Re: disabling undo boundaries

[David Kastrup]

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.

-- 
David Kastrup