Re: recover-file warnings too easy to get covered up

Re: recover-file warnings too easy to get covered up

[Dan Jacobson]

d>     The vital minibuffer message
d>        [file] has auto save data; consider M-x recover-file
d>     gets overwritten before the user has time to notice it, with

r> What command produces that message?

Simple,
$ emacs x.sh
Type some stuff, then ^Z suspend, kill -1 %1, leaving a #x.sh# file, then
$ emacs x.sh #again, and look at the *Messages* buffer.
You would have to happen to be looking at the minibuffer during the
vital second the "consider M-x recover-file" message is displayed to
see it before it gets covered up. I recall this issue is not new.
So how are you going to make sure the user sees that message before
blithely editing that file?  Or is e.g., "Indentation setup for shell type
bash" more important for him to see as he assess the screen once the
smoke clears?

Re: recover-file warnings too easy to get covered up

[Kevin Rodgers]

Dan Jacobson wrote:
> d>     The vital minibuffer message
> d>        [file] has auto save data; consider M-x recover-file
> d>     gets overwritten before the user has time to notice it, with
> 
> r> What command produces that message?
> 
> Simple,
> $ emacs x.sh
> Type some stuff, then ^Z suspend, kill -1 %1, leaving a #x.sh# file, then
> $ emacs x.sh #again, and look at the *Messages* buffer.
> You would have to happen to be looking at the minibuffer during the
> vital second the "consider M-x recover-file" message is displayed to
> see it before it gets covered up. I recall this issue is not new.
> So how are you going to make sure the user sees that message before
> blithely editing that file?  Or is e.g., "Indentation setup for shell type
> bash" more important for him to see as he assess the screen once the
> smoke clears?

As this cond clause from after-find-file shows, the maintainers clearly
believe that the message is not vital (it is not-serious):

	     ((not buffer-read-only)
	      (if (and warn
		       ;; No need to warn if buffer is auto-saved
		       ;; under the name of the visited file.
		       (not (and buffer-file-name
				 auto-save-visited-file-name))
		       (file-newer-than-file-p (or buffer-auto-save-file-name
						   (make-auto-save-file-name))
					       buffer-file-name))
		  (format "%s has auto save data; consider M-x recover-this-file"
			  (file-name-nondirectory buffer-file-name))
		(setq not-serious t)
		(if error "(New file)" nil)))
-- 
Kevin Rodgers

Re: recover-file warnings too easy to get covered up

[Richard M. Stallman]

    > So how are you going to make sure the user sees that message before
    > blithely editing that file?  Or is e.g., "Indentation setup for shell type
    > bash" more important for him to see as he assess the screen once the
    > smoke clears?

    As this cond clause from after-find-file shows, the maintainers clearly
    believe that the message is not vital (it is not-serious):

It is not "serious" because it does not impede correct visiting of the
file.  We could treat it as "serious" if that is clearly better.

recover-file warnings too easy to get covered up

[Dan Jacobson]

The vital minibuffer message
   fetchmailrc has auto save data; consider M-x recover-file
gets overwritten before the user has time to notice it, with
   Loading sh-script...
   Loading easy-mmode...done
   Loading sh-script...done
   Setting up indent for shell type bash
   Loading mule-util...done
   setting up indent stuff
   Indentation variable are now local.
   Indentation setup for shell type bash
if the file contains # -*-Shell-script-*- at top.
Anyway, the user might have not come back from the restroom, so I
would ask him a yes-or-no, and not just hope he saw it.
emacs-version"21.4.1"