[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: disabling undo boundaries
From: |
David Kastrup |
Subject: |
Re: disabling undo boundaries |
Date: |
Fri, 07 Aug 2015 15:59:05 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) |
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
- Re: disabling undo boundaries, Phillip Lord, 2015/08/04
- Re: disabling undo boundaries, Stefan Monnier, 2015/08/07
- Re: disabling undo boundaries, Stefan Monnier, 2015/08/08
- Re: disabling undo boundaries, Phillip Lord, 2015/08/09
- Re: disabling undo boundaries, Stefan Monnier, 2015/08/09
- Re: disabling undo boundaries, Phillip Lord, 2015/08/09
- Re: disabling undo boundaries, Stefan Monnier, 2015/08/09
- Re: disabling undo boundaries, Phillip Lord, 2015/08/10