Re: An idea: combine-change-calls

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Mon, Mar 26, 2018 at 17:07:40 -0400, Stefan Monnier wrote:
> > I'm experimenting with a different strategy: surrounding the mass of
> > elements in buffer-undo-list with a `(combine-change-begin ,beg ,end)
> > and a `(combine-change-end ,beg ,end).

> Beware: this changes the format of entries that can appear in the
> buffer-undo-list, which has repercussions beyond primitive-undo, IOW it
> can/will break other things such as undo-in-region and undo-tree.

Thanks.  I didn't know about undo-in-region.  That is a peculiarly badly
documented feature: Neither manual states what it means for an
undo-entry to be "within the region", and nowhere is it stated what
happens to undo-entries which aren't in the region.  Maybe they are
just discarded, maybe they are somehow kept in the undo list.

It looks like I've got some source code to read.

By the way, what's undo-tree?  I've not been able to find that symbol at
all in the source code.

> Better use the (apply DELTA BEG END FUN-NAME . ARGS) form, which was
> introduced specifically for use of such extensions.

This won't work, at least not without some seriously twisted coding: The
essential thing about (combine-change-end/begin ..) is that they bind
inhibit-modification-hooks to non-nil for other entries in the
undo-list.  Maybe FUN-NAME could call primitive-undo, but this doesn't
seem wise.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).