Re: disabling undo boundaries

[Phillip Lord]

David Kastrup <address@hidden> writes:

> address@hidden (Phillip Lord) writes:
>
>> Stefan Monnier <address@hidden> writes:
>>
>>>> I think that the current undo-boundary behaviour wrt a single buffer
>>>> makes sense. It's the fact that inserting content into *that* buffer
>>>> forces an undo-boundary into *this* buffer.  I don't know why Emacs
>>>> does this.
>>>
>>> I think the reason is not very deep: for reasons of efficiency (back in
>>> the days when 8MB was a lot of memory), Emacs keeps track of a few
>>> undo-related pieces of information in global variables, so it can only
>>> handle a single buffer at a time.  If a command touches some other
>>> buffer, the C code has to choose between "just switch" and "push
>>> a boundary and then switch", and the choice it makes is to err on the
>>> "safe" side of adding a potentially unnecessary undo-boundary rather
>>> than risking to let the undo-log grow without intervening boundaries.
>>
>>
>> I meant "deep" in the sense of "deep in version control history" -- or
>> in this case, before the version control system. Still, I didn't know
>> this was the reason.
>
> The problem _I_ see is that it is in general not just "a command" which
> may touch another buffer, but also compilation buffers, timer events,
> font lock and a number of other background activities not immediately
> caused by key presses.


I don't think this is an issue, because Emacs is single-threaded. So,
all of these events happen *between* commands which, in general, means
that an undo-boundary has gone onto the current-buffer anyway. So, they
don't break the undo behaviour in the current-buffer.

If it were not, the current semantics of Emacs undo would have been
shown to be problematic a long time ago.

As it stands (as I think I mentioned a long time ago!), I've checked how
often undo-boundaries are added by the current logic and the answer is
hardly ever. The code is almost entirely benign AFAICT, in that it never
runs. It just makes undo.c more complex than necessary, and is a total
disaster for my use case.

As always, it depends on what you do with Emacs and I may be missing
something where it is the right thing. I can't tell.

Phil