GNU bug report logs - #32581
24.4; make recover-file a prompt instead of a warning

Previous Next

Full log

View this message in rfc822 format

From: Glenn Linderman <v+python <at> g.nevcal.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 32581 <at> debbugs.gnu.org
Subject: bug#32581: 24.4; make recover-file a prompt instead of a warning
Date: Sat, 13 Jul 2019 19:10:56 -0700

[Message part 1 (text/plain, inline)]

On 7/13/2019 6:35 AM, Lars Ingebrigtsen wrote:
> Glenn Linderman <v+python <at> g.nevcal.com> writes:
>
>> I think you understood correctly.  I'm not sure what version of which
>> Python-mode I have, but could probably figure it out somehow (I love emacs,
>> because it has extensions, but I'm not real good at writing or understanding
>> elisp: I use other people's extensions, mostly, and a bit of cut-n-paste
>> programming for a few more customizations).
>>
>> Probably the following message, that I get every time I open the file.
>>
>> "Warning: no abbrev-file found, customize `abbrev-file-name' in order to make
>> mode-specific abbrevs work."
> Right.  Some modes are chatty at startup and hides warnings you're
> interested in.
>
> It's perfectly valid to not want to load an autosaved file, and making
> Emacs prompt would be an inconvenience, in my opinion.

I agree that a prompt (a forced interaction) would not be appropriate.
> Perhaps Emacs should treat auto-saved files a bit more like what it does
> with files that have changed?  I.e., if you try to edit a file with an
> auto-save file, it should prompt you something like "foo has auto save
> data; really edit the buffer?" or something?

This is a very interesting idea. It is only when you go to edit that you 
would lose the auto-save file, so that would be a "last-chance" to 
retrieve your data, and you would be interacting with the file at that 
point anyway, so a forced interaction would be less intrusive than at 
load time.

> Would that make sense?
>
That would certainly be safer than the current behavior, but would add 
the forced interaction.

My thought was more along the lines of some sort of message priority, 
where informational messages like the abbrev-file-name warning could not 
override a more important message... Of course, everyone thinks there 
message is most important, so that might be difficult to enforce or rank.

Another idea is that multiple messages could be displayed concurrently 
in an expanding echo area, and that none would vanish until the first 
user interaction. That way, when the user turns their attention to the 
emacs window again, all the messages from startup activities would be 
visible until the first keystroke or significant mouse operation (more 
than just a click) for the window occurs. This wouldn't require a forced 
interaction, and wouldn't require ranking message priorities, but would 
allow the user an opportunity to see all the startup messages. And it 
could generalize to non-startup situations: any occasion when macros or 
scripts are running and produce multiple messages without user 
interaction might want to grow the echo area to display them until there 
is another required user interaction.

Thanks for considering the possibility of enhancing something in this 
area, as it was a significant amount of work that was lost, and it could 
potentially happen again, and not just to me (I'm a little sensitized to 
the possibility now, others may not yet be).

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.