From: Miles Bader <miles@gnu.org>
To: rms@gnu.org
Cc: rgm@gnu.org, lennart.borgman@gmail.com, emacs-devel@gnu.org
Subject: Re: The *Warnings* buffer and undo
Date: Sat, 31 Mar 2007 07:50:04 +0900 [thread overview]
Message-ID: <87ejn6z6qr.fsf@catnip.gol.com> (raw)
In-Reply-To: <E1HXOYm-0000lD-H8@fencepost.gnu.org> (Richard Stallman's message of "Fri\, 30 Mar 2007 17\:23\:00 -0400")
Richard Stallman <rms@gnu.org> 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.
-Miles
--
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?
next prev parent reply other threads:[~2007-03-30 22:50 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-24 20:01 The *Warnings* buffer and undo Lennart Borgman (gmail)
2007-03-25 17:27 ` Richard Stallman
2007-03-28 0:47 ` Glenn Morris
2007-03-28 19:36 ` David Kastrup
2007-03-28 20:52 ` Glenn Morris
2007-03-29 17:59 ` Richard Stallman
2007-03-29 18:35 ` David Kastrup
2007-03-30 12:42 ` Richard Stallman
2007-03-30 19:18 ` Glenn Morris
2007-03-30 19:53 ` Lennart Borgman (gmail)
2007-03-31 7:20 ` Richard Stallman
2007-03-31 19:41 ` Glenn Morris
2007-03-31 23:21 ` Richard Stallman
2007-03-29 22:07 ` Miles Bader
2007-03-30 21:23 ` Richard Stallman
2007-03-30 21:45 ` Glenn Morris
2007-03-30 22:50 ` Miles Bader [this message]
2007-03-31 20:43 ` Richard Stallman
2007-04-01 0:22 ` Miles Bader
2007-04-01 0:44 ` Miles Bader
2007-03-29 15:32 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ejn6z6qr.fsf@catnip.gol.com \
--to=miles@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=lennart.borgman@gmail.com \
--cc=rgm@gnu.org \
--cc=rms@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).