Re: An idea: combine-change-calls

[Alan Mackenzie <acm@muc.de>]

Hello again, Stefan.

On Tue, Mar 27, 2018 at 14:30:53 -0400, Stefan Monnier wrote:
> > happens to undo-entries which aren't in the region.  Maybe they are
> > just discarded, maybe they are somehow kept in the undo list.

> They're just discarded (when building the list to pass to
> primitive-undo only: they stay in buffer-undo-list, of course).

OK.

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

> See http://elpa.gnu.org/packages/undo-tree.html

Interesting.  But I think it would be overkill for me personally.

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

> Actually the way I was thinking of using it was something like:

>     (let ((elem-apply `(apply 0 ,beg ,end ,#'my-undo-combining nil)))
>       (push elem-apply buffer-undo-list)
>       (funcall body)
>       (let ((new-bul (memq elem-apply buffer-undo-list)))
>         (when new-bul
>           (let ((undo-elems buffer-undo-list))
>             (setf (nthcdr (- (length undo-elems) (length new-bul))
>                           undo-elems)
>                   nil)
>             (setf (nth 1 elem-apply) (- end-marker end))
>             (setf (nth 3 elem-apply) (marker-position end-marker))
>             (setf (nth 5 elem-apply) undo-elems)
>             (setq buffer-undo-list new-bul)))))

> and then

>     (defun my-undo-combining (undo-elems)
>       (let ((inhibit-modification-hooks t))
>         (while t
>           (primitive-undo 1 undo-elems))))

OK, I get the general idea: there's a recursive call to primitive-undo
from the FUN-NAME in the `apply' undo element.

But it's actually more complicated still: When the undo is in progress,
FUN-NAME must push (a) new `apply' element(s) to buffer-undo-list for
the use of a possible redo.  This is probably possible, but my head's
beginning to hurt at the moment.  ;-)

My scheme (of introducing new types of element to the undo list) is
quite a bit simpler, but has the disadvantage of an incompatible change
in the undo list format.  I accept that this disadvantage is severe.

I think I will continue to refine my scheme to get practice and
experience.  Then will be the time to decide on replacing it with the
above `apply' scheme.

> But you might prefer just replacing the whole thing with a pair of
> insert+delete, which is simpler and vastly more efficient (but with the
> disadvantage that it doesn't preserve markers quite as well).

I really don't want to do this.  Some people will want to analyse
buffer-undo-list and such a replacement will throw off this analysis,
possibly to the extent of making it useless.  In practice, wrapping the
original undo elements in what we've been talking about is easily fast
enough.  (An undo over ~2000 lines of comment-region'd C++ code was
taking ~0.05s (if I remember correctly), though displaying it after that
took appreciably longer.)

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).