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

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

[ishikawa]

Hi,

When I ran "erase-buffer" on a buffer named "*sim*", I got
the following warning, which I didn't get with older version of Emacs.

Is this warning an intentional one?

In the old emacs version(s), it used to be that erase-buffer intentionally
discarded undo information if I recall correctly. The buffer in question, namely
"*sim*",  contained
a voluminous output of a running simulator program and I simply want to
throw away the contents from time to time. And thus, undo is not necessary
for this buffer.

emacs-version is a variable defined in `version.el'.
Its value is "22.0.93.1"

--- new warning which I see with 22.0.93.1

Warning (undo): Buffer `*sim*' undo info was 4766843 bytes long.
The undo info was discarded because it exceeded `undo-outer-limit'.

This is normal if you executed a command that made a huge change
to the buffer.  In that case, to prevent similar problems in the
future, set `undo-outer-limit' to a value that is large enough to
cover the maximum size of normal changes you expect a single
command to make, but not so large that it might exceed the
maximum memory allotted to Emacs.

If you did not execute any such command, the situation is
probably due to a bug and you should report it.

You can disable the popping up of this buffer by adding the entry
(undo discard-info) to the user option `warning-suppress-types'.

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

[Kim F. Storm]

ishikawa <chiaki.ishikawa@ubin.jp> writes:

> Hi,
>
> When I ran "erase-buffer" on a buffer named "*sim*", I got
> the following warning, which I didn't get with older version of Emacs.
>
> Is this warning an intentional one?

Yes.


> In the old emacs version(s), it used to be that erase-buffer intentionally
> discarded undo information if I recall correctly. 

I just checked, and no version of GNU Emacs since 1991 has done that
(I didn't check older versions).

>                                                   The buffer in question, namely
> "*sim*",  contained
> a voluminous output of a running simulator program and I simply want to
> throw away the contents from time to time. And thus, undo is not necessary
> for this buffer.

So disable undo in that buffer.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

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

[ishikawa]

Kim F. Storm wrote:
> ishikawa <chiaki.ishikawa@ubin.jp> writes:
> 
>> Hi,
>>
>> When I ran "erase-buffer" on a buffer named "*sim*", I got
>> the following warning, which I didn't get with older version of Emacs.
>>
>> Is this warning an intentional one?
> 
> Yes.
> 
> 
>> In the old emacs version(s), it used to be that erase-buffer intentionally
>> discarded undo information if I recall correctly. 
> 
> I just checked, and no version of GNU Emacs since 1991 has done that
> (I didn't check older versions).
> 
>>                                                   The buffer in question, namely
>> "*sim*",  contained
>> a voluminous output of a running simulator program and I simply want to
>> throw away the contents from time to time. And thus, undo is not necessary
>> for this buffer.
> 
> So disable undo in that buffer.
> 

Thank you for the info.

It is only that I am a little puzzled that I didn't get this warning
in the previous versions 21.x (and prior), and I am wondering
if there is a better memory allocation/checking introduced in 22.0
which causes this warning to appear. In the older versions, say 21.x (and 
prior), I have not seen this message.
With 22.0, I see the memory usage warning also, which I didn't notice often before.

Maybe, with the older versions, the logic to show the warning might have had a 
subtle bug/feature which caused the warning not to  appear often on my PC. But I 
digress.

I will disable undo on this buffer and move on.
(Maybe my knowledge of erase-buffer discarding undo information is
based on the old knowledge of 18.xx version which I tried to port
to now extinct Data General minicomputers. This was circa mid 1980's)

Thank you again.

Chiaki Ishikawa

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

[Kim F. Storm]

ishikawa <chiaki.ishikawa@ubin.jp> writes:

> It is only that I am a little puzzled that I didn't get this warning
> in the previous versions 21.x (and prior), and I am wondering
> if there is a better memory allocation/checking introduced in 22.0
> which causes this warning to appear. In the older versions, say 21.x
> (and prior), I have not seen this message.

Those warnings are new in Emacs 22.

In Emacs 21 and before, there is a risk of running out of memory and
Emacs crashing.

In Emacs 22, more checks and automatic measures like undo-outer-limit
have been added to prevent running out of memory, and to give feedback
to the user when those measures kick in.

Here's what C-h C-n (aka NEWS) says about it:

** When the undo information of the current command gets really large
(beyond the value of `undo-outer-limit'), Emacs discards it and warns
you about it.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

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

[ishikawa]

