Re: The *Warnings* buffer and undo

[Miles Bader <miles@gnu.org>]

Richard Stallman <rms@gnu.org> writes:
>      (1) If you use `comint-truncate-buffer' (in comint-output-filter-functions)
> 	 to keep comint buffers from getting too big (and in many cases it's a
> 	 very good idea), a line gets deleted at the beginning of the buffer for
> 	 every new line that gets inserted at the end, which can use massive
> 	 amounts of space in the undo list.
>
> Perhaps `comint-truncate-buffer' should discard its own undo entries.
> It could use `inhibit-undo', if we add such a feature.
> Alternatively we could add a feature which says, "discard this undo entry,
> and fix up the older entries so that they still work."  That could
> be written in Lisp.

It's arguably less reliable to rely on comint-truncate-buffer to worry
about it, because hooks on comint-output-filter-functions are not
generally controlled by the emacs distribution -- the user can write their
own hooks, and so might not know too take care of the necessary details.

The lisp solution which I've worked on a slight bit (and which
apparently is also done in ERC to some degree) inhibits undo while
calling hooks (and during new output insertion), and then tries to
measure the resulting amount of buffer change and fix up the
buffer-undo-list to reflect it.

This is probably doable in comint because the "undoable" and "undo
inhibited" buffer modifications are separated into two easily
distinguished areas.

However in some other potential applications (someone mentioned
customization buffers, where you probably want to restrict undo to the
user-editable fields), things are not so simple, so having something
which works at a primitive level (like "inhibit-undo") might be nice in
general.

-Miles

-- 
"1971 pickup truck; will trade for guns"