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: Sun, 01 Apr 2007 09:22:30 +0900 Message-ID: <871wj5ymd5.fsf@catnip.gol.com> References: <460583AD.7010002@gmail.com> <85abxxw46j.fsf@lola.goethe.zz> <87y7lf1z6t.fsf@catnip.gol.com> <87ejn6z6qr.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 1175386973 31684 80.91.229.12 (1 Apr 2007 00:22:53 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 1 Apr 2007 00:22:53 +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 Sun Apr 01 02:22:46 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 1HXnqI-00047l-41 for ged-emacs-devel@m.gmane.org; Sun, 01 Apr 2007 02:22:46 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HXnt9-0003rr-61 for ged-emacs-devel@m.gmane.org; Sat, 31 Mar 2007 19:25:43 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HXnt6-0003p7-Pp for emacs-devel@gnu.org; Sat, 31 Mar 2007 20:25:40 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HXnt5-0003hU-51 for emacs-devel@gnu.org; Sat, 31 Mar 2007 20:25:40 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HXnt5-0003hA-0N for emacs-devel@gnu.org; Sat, 31 Mar 2007 19:25:39 -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 1HXnq8-0001VF-Lw; Sat, 31 Mar 2007 20:22:37 -0400 Original-Received: from 203-216-98-180.dsl.gol.ne.jp ([203.216.98.180] helo=catnip.gol.com) by smtp02.dentaku.gol.com with esmtpa (Dentaku) id 1HXnq5-0002bf-LS; Sun, 01 Apr 2007 09:22:33 +0900 Original-Received: by catnip.gol.com (Postfix, from userid 1000) id 5ECF02F43; Sun, 1 Apr 2007 09:22:30 +0900 (JST) System-Type: i686-pc-linux-gnu In-Reply-To: (Richard Stallman's message of "Sat\, 31 Mar 2007 16\:43\:00 -0400") Original-Lines: 38 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:68872 Archived-At: Richard Stallman 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"