From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: The *Warnings* buffer and undo Date: Sat, 31 Mar 2007 07:50:04 +0900 Message-ID: <87ejn6z6qr.fsf@catnip.gol.com> References: <460583AD.7010002@gmail.com> <85abxxw46j.fsf@lola.goethe.zz> <87y7lf1z6t.fsf@catnip.gol.com> Reply-To: Miles Bader NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1175295023 8999 80.91.229.12 (30 Mar 2007 22:50:23 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 30 Mar 2007 22:50:23 +0000 (UTC) Cc: rgm@gnu.org, lennart.borgman@gmail.com, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 31 00:50:21 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HXPvF-0001UV-RG for ged-emacs-devel@m.gmane.org; Sat, 31 Mar 2007 00:50:18 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HXPxz-0002LK-Fq for ged-emacs-devel@m.gmane.org; Fri, 30 Mar 2007 17:53:07 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HXPxx-0002LC-7l for emacs-devel@gnu.org; Fri, 30 Mar 2007 18:53:05 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HXPxu-0002JJ-Ks for emacs-devel@gnu.org; Fri, 30 Mar 2007 18:53:04 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HXPxu-0002JA-C9 for emacs-devel@gnu.org; Fri, 30 Mar 2007 17:53:02 -0500 Original-Received: from smtp02.dentaku.gol.com ([203.216.5.72]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HXPv7-0005qB-Ad; Fri, 30 Mar 2007 18:50:09 -0400 Original-Received: from 203-216-104-183.dsl.gol.ne.jp ([203.216.104.183] helo=catnip.gol.com) by smtp02.dentaku.gol.com with esmtpa (Dentaku) id 1HXPv4-000540-NN; Sat, 31 Mar 2007 07:50:06 +0900 Original-Received: by catnip.gol.com (Postfix, from userid 1000) id A1A8F2F43; Sat, 31 Mar 2007 07:50:04 +0900 (JST) System-Type: i686-pc-linux-gnu In-Reply-To: (Richard Stallman's message of "Fri\, 30 Mar 2007 17\:23\:00 -0400") Original-Lines: 33 X-Abuse-Complaints: abuse@gol.com X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:68789 Archived-At: Richard Stallman 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?