Kim F. Storm wrote:
> ishikawa <chiaki.ishikawa@ubin.jp> writes:
> 
>> It is only that I am a little puzzled that I didn't get this warning
>> in the previous versions 21.x (and prior), and I am wondering
>> if there is a better memory allocation/checking introduced in 22.0
>> which causes this warning to appear. In the older versions, say 21.x
>> (and prior), I have not seen this message.
> 
> Those warnings are new in Emacs 22.
> 
> In Emacs 21 and before, there is a risk of running out of memory and
> Emacs crashing.
> 
> In Emacs 22, more checks and automatic measures like undo-outer-limit
> have been added to prevent running out of memory, and to give feedback
> to the user when those measures kick in.
> 
> Here's what C-h C-n (aka NEWS) says about it:
> 
> ** When the undo information of the current command gets really large
> (beyond the value of `undo-outer-limit'), Emacs discards it and warns
> you about it.
> 

Thank you again.

After tinkering with new emacs, here is my suggestion for a slight improvement 
for the particular warning message.

AT the end (that is,
after "You can disable the popping up of this buffer by adding the entry
(undo discard-info) to the user option `warning-suppress-types'."),
we might want to add something like the following (as rms suggested):

"
If you know what you are doing, and you don't want the buffer
to collect undo information which uses memory internally,
do M-x buffer-disable-undo,  or (setq buffer-undo-list t)."

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

[Richard Stallman]

    After tinkering with new emacs, here is my suggestion for a slight improvement 
    for the particular warning message.

    AT the end (that is,
    after "You can disable the popping up of this buffer by adding the entry
    (undo discard-info) to the user option `warning-suppress-types'."),
    we might want to add something like the following (as rms suggested):

    "
    If you know what you are doing, and you don't want the buffer
    to collect undo information which uses memory internally,
    do M-x buffer-disable-undo,  or (setq buffer-undo-list t)."

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.

So if we add something like this, we should add something urging
people to send a bug report if they get such a message from any
mode or facility built into Emacs.

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

[Miles Bader]

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

-- 
"Don't just question authority,
Don't forget to question me."
-- Jello Biafra

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

[ishikawa]

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

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

[Davis Herring]

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

For the record, the * in the buffer name has nothing to do with that
decision; it's that `buffer-file-name' and `buffer-offer-save' are both
nil in a buffer.  (When you do C-x s instead of C-x C-c, and for the "exit
anyway?" query, only `buffer-file-name' counts.)

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

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

[Johan Bockgård]

Miles Bader <miles@gnu.org> writes:

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

FWIW, erc.el does this kind of selective undo.

-- 
Johan Bockgård

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

[Miles Bader]

bojohan+news@dd.chalmers.se (Johan Bockgård) writes:
>> 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.
>
> FWIW, erc.el does this kind of selective undo.

How does it deal with changing buffer locations?

I mean, if you're editing a new command line at the same time that some
text is being output into the buffer by the subprocess, then if you
don't record the subprocess output in the undo list (and you don't want
to), then the buffer positions recorded in buffer-undo-list become
invalid, as they're simply integers (not markers).

My attempted solution was to scan through buffer-undo-list, updating
those position, every time I inserted some "hidden from undo" text.
[This isn't typically a performance problem because _usually_
buffer-undo-list is nil when process output is occuring.]

Thanks,

-Miles

-- 
[|nurgle|]  ddt- demonic? so quake will have an evil kinda setting? one that
            will  make every christian in the world foamm at the mouth?
[iddt]      nurg, that's the goal

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

[Johan Bockgård]

Miles Bader <miles.bader@necel.com> writes:

> bojohan+news@dd.chalmers.se (Johan Bockgård) writes:
>>> 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.
>>
>> FWIW, erc.el does this kind of selective undo.
>
> How does it deal with changing buffer locations?

Nicely.

> My attempted solution was to scan through buffer-undo-list, updating
> those position, every time I inserted some "hidden from undo" text.
> [This isn't typically a performance problem because _usually_
> buffer-undo-list is nil when process output is occuring.]

That's exactly what ERC does.  See erc-update-undo-list.

-- 
Johan Bockgård

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

[Stefan Monnier]

>>>> 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.
>>> 
>>> FWIW, erc.el does this kind of selective undo.
>> 
>> How does it deal with changing buffer locations?

> Nicely.

>> My attempted solution was to scan through buffer-undo-list, updating
>> those position, every time I inserted some "hidden from undo" text.
>> [This isn't typically a performance problem because _usually_
>> buffer-undo-list is nil when process output is occuring.]

> That's exactly what ERC does.  See erc-update-undo-list.

I.e. we should probably add a "insert-without-undo" function which does
just that.


        Stefan

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

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
>>>>> 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.
>>>> FWIW, erc.el does this kind of selective undo.
>>> How does it deal with changing buffer locations?
> 
>> Nicely.
> 
>>> My attempted solution was to scan through buffer-undo-list, updating
>>> those position, every time I inserted some "hidden from undo" text.
>>> [This isn't typically a performance problem because _usually_
>>> buffer-undo-list is nil when process output is occuring.]
> 
>> That's exactly what ERC does.  See erc-update-undo-list.
> 
> I.e. we should probably add a "insert-without-undo" function which does
> just that.

Yes, please. And also an delete-without-undo.

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

[martin rudalics]

 >>>> My attempted solution was to scan through buffer-undo-list, updating
 >>>> those position, every time I inserted some "hidden from undo" text.
 >>>> [This isn't typically a performance problem because _usually_
 >>>> buffer-undo-list is nil when process output is occuring.]
 >>
 >>
 >>> That's exactly what ERC does.  See erc-update-undo-list.
 >>
 >>
 >> I.e. we should probably add a "insert-without-undo" function which does
 >> just that.
 >
 >
 > Yes, please. And also an delete-without-undo.

You can't do that by simply scanning the buffer-undo-list and comparing
positions.  If I recall correctly `erc-update-undo-list' doesn't even
handle the simple case where the undo list records an insertion from A
to B, and you want to insert a text from C to D where A < C and D < B.
It would either modify both A and B or none of them.

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

[Miles Bader]

martin rudalics <rudalics@gmx.at> writes:
> You can't do that by simply scanning the buffer-undo-list and comparing
> positions.  If I recall correctly `erc-update-undo-list' doesn't even
> handle the simple case where the undo list records an insertion from A
> to B, and you want to insert a text from C to D where A < C and D < B.
> It would either modify both A and B or none of them.

For uses like erc and comint it hardly matters.  I don't know if it's
worth trying to support the general case.

In the case of comint, I'd actually like to try supporting a model where
the undo-list-updating is _not_ handled directly by the text modifying
code -- i.e. `insert/delete-without-undo' wouldn't work.  The reason is
that some text modification is done by various hook functions in comint,
and those are harder to control (e.g. they may be written by the user).

I don't think this is too much of a problem given the restrictions of
comint mode (where non-undoable and undoable modifications are separated
by a clear boundary).

To support this model in a more general manner I guess would require
primitive support (e.g., something like an `inhibit-undo' variable which
would cause primitives to adjust the undo list instead of recording undo
information).

-Miles

-- 
Is it true that nothing can be known?  If so how do we know this?  -Woody Allen

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

[martin rudalics]

 > In the case of comint, I'd actually like to try supporting a model where
 > the undo-list-updating is _not_ handled directly by the text modifying
 > code -- i.e. `insert/delete-without-undo' wouldn't work.  The reason is
 > that some text modification is done by various hook functions in comint,
 > and those are harder to control (e.g. they may be written by the user).
 >
 > I don't think this is too much of a problem given the restrictions of
 > comint mode (where non-undoable and undoable modifications are separated
 > by a clear boundary).

Agreed.

 > To support this model in a more general manner I guess would require
 > primitive support (e.g., something like an `inhibit-undo' variable which
 > would cause primitives to adjust the undo list instead of recording undo
 > information).

