warning about undo info being discarded when in *Backtrace*

warning about undo info being discarded when in *Backtrace*

[Drew Adams]

1. I'm in the debugger, and the result of a given debugger step is a large
value. It is first printed in buffer *Backtrace* and then later erased. A
*Warning* buffer pops up saying "Warning (undo): Buffer `*Backtrace*' undo
info was 47119441 bytes long. The undo info was discarded because it
exceeded `undo-outer-limit'." That variable's value is 3,000,000.

I can customize `warning-suppress-types' to add (undo discard-info), but I
wonder if users should ever get such a warning when in *Backtrace*. WDOT?
Should such a warning be contextual, dependent on the kind of buffer? I
would want to be informed of a large change in a text or code buffer, but
not in *Backtrace*.


2. This warning is simply appended to buffer *Warning* each time, with no
separation between the various warnings. Shouldn't there be a ^L page
separator or a separator line of `-' chars? And should such a long warning
just be appended literally each time? Perhaps after the first time a
shortened version of the warning could be printed instead?  For example:

----------8<-------------

 Warning (undo): Buffer `*Backtrace*' undo info was 47119441 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'.

 -----------------------------------------------------

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

 -----------------------------------------------------

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

----------8<-------------


3. For this particular warning, does it make sense to repeat the warning
all? If undo was disabled in *Backtrace*, then it is still disabled, no? I
might be mistaken here, however: It's possible that each warning was issued
after the *Backtrace* was entered anew. The warning would presumably be
issued only when undo was enabled and it became disabled.


4. Isn't it inappropriate to include this sentence in the warning: "If you
did not execute any such command, the situation is probably due to a bug and
you should report it"? That sounds ridiculous, to me.

It's always the case that if Emacs seems to be doing something wrong then
you can file a bug. Why is this mentioned only here? It gives the impression
that we expect the code that produces the warning to be bugged. And that
takes away from the _warning_ aspect; it makes it sound like a Chicken
Little exclamation. It's as if we were saying "Emergency!!!!! Oh, but there
might be no emergency. If you think we're mistaken, send a bug report".

Re: warning about undo info being discarded when in *Backtrace*

[Davis Herring]

> 3. For this particular warning, does it make sense to repeat the warning
> all? If undo was disabled in *Backtrace*, then it is still disabled, no? I
> might be mistaken here, however: It's possible that each warning was
> issued
> after the *Backtrace* was entered anew. The warning would presumably be
> issued only when undo was enabled and it became disabled.

When the undo info is discarded, undo remains enabled in the affected
buffer.  Future large changes thus cause it to be discarded again.

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: warning about undo info being discarded when in *Backtrace*

[Drew Adams]

> > 3. For this particular warning, does it make sense to repeat the warning
> > all? If undo was disabled in *Backtrace*, then it is still
> disabled, no? I
> > might be mistaken here, however: It's possible that each warning was
> > issued
> > after the *Backtrace* was entered anew. The warning would presumably be
> > issued only when undo was enabled and it became disabled.
>
> When the undo info is discarded, undo remains enabled in the affected
> buffer.  Future large changes thus cause it to be discarded again.

I see. I think I misread "discarded" for "disabled". Perhaps the verbose
version of the warning could explicitly mention that undo is still enabled,
so future undo info will be retained.

Re: warning about undo info being discarded when in *Backtrace*

[Richard Stallman]

How about turning off undo information in *Backtrace*?
As far as I know, there is no use for any.

Please try this patch.

*** debug.el	25 Jul 2007 11:49:15 -0400	1.101.2.1
--- debug.el	09 Oct 2007 22:44:24 -0400	
***************
*** 269,274 ****
--- 269,275 ----
    (setq buffer-read-only nil)
    (erase-buffer)
    (set-buffer-multibyte nil)
+   (setq buffer-undo-list t)
    (let ((standard-output (current-buffer))
  	(print-escape-newlines t)
  	(print-level 8)

RE: warning about undo info being discarded when in *Backtrace*

[Drew Adams]

> How about turning off undo information in *Backtrace*?
> As far as I know, there is no use for any.

I almost mentioned that too. I did not, thinking that someone might want to
edit a sexp in the buffer to use as a return value, and then undo the edit
to see better what was there before, etc. Or s?he might want to paste a
value into the buffer as return value, and use undo during editing of the
value in place.

Ohter than a use such as that, I can't think of a good reason for having
undo in *Backtrace*.

I didn't try the patch (but it would seem to turn off undo OK).

Re: warning about undo info being discarded when in *Backtrace*

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

>> How about turning off undo information in *Backtrace*?
>> As far as I know, there is no use for any.
>
> I almost mentioned that too. I did not, thinking that someone might want to
> edit a sexp in the buffer to use as a return value,

Is that even possible? I think you'd use "r" or something and then do
the editing in the minibuffer after pasting there.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

RE: warning about undo info being discarded when in *Backtrace*

[Drew Adams]

> >> How about turning off undo information in *Backtrace*?
> >> As far as I know, there is no use for any.
> >
> > I almost mentioned that too. I did not, thinking that someone
> > might want to edit a sexp in the buffer to use as a return value,
>
> Is that even possible? I think you'd use "r" or something and then do
> the editing in the minibuffer after pasting there.

Perhaps you're right: someone could certainly copy something from
*Backtrace* to the minibuffer and edit it there. But someone else might find
it convenient to edit it in *Backtrace* (in context) before copying. Dunno
if that's worthwhile.

The question is whether there is a real need for undo in *Backtrace*. I
don't see a need for it, but the question is open, for now. Anyone see such
a need?