unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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?

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