Re: Support for undo-amalgamate in a version of the atomic-change-group macro (with patch)

[Campbell Barton]

On Tue, Nov 2, 2021 at 12:04 PM Campbell Barton <ideasman42@gmail.com> wrote:
>
> On 11/2/21 04:43, Stefan Monnier wrote:
> >> Hi, there have been a handful of times I've needed to treat multiple
> >> actions as a single action,
> >> others too (see stackoverflow question [0]).
> >>
> >> While this is supported using change groups, the resulting macro ends
> >> up being nearly identical to the existing `atomic-change-group' macro.
> >> The only difference is a call to undo-amalgamate-change-group.
> >
> > The other difference would be the call to `cancel-change-group` (you
> > may want to not undo the changes in case of errors).
>
> Good point (updated my answer)
>
> >> Attached a patch to add `atomic-change-group-undo-amalgamate' so
> >> packages don't need to use a modified copy of this macro.
> >
> > I suspect that we'd be better off with a separate macro which only does
> > the amalgamation without the cancel-change-group-on-error.
>
> Agree, if the cancel group is removed it's no longer atomic and can be a
> separate macro.
>
> > But I wonder how often such a macro would be useful: undo boundaries are
> > normally added only by the command-loop (i.e. the loop which repeatedly
> > reads a key and calls the corresponding command), so unless your macro's
> > body calls `recursive-edit` it's very unlikely that you'll get any undo
> > entries that you would then want to remove.
>
> I'm not sure why most other people are running into this (the original
> question relates specifically voice commands), nevertheless the stats on
> the stackexchange question lead me to think it's not so unusual to spawn
> multiple commands that happen to be treated as separate undo steps.
>
> > (Re)reading your stackexchange question, it seems you want to amalgamate
> > undo entries from different commands.  So do you run those commands
> > within a `recursive-edit`?  If not, how do you manage to run those
> > commands from within your (new) macro?
>
> As far as I know I'm not using recursive edit (unless indirectly).
>
> In these situations collapsing undo data was necessary.
>
> - Calling kmacro-exec-ring-item (based on this answer [0])
> - Calling some evil functions for e.g.
>
>    (defun evil-paste-and-indent-after ()
>      (interactive)
>      (with-undo-collapse
>        (evil-paste-after 1)
>        (evil-indent (evil-get-marker ?\[)
>                     (evil-get-marker ?\]))))
>
> [0]: https://emacs.stackexchange.com/questions/70

To follow up on my previous post, from checking packages on melpa, the
following use an undo-collapse macro:

- recomplete (recomplete--with-undo-collapse)
- jupyter (jupyter-repl-with-single-undo)
- meow (meow--wrap-collapse-undo)
- symex (symex--with-undo-collapse)

Candidates which could potentially use an undo collapse macro but mix
undo-amalgamate with other logic:

- eglot (eglot--apply-text-edits)
- lsp-mode (lsp--apply-text-edits)
- parinfer-rust-mode (parinfer-rust--execute)