* "No further undo information" clutters *Messages* buffer @ 2005-10-24 8:21 martin rudalics 2005-10-25 15:59 ` Richard M. Stallman 0 siblings, 1 reply; 8+ messages in thread From: martin rudalics @ 2005-10-24 8:21 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: "No further undo information" clutters *Messages* buffer 2005-10-24 8:21 "No further undo information" clutters *Messages* buffer martin rudalics @ 2005-10-25 15:59 ` Richard M. Stallman 2005-10-26 12:07 ` martin rudalics 0 siblings, 1 reply; 8+ messages in thread From: Richard M. Stallman @ 2005-10-25 15:59 UTC (permalink / raw) Cc: emacs-devel Is it inevitable that `undo-more' raises an error when there is no further undo information? That seems like the right thing to do. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: "No further undo information" clutters *Messages* buffer 2005-10-25 15:59 ` Richard M. Stallman @ 2005-10-26 12:07 ` martin rudalics 2005-10-26 16:11 ` Kevin Rodgers 2005-10-27 1:30 ` Richard M. Stallman 0 siblings, 2 replies; 8+ messages in thread From: martin rudalics @ 2005-10-26 12:07 UTC (permalink / raw) Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: "No further undo information" clutters *Messages* buffer 2005-10-26 12:07 ` martin rudalics @ 2005-10-26 16:11 ` Kevin Rodgers 2005-10-27 1:30 ` Richard M. Stallman 1 sibling, 0 replies; 8+ messages in thread From: Kevin Rodgers @ 2005-10-26 16:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: "No further undo information" clutters *Messages* buffer 2005-10-26 12:07 ` martin rudalics 2005-10-26 16:11 ` Kevin Rodgers @ 2005-10-27 1:30 ` Richard M. Stallman 2005-10-29 9:24 ` martin rudalics 1 sibling, 1 reply; 8+ messages in thread From: Richard M. Stallman @ 2005-10-27 1:30 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: "No further undo information" clutters *Messages* buffer 2005-10-27 1:30 ` Richard M. Stallman @ 2005-10-29 9:24 ` martin rudalics 2005-10-29 20:33 ` Richard M. Stallman 0 siblings, 1 reply; 8+ messages in thread From: martin rudalics @ 2005-10-29 9:24 UTC (permalink / raw) Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: "No further undo information" clutters *Messages* buffer 2005-10-29 9:24 ` martin rudalics @ 2005-10-29 20:33 ` Richard M. Stallman 2005-11-01 9:42 ` martin rudalics 0 siblings, 1 reply; 8+ messages in thread From: Richard M. Stallman @ 2005-10-29 20:33 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: "No further undo information" clutters *Messages* buffer 2005-10-29 20:33 ` Richard M. Stallman @ 2005-11-01 9:42 ` martin rudalics 0 siblings, 0 replies; 8+ messages in thread From: martin rudalics @ 2005-11-01 9:42 UTC (permalink / raw) Cc: emacs-devel > Does this patch solve the problem? > It does, thank you. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2005-11-01 9:42 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-10-24 8:21 "No further undo information" clutters *Messages* buffer martin rudalics 2005-10-25 15:59 ` Richard M. Stallman 2005-10-26 12:07 ` martin rudalics 2005-10-26 16:11 ` Kevin Rodgers 2005-10-27 1:30 ` Richard M. Stallman 2005-10-29 9:24 ` martin rudalics 2005-10-29 20:33 ` Richard M. Stallman 2005-11-01 9:42 ` martin rudalics
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.