Re: An idea: combine-change-calls

[Alan Mackenzie]

Hello, Stefan.

On Thu, Mar 29, 2018 at 11:40:26 -0400, Stefan Monnier wrote:
> > I don't think "consider" is the right word here.  I don't think it will
> > work at all.

> I expect otherwise.

[ .... ]

> 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 think you've just drawn two pictures of possible undo lists.

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

Right, I think I've got it now.  The macro combine-change-calls would
maybe first push some sort of sentinal element onto buffer-undo-list,
then let ,@forms run, then massage the list so that the 2000 elements
created by ,@forms would become part of the `apply' element.

Yes, that would work.  :-)

I will implement this.

> >> ... 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.

I still don't understand.  What other things could possibly be similiar
enough to collecting before/after-change-functions to be abstractable
into some sort of parameter?  Could you give an example?

> > 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?

The information is the original undo entries created by the Emacs
primitives whilst in combine-change-calls.

As to where/when/why it might be needed, I couldn't say at this point.
Somebody, sometime, will want it for some reason, just like you said in
your piece about "hiding information" I quoted a short while ago.

Why are you so keen to destroy this detailed information?  Its continued
existence does not cause any disadvantage.  The run time which would be
saved in `undo' is minimal and inconsequential.

> >> 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.

OK.  We could amend primitive-undo such that the argument N could,
additionally, take the value t, meaning "undo all elements in the list,
ignoring nils".  Or something like that.

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

I suppose so.  What would such a boundary mean anyway?  We're talking
about a scenario where all the change hook invocations are amalgamated.
How could it make sense to split that up?

> >> 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.

I suppose not.  Not at the moment, anyway.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).