[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A new(?) warning of erase-buffer, which was not seen before.

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



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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]