|
From: | ishikawa |
Subject: | Re: A new(?) warning of erase-buffer, which was not seen before. |
Date: | Fri, 23 Mar 2007 18:47:11 +0900 |
User-agent: | Thunderbird 1.5.0.10 (X11/20070221) |
Miles Bader wrote:
Richard Stallman <address@hidden> 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 bufferof 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 willsolve 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
[Prev in Thread] | Current Thread | [Next in Thread] |