I think it's not feasible.  I tried to write such code for customization
buffers - where undo can erase entire buffer contents - but didn't get
very far.  It should be possible though since these undos have "clear
boundaries" as for the comint case (hence you could try to have a look
at this - maybe you come up with a solution that works for both).  A
general solution would virtually have to undo every single action on the
undo list to check how a current non-undoable modification interferes
with undoable ones.

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

[Richard Stallman]

    In the old emacs version(s), it used to be that erase-buffer intentionally
    discarded undo information if I recall correctly. The buffer in question, namely
    "*sim*",  contained
    a voluminous output of a running simulator program and I simply want to
    throw away the contents from time to time. And thus, undo is not necessary
    for this buffer.

If you don't want it to collect undo information, do
M-x buffer-disable-undo, or (setq buffer-undo-list t).

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

[ishikawa]

Richard Stallman wrote:
>     In the old emacs version(s), it used to be that erase-buffer intentionally
>     discarded undo information if I recall correctly. The buffer in question, namely
>     "*sim*",  contained
>     a voluminous output of a running simulator program and I simply want to
>     throw away the contents from time to time. And thus, undo is not necessary
>     for this buffer.
> 
> If you don't want it to collect undo information, do
> M-x buffer-disable-undo, or (setq buffer-undo-list t).
> 

Thank you. I will do that.
(Makes me wonder, though, why I didn't get the warning when I ran "erase-buffer" 
before. Maybe the logic to show the warning has been improved...)

Chiaki Ishikawa