[Top][All Lists]

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

Re: The *Warnings* buffer and undo

From: Miles Bader
Subject: Re: The *Warnings* buffer and undo
Date: Sat, 31 Mar 2007 07:50:04 +0900

Richard Stallman <address@hidden> writes:
>       (3) Modify the emacs insert/delete primitives to do the job, e.g.,
>         they could look for a variable like `inhibit-undo', and if
>         non-nil, fixup buffer-undo-list to account for the new operation
>         instead of actually recording the new operation in it.
> This seems like a good feature to perhaps add.
> However, it occurs to me that the insertion of text (such as, new
> warnings) uses rather little space in an undo list.  So I wonder how
> it happened that the undo list in the warnings buffer got big enough
> to trigger the warning.  Did that really happen?

I don't know about the *Warning* buffer (I don't think I've ever even seen
it), but in the case of comint:

 (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.

 (2) The interleaving of "user input" and "process output" in the undo list
     can be very annoying for the user -- when you try to undo something you
     just typed, you can end up accidentally undoing process output instead.
     That's not only very confusing, but can actually be quite hard to
     properly recover from (despite undo) if the process is continually
     sending output.

Come now, if we were really planning to harm you, would we be waiting here,
 beside the path, in the very darkest part of the forest?

reply via email to

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