"No further undo information" clutters *Messages* buffer

"No further undo information" clutters *Messages* buffer

[martin rudalics]

Is it inevitable that `undo-more' raises an error when there is no
further undo information?  The "No further undo information"s clutter
the *Messages* buffer considerably and make it impracticable to spot
more important error messages.

Re: "No further undo information" clutters *Messages* buffer

[Richard M. Stallman]

    Is it inevitable that `undo-more' raises an error when there is no
    further undo information?

That seems like the right thing to do.

Re: "No further undo information" clutters *Messages* buffer

[martin rudalics]

 >     Is it inevitable that `undo-more' raises an error when there is no
 >     further undo information?
 >
 > That seems like the right thing to do.

Eventually

Undo!
undo-more: No further undo information

occupied more than 90% of my `*Messages*' buffer which made it quite
difficult to trace more interesting error messages.  I finally turned
this off by making `undo-more' display a non-logged message and ding
when there was no more undo information.  Hardly the right thing to do
but I didn't know better.

Ideally, I wanted `undo' issue `Undo...', `Redo...', etc. first.  If the
operation succeeded it would display `Undo...done', `Redo...done', etc.
Otherwise, it would issue `Undo...', `Redo...', etc. with the according
error text appended.  In any case `message_log_check_duplicate' would
take care of the rest.

Re: "No further undo information" clutters *Messages* buffer

[Kevin Rodgers]

martin rudalics wrote:
 >  >     Is it inevitable that `undo-more' raises an error when there is no
 >  >     further undo information?
 >  >
 >  > That seems like the right thing to do.
 >
 > Eventually
 >
 > Undo!
 > undo-more: No further undo information
 >
 > occupied more than 90% of my `*Messages*' buffer which made it quite
 > difficult to trace more interesting error messages.  I finally turned
 > this off by making `undo-more' display a non-logged message and ding
 > when there was no more undo information.  Hardly the right thing to do
 > but I didn't know better.

You could do that fairly cleanly with advice:

