Re: An idea: combine-change-calls

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Fri, Mar 30, 2018 at 09:04:06 -0400, Stefan Monnier wrote:
> > But the `(apply ...)' forms are a problem for exactly these other
> > things. It's too powerful. The packages that manipulate buffer-undo-list
> > can't (and don't try to) handle `apply' properly, since it can contain
> > arbitrary effects.

> AFAIK the (apply ...) has the needed constraints for undo-in-region to
> handle it properly.  If not, we should fix it.

Indeed we should.  undo-elt-in-region "Determine whether UNDO-ELT falls
inside the region START ... END." lacks a cond arm for (apply ...), so
always returns nil for it, which means that undo doesn't work at all for
an (apply ...) element when transient-mark-mode is enabled and the mark
is "active" (which is quite common).

> So, AFAIK it's handled properly by undo itself, undo-tree, and
> undo-in-region.  Which "package that manipulate buffer-undo-list" are
> you thinking of?

Actually, undo-in-region is problematic.  Aside from undo-elt-in-region
(see above), which is easy to fix, there is undo-adjust-elt "Return
adjustment of undo element ELT by the undo DELTAS list.", which can't
adjust the contents of an (apply ...) element, since it doesn't know the
internal structure of each type of (apply ...).  In this sense, (apply
...) is indeed too powerful.

Fixing this in general would need something like a property on the
(apply ...)'s FUN-NAME symbol, whose value would be a function for
"returning the adjustment of the matching (apply ...) element".  But
that is getting crazy.

Why do we have undo-in-region at all?  It fouls up the simplicity of the
undo mechanism.  It also seems like a nuisance rather than a feature:
If I were using transient-mark-mode, made some buffer changes, and
somehow had a small "active" region; if I then start undoing the
changes, I would be annoyed if C-x u missed out some undos because they
weren't inside that region.  I think it would make undo unusable.

How about phasing out undo-in-region?  We make it optional in Emacs 27.1
(with the default being off), see if anybody complains, then remove it
entirely in Emacs 28.  undo-in-region is incompatible with (apply ...).
I would say that (apply ...) is the more important of the two.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).