Re: disabling undo boundaries

[Phillip Lord]

Stefan Monnier <address@hidden> writes:

>> Yes, you are right, the second buffer is an issue, although I am not
>> convinced that the behaviour is worse.
>
> Worse than the ideal or worse than the current one?

The current situation.

> Right now, I'm trying to understand what the ideal behavior should be.

I don't have a clear handle on this either.

For my two use cases, with noisy-change-log, I think the answer is, I
don't really care. I don't need undo in a log buffer, and if I had
thought about it, I would have switched it off.

For lentic, I would like the undo-boundaries to be what they would have
been if the commands had been typed manually.

> After that, we can try to figure out how to get this ideal behavior, or
> how close we can get to it, and which part of the work can be made
> generic in undo.c and which part of the work has to be done manually by
> each and every particular command/package.

That would be good.

Another package worth looking at would be gnus, which AFAICT,
reimplements undo all for itself, to cope with the fact that it's a
multi buffer sort of package.
 


>> ** Conclusion
>> All of the insertion events have been amalgamated, so the undo is much
>> too "lumpy".  Again, I can add this logic in, but I have to duplicate
>> the "add an undo-boundary after a command" logic from the
>> command loop.
>
> [ You only used self-insert-command in your examples, which gives
>   a slightly twisted view of what's going on in general.  ]
>
> But ideally, we could have undo.c do most of that for you.
> E.g. instead of adding a boundary every time we switch buffer, undo.c
> could simply keep track of which buffers have seen changes during the
> current command, and then push undo-boundaries on all of them at the end
> of the command.


Yeah, thought about that and that would get me most of the way there.

I think that should not affect *shell* buffers or equivalent right? They
actually only update outside of the command loop, so can't have changed
in the middle?


> Except for self-insert-command, I think this would give you the ideal
> behavior (without any manual work on your side) *and* it would mostly
> preserve the existing behavior.
>
> For self-insert-command, it's more tricky, and you'd probably need to do
> the extra manual work.  E.g. add a post-self-insert-hook which checks if
> this self-insert-command removed the previous undo-boundary and then
> remove it as well in the sibling buffer.  I can't see how undo.c could
> do that for you magically, since it doesn't know that the insertions in
> the sibling buffer are "clones" of the insertions in the main buffer,
> nor that it's done by self-insert-command.


I'd agree with this. One possibility would be to have an undo-boundary
command which is implements the same sort of "20 steps" logic as
self-insert-command. But, even that is going to be hard, since there can
be more changes in *that* buffer than in *this* (the two are not
necessarily exactly the same).

I think this would all be a little easier if buffer-undo-list didn't use
"nil" but allowed the developer to differentiate between different kinds
of boundary.


> Another approach would be for you to arrange such that your a-f-c uses
> self-insert-command rather than `insert' when cloning the insertion
> from a self-insert-command, but that's probably just as hard if not
> harder.

That doesn't sound great to me either, as I have to behave quite
differently depending on the last-command.

It seems to me, that you are not adverse to the idea of changing undo.c
to stop it putting boundaries in. Can I suggest a way forward? I will
carry on with my hacked Emacs with removed undo-boundaries in undo.c. I
can add the "undo-boundary to all changed buffers" using
post-command-hook. This will let me test everything makes sense and
works as expected, and I don't mind spending the effort, if emacs will
support it later.

If you are prepared to implement the "add an undo-boundary to every
buffer thats changed" logic into undo.c/cmd.c, then we can do that once
the logic works. I would be willing to help with that, but my C
programming is very poor, and in practice, I'm likely to learn more than
I actually help.


Phil