From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ishikawa Newsgroups: gmane.emacs.devel Subject: Re: A new(?) warning of erase-buffer, which was not seen before. Date: Fri, 23 Mar 2007 18:47:11 +0900 Message-ID: <4603A21F.5030608@ubin.jp> References: <45FDF35F.6030605@ubin.jp> <45FF5975.1070602@ubin.jp> <4602639A.8030606@ubin.jp> <87vegsj244.fsf@catnip.gol.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1174643333 9705 80.91.229.12 (23 Mar 2007 09:48:53 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 23 Mar 2007 09:48:53 +0000 (UTC) Cc: storm@cua.dk, rms@gnu.org, emacs-devel@gnu.org To: Miles Bader Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 23 10:48: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 1HUgO5-0002gr-T6 for ged-emacs-devel@m.gmane.org; Fri, 23 Mar 2007 10:48:46 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HUgPx-0008FC-Tb for ged-emacs-devel@m.gmane.org; Fri, 23 Mar 2007 04:50:41 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HUgOl-0007YJ-Ck for emacs-devel@gnu.org; Fri, 23 Mar 2007 05:49:27 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HUgOi-0007Vm-1n for emacs-devel@gnu.org; Fri, 23 Mar 2007 05:49:27 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HUgOh-0007Vi-Sd for emacs-devel@gnu.org; Fri, 23 Mar 2007 04:49:23 -0500 Original-Received: from post.ubin.jp ([202.32.0.84]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HUgMg-0006e4-P4; Fri, 23 Mar 2007 05:47:19 -0400 Original-Received: from post.ubin.jp (post [127.0.0.1]) by localhost.ubin.jp (Postfix) with ESMTP id 00A2329AC2F; Fri, 23 Mar 2007 18:47:14 +0900 (JST) Original-Received: from [10.254.248.233] (dell-w2k-note.ddns.member.ubin.jp [10.254.248.233]) by post.ubin.jp (Postfix) with ESMTP id 87BD129AC2C; Fri, 23 Mar 2007 18:47:13 +0900 (JST) User-Agent: Thunderbird 1.5.0.10 (X11/20070221) In-Reply-To: <87vegsj244.fsf@catnip.gol.com> X-detected-kernel: Linux 2.4-2.6 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:68370 Archived-At: Miles Bader wrote: > Richard Stallman writes: >> Actually, we want people to tell us where they get these messages, >> so that we can learn about Emacs modes and facilities >> where we ought to turn off undo. > > This is an issue for post-release, but: > > I think comint is an obvious candidate for this -- the throughput in a > comint buffer can be massive, and basically you never want to undo > anything except small user edits at the end. Indeed, it's all to easy > to accidentally undo part of the process output, which just messes > things up. However, it _is_ handy to have undo for user edits of the > command line. > > Ideally, you could keep undo information _only_ for user edits, and > flush even that whenever the user submits a line of input to the > subprocess (so once submitted, a command line would become "permanent"). > > I've been working on some patches to comint to do this, by selectively > disabling undo at various points, but it's not entirely straight-forward > because you then have to fix up the undo list to account for the > unrecorded buffer changes. > > -Miles > Hi, Come to think of it, my original post was concerning a buffer which actually contains interactive-shell mode buffer (I invoked it with M-x shell and then later renamed it to "*sim*" since a buffer of which name starts with "*" is not the target of confirmation for saving when we quit emacs. The buffer contains the massive output of a running simulator program which I want to check from time to time, but basically I can safely throw it away whenever the buffer becomes too large. I am not familiar with the current emacs, but if comint is the underlying base for "shell" mode, then I agree that the above change will solve all my concerns. (I don't understand the "unrecorded buffer changes" above [whose change? subprocess?], but I think that is a side issue.) As a matter of fact, "undo" is probably unnecessary even for small user command editing if we use a shell that supports the printing of past history of executed command. In order to pick up old command line for new editing, we can always run, say, "history" to bash to choose the command line even if we lost the region that contains that particular command line by mistake or something. But not all the interactive program that talks with us at the other end supports "list command history" command. So comint might have to deal with user input editing issues. At least, "shell" mode might be an easy target. Chiaki Ishikawa