GNU bug report logs -
#32581
24.4; make recover-file a prompt instead of a warning
Previous Next
Reported by: Glenn Linderman <v+python <at> g.nevcal.com>
Date: Thu, 30 Aug 2018 04:36:01 UTC
Severity: wishlist
Found in version 24.4
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 32581 in the body.
You can then email your comments to 32581 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32581
; Package
emacs
.
(Thu, 30 Aug 2018 04:36:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Glenn Linderman <v+python <at> g.nevcal.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Thu, 30 Aug 2018 04:36:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
--text follows this line--
I have emacs open a certain large file at boot-time startup, because the
Python
mode takes so long to parse it. So I guess I forgot to save last night,
did a windows shutdown, and this morning my work wasn't there... but
while emacs probably gave the warning, it was probably wiped out by the
next warning from the Python mode, and I don't sit there and watch my
computer boot up. So by the time I noticed stuff from last night was
missing, the recover file had been rewritten with the new edits.
So it would be nice to have an optional way to make that warning require
a response before disappearing.
In GNU Emacs 24.4.1 (x86_64-w64-mingw32)
of 2014-10-20 on KAEL
Windowing system distributor `Microsoft Corp.', version 6.3.9600
Configured using:
`configure --prefix=/z/emacs --host=x86_64-w64-mingw32
--target=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --with-wide-int
--with-jpeg --with-xpm --with-png --with-tiff --with-rsvg --with-xml2
--with-gnutls --with-xft --with-sound=yes --with-file-notification=yes
--without-dbus --without-imagemagick 'CFLAGS=-Ofast
-fomit-frame-pointer -funroll-loops -g0 -pipe' 'CPPFLAGS=-DNDEBUG
-DDBUS_STATIC_BUILD' 'LDFLAGS=-static-libgcc -static-libstdc++ -static
-s -Wl,-s''
Important settings:
value of $LANG: ENU
locale-coding-system: cp1252
Major mode: Py
Minor modes in effect:
shell-dirtrack-mode: t
which-function-mode: t
tooltip-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
size-indication-mode: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
<switch-frame> <switch-frame> <switch-frame> <switch-frame>
<switch-frame> <switch-frame> C-x C-f b m u <tab> o
<tab> <return> <help-echo> <help-echo> <help-echo>
<down-mouse-1> <mouse-1> <help-echo> <help-echo> <help-echo>
<help-echo> <escape> x r e p o r t - e m a c s - b
u g <return>
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Warning: no abbrev-file found, customize `abbrev-file-name' in order to
make mode-specific abbrevs work.
Load-path shadows:
None found.
Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils add-log python-mode derived skeleton advice
help-fns easymenu cl-macs thingatpt flymake rx shell pcomplete cc-cmds
cc-engine cc-vars cc-defs compile cl gv comint ansi-color ring
whitespace edmacro kmacro cl-loaddefs cl-lib which-func imenu jka-compr
easy-mmode time-date tooltip electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp w32-common-fns disp-table w32-win
w32-vars tool-bar dnd fontset image regexp-opt fringe tabulated-list
newcomment lisp-mode prog-mode register page menu-bar rfn-eshadow timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer nadvice loaddefs button faces cus-face macroexp
files text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
w32notify w32 multi-tty emacs)
Memory information:
((conses 16 333400 168725)
(symbols 56 23740 0)
(miscs 48 54 117)
(strings 32 28683 7091)
(string-bytes 1 973909)
(vectors 16 30900)
(vector-slots 8 699691 5651)
(floats 8 83 359)
(intervals 56 741 1184)
(buffers 960 12))
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32581
; Package
emacs
.
(Sat, 13 Jul 2019 02:44:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 32581 <at> debbugs.gnu.org (full text, mbox):
Glenn Linderman <v+python <at> g.nevcal.com> writes:
> I have emacs open a certain large file at boot-time startup, because
> the Python mode takes so long to parse it. So I guess I forgot to save
> last night, did a windows shutdown, and this morning my work wasn't
> there... but while emacs probably gave the warning, it was probably
> wiped out by the next warning from the Python mode, and I don't sit
> there and watch my computer boot up. So by the time I noticed stuff
> from last night was missing, the recover file had been rewritten with
> the new edits.
If I understand you correctly (and I may not), you're saying that when
you open a Python file that has an auto-saved file, then Emacs says that
an auto-saved file exists... and then Python mode issues a message that
overwrites that message?
What is that Python-mode message?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32581
; Package
emacs
.
(Sat, 13 Jul 2019 03:49:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 32581 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 7/12/2019 7:42 PM, Lars Ingebrigtsen wrote:
> Glenn Linderman <v+python <at> g.nevcal.com> writes:
>
>> I have emacs open a certain large file at boot-time startup, because
>> the Python mode takes so long to parse it. So I guess I forgot to save
>> last night, did a windows shutdown, and this morning my work wasn't
>> there... but while emacs probably gave the warning, it was probably
>> wiped out by the next warning from the Python mode, and I don't sit
>> there and watch my computer boot up. So by the time I noticed stuff
>> from last night was missing, the recover file had been rewritten with
>> the new edits.
> If I understand you correctly (and I may not), you're saying that when
> you open a Python file that has an auto-saved file, then Emacs says that
> an auto-saved file exists... and then Python mode issues a message that
> overwrites that message?
>
> What is that Python-mode message?
>
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."
And I find the following line in my .emacs file:
(add-to-list 'load-path "d:/my/py/emacs/python-mode.el-6.1.1")
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32581
; Package
emacs
.
(Sat, 13 Jul 2019 13:37:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 32581 <at> debbugs.gnu.org (full text, mbox):
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.
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?
Would that make sense?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32581
; Package
emacs
.
(Sat, 13 Jul 2019 16:25:02 GMT)
Full text and
rfc822 format available.
Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):
On 13.07.19 15:35, 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.
>
> 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?
>
> Would that make sense?
>
Hi,
python-mode.el developer here. As for the abbrev-file-name, assume
that's a general warning from Emacs.
Looking for the value of abbrev-file-name and creating a file of that
name if not existing should silence that warning.
Also auto-save issue seems not mode-related.
BTW bug-reports are welcome at
https://gitlab.com/python-mode-devs/python-mode/issues
Best,
Andreas
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32581
; Package
emacs
.
(Sun, 14 Jul 2019 02:12:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 32581 <at> debbugs.gnu.org (full text, mbox):
[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)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32581
; Package
emacs
.
(Sun, 14 Jul 2019 12:51:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 32581 <at> debbugs.gnu.org (full text, mbox):
Glenn Linderman <v+python <at> g.nevcal.com> writes:
> 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.
Yes, I think that warning about the auto-saved file when you try to edit
the new file has possibilities... I'm wondering whether there would be
any adverse effects somehow. Emacs has a number of things that warn
about editing files -- that it's changed on disk, or that another Emacs
process has the file locked, and now checking for auto-saved files in
the same area would perhaps add unforeseen complications.
But perhaps we should just try and see what it feels like in practice.
> 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.
We do have a very primitive sort of message priority -- i.e., we have
some things that are so bad that we pop up the *Warnings* buffer. But I
think that's too intrusive for auto-saved files.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32581
; Package
emacs
.
(Sun, 14 Jul 2019 12:56:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 32581 <at> debbugs.gnu.org (full text, mbox):
Andreas Röhler <andreas.roehler <at> easy-emacs.de> writes:
> python-mode.el developer here. As for the abbrev-file-name, assume
> that's a general warning from Emacs.
>
> Looking for the value of abbrev-file-name and creating a file of that
> name if not existing should silence that warning.
>
> Also auto-save issue seems not mode-related.
Yes, this isn't really a python-mode issue...
> BTW bug-reports are welcome at
> https://gitlab.com/python-mode-devs/python-mode/issues
... but there are a number of python-mode bugs in the Emacs bug tracker.
Looks like about 40-ish, with an additional ten that are in the
intersection of python mode and CEDET.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32581
; Package
emacs
.
(Sun, 14 Jul 2019 17:05:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 32581 <at> debbugs.gnu.org (full text, mbox):
On 14.07.19 14:55, Lars Ingebrigtsen wrote:
>
> Yes, this isn't really a python-mode issue...
>
>> BTW bug-reports are welcome at
>> https://gitlab.com/python-mode-devs/python-mode/issues
> ... but there are a number of python-mode bugs in the Emacs bug tracker.
> Looks like about 40-ish, with an additional ten that are in the
> intersection of python mode and CEDET.
>
Understood a fairly old version of python-mode.el was mentioned in this
report, not python.el developed here.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32581
; Package
emacs
.
(Sun, 14 Jul 2019 17:19:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 32581 <at> debbugs.gnu.org (full text, mbox):
Andreas Röhler <andreas.roehler <at> easy-emacs.de> writes:
> Understood a fairly old version of python-mode.el was mentioned in
> this report, not python.el developed here.
Ah, I see.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32581
; Package
emacs
.
(Mon, 07 Feb 2022 04:14:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 32581 <at> debbugs.gnu.org (full text, mbox):
Glenn Linderman <v+python <at> g.nevcal.com> writes:
> 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."
(I'm going through old bug reports that unfortunately weren't resolved
at the time.)
I can't find that message in the Emacs tree, so I guess it's coming from
a third party package?
In any case, I think we decided to not make recover-file into a prompt,
so I think the problem here really is that warning message, which seems
unhelpful and excessive. Therefore I don't really think there's
anything much to be done on the Emacs side, and I'm closing this bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug closed, send any further explanations to
32581 <at> debbugs.gnu.org and Glenn Linderman <v+python <at> g.nevcal.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Mon, 07 Feb 2022 04:14:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 07 Mar 2022 12:24:10 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 49 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.