Re: An idea: combine-change-calls

[Stefan Monnier]

> I don't think "consider" is the right word here.  I don't think it will
> work at all.

I expect otherwise.

> In primitive-undo, some undo list is an argument, and it
> has elements removed from it and it is then the return value.  If we try
> to call primitive-undo recursively through an (apply ...) form, there is
> no interface to return the depleted list to the calling p-u.

You keep assuming a shape like

    ...previous elements...
    (apply ....)
    ...undo-elements...
    (apply ....)
    ...subsequent elements...

where I'm assuming a shape like:

    ...previous elements...
    (apply ....  ...undo-elements...)
    ...subsequent elements...

I don't see any part of primitive-undo which would prevent it being used
recursively in such a situation.

>> ... than I'd want this new extension to be generic rather than
>> specific for this particular use-case.
> It is generic, in the sense it handles any case where
> before/after-change-functions are to be condensed into one call of each.
> What do you mean by generic, here?

That it can be used by other things than combine-change-calls.
I.e. generic is the same sense as the (apply ....) thingy is generic.

> It does a good deal more than "optimizing the representation" - it makes
> an irreversible change which loses information.

To the extent that most execution of code makes irreversible changes,
I agree, but other than that, I fail to see what information you're
thinking about.

> Somebody, sometime, is going to need that info.

Could you give some hypothetical example to give me an idea of what kind
of info you're thinking of and where/when it might be needed?

>> Whatever you decide to do with the undo-log, handling undo-boundary
>> pushed during the execution of `body` will be tricky I suspect (except
>> if we just don't touch the undo-list, of course).
> In my current code, the only undo-boundary pushed (in the handling of
> combine-change-begin) is immediately acted upon to terminate the
> recursive invocation of primitive-undo.  This is pushed onto the LIST
> variable in the nested p-u, and doesn't affect buffer-undo-list or
> pending-undo-list.

I'm referring to undo-boundaries pushed by the "execution of
`body`", not by your code.

IIUC we agree that this is considered an unimportant use-case and it's
OK to just ignore such boundaries.

>> IIUC The code you cite only strips them from the undo elements added
>> while performing an undo (i.e. from "redo" elements), so they should
>> still work for a plain "edit .... undo".
> Ah, is that it?  I had some difficulty understanding it properly.

Yes, that's it.  I don't think it affects this discussion at all.


        Stefan