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

[ishikawa <chiaki.ishikawa@ubin.jp>]

Miles Bader wrote:
> Richard Stallman <rms@gnu.org> 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