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"
_______________________________________________
Emacs-devel mailing list
Emacs-devel gnu.org
htt
p://lists.gnu.org/mailman/listinfo/emacs-devel
|