[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] fix/no-undo-boundary-on-secondary-buffer-change e5ff57

From: Phillip Lord
Subject: Re: [Emacs-diffs] fix/no-undo-boundary-on-secondary-buffer-change e5ff575 2/2: Add a timer to ensure undo-boundaries in buffers.
Date: Tue, 01 Sep 2015 13:24:26 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Stefan Monnier <address@hidden> writes:

>> +(defun undo-ensure-boundary ()
>> +  "Add an `undo-boundary' if `buffer-undo-list' is long.
>> +
>> +Return t if an undo boundary has been added.
>> +
>> +Normally, Emacs will only garbage collect data from
>> +`buffer-undo-list' when this list is longer than `undo-limit'. It
>> +then collects data from after the first `undo-boundary' after
>> +`undo-limit'. If there are no boundaries in the list,
>> +`buffer-undo-list' will grow until it reaches
>> +`undo-outer-limit' (by default a much larger value than
>> +`undo-limit'), when it will discard the data anyway. In this
>> +case, however, it is treated as an exceptional case, and the a
>> +warning is signalled.
>> +
>> +This function add an `undo-boundary' to `buffer-undo-list' if
>> +there is no other `undo-boundary', and `buffer-undo-list' is
>> +longer than `undo-limit'. It provides a useful default mechanism
>> +for adding an `undo-boundary' which retains data where possible,
>> +without signalling warnings to the user."
> I think this makes sense, but we should do it in the GC code, then.

It's possible, but it then negates the utility of the
`under-outer-limit' functionality. The point is that after
undo-outer-limit GC ditches the undo data anyway in the absence of any
boundaries, but does so noisily. But, if we run undo-ensure-boundary
before compaction, the boundary will mean the undo-list is always
GC'able with noise.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]