(defadvice undo-more (around disable-message-log activate)
   "Don't log \"No further undo information\" error messages."
   ;; Note that the "Undo!" messages are displayed by `undo', which
   ;; calls `undo-more' directly and via `undo-start'.   `undo-start'
   ;; also logs "No undo information in this buffer" error messages.
   (let ((message-log-max nil))
     ad-do-it))

 > Ideally, I wanted `undo' issue `Undo...', `Redo...', etc. first.  If the
 > operation succeeded it would display `Undo...done', `Redo...done', etc.
 > Otherwise, it would issue `Undo...', `Redo...', etc. with the according
 > error text appended.  In any case `message_log_check_duplicate' would
 > take care of the rest.

Hmmm...

-- 
Kevin Rodgers

Re: "No further undo information" clutters *Messages* buffer

[Richard M. Stallman]

    Eventually

    Undo!
    undo-more: No further undo information

    occupied more than 90% of my `*Messages*' buffer which made it quite
    difficult to trace more interesting error messages.

How did that happen?  From one sequence of undos, you'll only
get one such message.  So you must have done lots of sequences
of undos, and in each one, continued until you got an error.
It's not impossible, but it is strange and probably unusual.

Can you show us a complete, precise test case?

    Ideally, I wanted `undo' issue `Undo...', `Redo...', etc. first.  If the
    operation succeeded it would display `Undo...done', `Redo...done', etc.
    Otherwise, it would issue `Undo...', `Redo...', etc. with the according
    error text appended.  In any case `message_log_check_duplicate' would
    take care of the rest.

It already combines duplicate Undo! messages, so that you end up
with at most one of them from any sequence of undos.

Re: "No further undo information" clutters *Messages* buffer

[martin rudalics]

 >     Eventually
 >
 >     Undo!
 >     undo-more: No further undo information
 >
 >     occupied more than 90% of my `*Messages*' buffer which made it quite
 >     difficult to trace more interesting error messages.
 >
 > How did that happen?  From one sequence of undos, you'll only
 > get one such message.  So you must have done lots of sequences
 > of undos, and in each one, continued until you got an error.
 > It's not impossible, but it is strange and probably unusual.
 >
 > Can you show us a complete, precise test case?
 >

I'm using the recipe from the Emacs manual

    "If you notice that a buffer has been modified accidentally, the
easiest way to recover is to type `C-_' repeatedly until the stars
disappear from the front of the mode line."

In practice I "type `C-_' repeatedly" using the auto-repeat function of
that key.  When there's no more undo information, some time will pass by
until I take notice and release the key.  This way I issue some 10-20
undo commands in one sequence of undos.  With 2-3 three successful undos
the failing ones may get me nearly a page full of the messages cited
above.  Hence one sequence of undos typically produces something like

Undo! [2 times]
undo-more: No further undo information
Undo!
undo-more: No further undo information
Undo!
undo-more: No further undo information
Undo!
...

Maybe the auto-repeat rate of my keyboard is too high but I got too much
used to that as to change it.  Or should I try discarding my input for
pending undos and an empty pending-undo-list?  Anyway, if no one else
experiences this, it must be a consequence of my typing idiosyncrasies.

 >     Ideally, I wanted `undo' issue `Undo...', `Redo...', etc. first.  If the
 >     operation succeeded it would display `Undo...done', `Redo...done', etc.
 >     Otherwise, it would issue `Undo...', `Redo...', etc. with the according
 >     error text appended.  In any case `message_log_check_duplicate' would
 >     take care of the rest.
 >
 > It already combines duplicate Undo! messages, so that you end up
 > with at most one of them from any sequence of undos.
 >

But "Undo! \n undo-more: No further undo information" are two messages
occupying two lines and `message_log_check_duplicate' doesn't combine
entries comprising two lines.

Re: "No further undo information" clutters *Messages* buffer

[Richard M. Stallman]

Does this patch solve the problem?

*** simple.el	24 Oct 2005 18:07:24 -0400	1.758
--- simple.el	29 Oct 2005 10:34:00 -0400	
***************
*** 1344,1350 ****
    ;; and will get another error.  To begin undoing the undos,
    ;; you must type some other command.
    (let ((modified (buffer-modified-p))
! 	(recent-save (recent-auto-save-p)))
      ;; If we get an error in undo-start,
      ;; the next command should not be a "consecutive undo".
      ;; So set `this-command' to something other than `undo'.
--- 1344,1351 ----
    ;; and will get another error.  To begin undoing the undos,
    ;; you must type some other command.
    (let ((modified (buffer-modified-p))
! 	(recent-save (recent-auto-save-p))
! 	message)
      ;; If we get an error in undo-start,
      ;; the next command should not be a "consecutive undo".
      ;; So set `this-command' to something other than `undo'.
***************
*** 1373,1381 ****
      ;; so, ask the user whether she wants to skip the redo/undo pair.
      (let ((equiv (gethash pending-undo-list undo-equiv-table)))
        (or (eq (selected-window) (minibuffer-window))
! 	  (message (if undo-in-region
! 		       (if equiv "Redo in region!" "Undo in region!")
! 		     (if equiv "Redo!" "Undo!"))))
        (when (and (consp equiv) undo-no-redo)
  	;; The equiv entry might point to another redo record if we have done
  	;; undo-redo-undo-redo-... so skip to the very last equiv.
--- 1374,1382 ----
      ;; so, ask the user whether she wants to skip the redo/undo pair.
      (let ((equiv (gethash pending-undo-list undo-equiv-table)))
        (or (eq (selected-window) (minibuffer-window))
! 	  (setq message (if undo-in-region
! 			    (if equiv "Redo in region!" "Undo in region!")
! 			  (if equiv "Redo!" "Undo!"))))
        (when (and (consp equiv) undo-no-redo)
  	;; The equiv entry might point to another redo record if we have done
  	;; undo-redo-undo-redo-... so skip to the very last equiv.
***************
*** 1417,1423 ****
      ;; Record what the current undo list says,
      ;; so the next command can tell if the buffer was modified in between.
      (and modified (not (buffer-modified-p))
! 	 (delete-auto-save-file-if-necessary recent-save))))
  
  (defun buffer-disable-undo (&optional buffer)
    "Make BUFFER stop keeping undo information.
--- 1418,1427 ----
      ;; Record what the current undo list says,
      ;; so the next command can tell if the buffer was modified in between.
      (and modified (not (buffer-modified-p))
! 	 (delete-auto-save-file-if-necessary recent-save))
!     ;; Display a message announcing success.
!     (if message
! 	(message message))))
  
  (defun buffer-disable-undo (&optional buffer)
    "Make BUFFER stop keeping undo information.

Re: "No further undo information" clutters *Messages* buffer

[martin rudalics]

 > Does this patch solve the problem?
 >

It does, thank you.