bug#28843: 26.0.90; gnus kills unsaved message buffer

bug#28843: 26.0.90; gnus kills unsaved message buffer

[Nick Helm]

When gnus is the mail-user-agent, quitting gnus causes unsaved messages
to be lost.

Emacs -Q
(setq mail-user-agent 'gnus-user-agent)
M-x gnus
C-x 5 m "xxx" ;make and modify a new message
C-x 5 b "*Group*" ;back to gnus
q, yes

Gnus exits, and the unsaved message buffer dies with it, without prompts
to save.


In GNU Emacs 26.0.90 (build 1, x86_64-apple-darwin16.7.0, NS appkit-1504.83 Version 10.12.6 (Build 16G29))
 of 2017-10-15 built on oberon
Windowing system distributor 'Apple', version 10.3.1504
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Emacs start-up time: 0.2 seconds

Configured features:
JPEG NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS LCMS2

Important settings:
  value of $LANG: en_NZ.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Text

Minor modes in effect:
  savehist-mode: t
  global-eldoc-mode: t
  mouse-wheel-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
  visual-line-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime
smime dig mailcap gnus-sum gnus-group gnus-undo gnus-start gnus-cloud
nnimap nnmail mail-source tls gnutls utf7 netrc nnoo parse-time
gnus-spec gnus-int gnus-range gnus-win gnus nnheader wid-edit emacsbug
message rmc puny seq byte-opt bytecomp byte-compile cconv format-spec
rfc822 mml mml-sec password-cache epa derived epg epg-config gnus-util
rmail rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils time dired-x easymenu dired dired-loaddefs
pcase savehist nh-macdict easy-mmode iso-transl edmacro kmacro
cl-loaddefs cl-lib gv plain-theme time-date tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel term/ns-win ns-win
ucs-normalize mule-util term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded 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 kqueue cocoa ns lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 262303 8886)
 (symbols 48 26274 4)
 (miscs 40 38 132)
 (strings 32 47796 1277)
 (string-bytes 1 1405572)
 (vectors 16 40422)
 (vector-slots 8 763529 24867)
 (floats 8 202 17)
 (intervals 56 206 0)
 (buffers 992 11))

bug#28843: 26.0.90; gnus kills unsaved message buffer

[Nick Helm]

On Sun, 15 Oct 2017 at 20:46:25 +1300, Nick Helm wrote:

> When gnus is the mail-user-agent, quitting gnus causes unsaved messages
> to be lost.
>
> Emacs -Q
> (setq mail-user-agent 'gnus-user-agent)
> M-x gnus
> C-x 5 m "xxx" ;make and modify a new message
> C-x 5 b "*Group*" ;back to gnus
> q, yes
>
> Gnus exits, and the unsaved message buffer dies with it, without prompts
> to save.

I got stung by this one again today, so I did a bit more looking into it.

It seems the behaviour is intentional (see bug#26862 and commit
4b35dd653d35ba95c4d304bee69b69d41301ec3b).

This commit changed `gnus-clear-system' to include this:

  #+begin_src emacs-lisp
  ;; Kill Gnus buffers.
  (do-auto-save t)
  (dolist (buffer (gnus-buffers))
    (when (gnus-buffer-exists-p buffer)
      (with-current-buffer buffer
  	   (set-buffer-modified-p nil)
  	   (when (local-variable-p 'kill-buffer-hook)
  	     (setq kill-buffer-hook nil))))
    (gnus-kill-buffer buffer))
  #+end_src

So gnus is at least auto-saving draft messages before zapping them.

Is there a better way to do this though? I think the user should at
least have some warning that an unsaved buffer is about to be
automatically killed.

Also, relying on auto-save means the next time I save a draft message
(either manually or automatically) it silently clobbers the previous
auto-save. At least that's what I see here. Only the latest draft is
retained.

bug#28843: 26.0.90; gnus kills unsaved message buffer

[Nick Helm]

On Thu, 26 Oct 2017 at 13:52:13 +1300, Nick Helm wrote:

> On Sun, 15 Oct 2017 at 20:46:25 +1300, Nick Helm wrote:
>
>> Gnus exits, and the unsaved message buffer dies with it, without prompts
>> to save.
>
> It seems the behaviour is intentional ... This commit changed
> `gnus-clear-system' to include this:
>
>   #+begin_src emacs-lisp
>   ;; Kill Gnus buffers.
>   (do-auto-save t)
>   (dolist (buffer (gnus-buffers))
>     (when (gnus-buffer-exists-p buffer)
>       (with-current-buffer buffer
>   	   (set-buffer-modified-p nil)
>   	   (when (local-variable-p 'kill-buffer-hook)
>   	     (setq kill-buffer-hook nil))))
>     (gnus-kill-buffer buffer))
>   #+end_src
>
> So gnus is at least auto-saving draft messages before zapping them.
>
> Is there a better way to do this though? I think the user should at
> least have some warning that an unsaved buffer is about to be
> automatically killed.

One solution (though not a very good one IMHO) would be to make the
auto-save depend on the user's value of guns-interactive-exit. For
example:

--- a/lisp/gnus/gnus-start.el	2017-10-26 12:49:43.000000000 +1300
+++ b/lisp/gnus/gnus-start.el	2017-10-26 12:45:12.000000000 +1300
@@ -731,11 +731,12 @@
     (kill-buffer (get-file-buffer (gnus-newsgroup-kill-file nil))))
   (gnus-kill-buffer nntp-server-buffer)
   ;; Kill Gnus buffers.
-  (do-auto-save t)
   (dolist (buffer (gnus-buffers))
     (when (gnus-buffer-exists-p buffer)
       (with-current-buffer buffer
-	(set-buffer-modified-p nil)
+        (unless gnus-interactive-exit
+          (do-auto-save t t)
+	(set-buffer-modified-p nil))
 	(when (local-variable-p 'kill-buffer-hook)
 	  (setq kill-buffer-hook nil))))
     (gnus-kill-buffer buffer))

bug#28843: 26.0.90; gnus kills unsaved message buffer

[Eric Abrahamsen]

Nick Helm <nick@tenpoint.co.nz> writes:

> On Thu, 26 Oct 2017 at 13:52:13 +1300, Nick Helm wrote:
>
>> On Sun, 15 Oct 2017 at 20:46:25 +1300, Nick Helm wrote:
>>
>>> Gnus exits, and the unsaved message buffer dies with it, without prompts
>>> to save.
>>
>> It seems the behaviour is intentional ... This commit changed
>> `gnus-clear-system' to include this:
>>
>>   #+begin_src emacs-lisp
>>   ;; Kill Gnus buffers.
>>   (do-auto-save t)
>>   (dolist (buffer (gnus-buffers))
>>     (when (gnus-buffer-exists-p buffer)
>>       (with-current-buffer buffer
>>   	   (set-buffer-modified-p nil)
>>   	   (when (local-variable-p 'kill-buffer-hook)
>>   	     (setq kill-buffer-hook nil))))
>>     (gnus-kill-buffer buffer))
>>   #+end_src
>>
>> So gnus is at least auto-saving draft messages before zapping them.
>>
>> Is there a better way to do this though? I think the user should at
>> least have some warning that an unsaved buffer is about to be
>> automatically killed.
>
> One solution (though not a very good one IMHO) would be to make the
> auto-save depend on the user's value of guns-interactive-exit. For
> example:
>
> --- a/lisp/gnus/gnus-start.el	2017-10-26 12:49:43.000000000 +1300
> +++ b/lisp/gnus/gnus-start.el	2017-10-26 12:45:12.000000000 +1300
> @@ -731,11 +731,12 @@
>      (kill-buffer (get-file-buffer (gnus-newsgroup-kill-file nil))))
>    (gnus-kill-buffer nntp-server-buffer)
>    ;; Kill Gnus buffers.
> -  (do-auto-save t)
>    (dolist (buffer (gnus-buffers))
>      (when (gnus-buffer-exists-p buffer)
>        (with-current-buffer buffer
> -	(set-buffer-modified-p nil)
> +        (unless gnus-interactive-exit
> +          (do-auto-save t t)
> +	(set-buffer-modified-p nil))
>  	(when (local-variable-p 'kill-buffer-hook)
>  	  (setq kill-buffer-hook nil))))
>      (gnus-kill-buffer buffer))

We could also consider mirroring the behavior of Emacs itself: if
`gnus-interactive-exit' is non-nil, prompt the user whether to save
changed buffers or not.

bug#28843: 26.0.90; gnus kills unsaved message buffer

[Nick Helm]

On Tue,  7 Nov 2017 at 18:41:24 -0800, Eric Abrahamsen wrote:

> Nick Helm <nick@tenpoint.co.nz> writes:
>
>> On Thu, 26 Oct 2017 at 13:52:13 +1300, Nick Helm wrote:
>>
>>> On Sun, 15 Oct 2017 at 20:46:25 +1300, Nick Helm wrote:
>>>
>>>> Gnus exits, and the unsaved message buffer dies with it, without prompts
>>>> to save.
>>>
>>> It seems the behaviour is intentional ... This commit changed
>>> `gnus-clear-system' to include this:
>>>
>>>   #+begin_src emacs-lisp
>>>   ;; Kill Gnus buffers.
>>>   (do-auto-save t)
>>>   (dolist (buffer (gnus-buffers))
>>>     (when (gnus-buffer-exists-p buffer)
>>>       (with-current-buffer buffer
>>>   	   (set-buffer-modified-p nil)
>>>   	   (when (local-variable-p 'kill-buffer-hook)
>>>   	     (setq kill-buffer-hook nil))))
>>>     (gnus-kill-buffer buffer))
>>>   #+end_src
>>>
>>> So gnus is at least auto-saving draft messages before zapping them.
>>>
>>> Is there a better way to do this though? I think the user should at
>>> least have some warning that an unsaved buffer is about to be
>>> automatically killed.
>>
>> One solution (though not a very good one IMHO) would be to make the
>> auto-save depend on the user's value of guns-interactive-exit. For
>> example:
>>
>> --- a/lisp/gnus/gnus-start.el	2017-10-26 12:49:43.000000000 +1300
>> +++ b/lisp/gnus/gnus-start.el	2017-10-26 12:45:12.000000000 +1300
>> @@ -731,11 +731,12 @@
>>      (kill-buffer (get-file-buffer (gnus-newsgroup-kill-file nil))))
>>    (gnus-kill-buffer nntp-server-buffer)
>>    ;; Kill Gnus buffers.
>> -  (do-auto-save t)
>>    (dolist (buffer (gnus-buffers))
>>      (when (gnus-buffer-exists-p buffer)
>>        (with-current-buffer buffer
>> -	(set-buffer-modified-p nil)
>> +        (unless gnus-interactive-exit
>> +          (do-auto-save t t)
>> +	(set-buffer-modified-p nil))
>>  	(when (local-variable-p 'kill-buffer-hook)
>>  	  (setq kill-buffer-hook nil))))
>>      (gnus-kill-buffer buffer))
>
> We could also consider mirroring the behavior of Emacs itself: if
> `gnus-interactive-exit' is non-nil, prompt the user whether to save
> changed buffers or not.

Yes, that would be better. 

One way to do that might be to kill unsaved message buffers earlier in
the gnus exit process, say with `gnus-exit-gnus-hook', and rely on
Emacs's standard unsaved buffer query to do `save-buffer' or
`message-dont-send'. Gnus is still running at that point, so it should
save to the drafts group just fine.

Also, the doc for `message-dont-send' says it does an auto-save, but the
code says it actually does `save-buffer'. 

bug#28843: 26.0.90; gnus kills unsaved message buffer

[Eric Abrahamsen]

Nick Helm <nick@tenpoint.co.nz> writes:

> On Tue,  7 Nov 2017 at 18:41:24 -0800, Eric Abrahamsen wrote:
>
>> Nick Helm <nick@tenpoint.co.nz> writes:
>>
>>> On Thu, 26 Oct 2017 at 13:52:13 +1300, Nick Helm wrote:
>>>
>>>> On Sun, 15 Oct 2017 at 20:46:25 +1300, Nick Helm wrote:
>>>>
>>>>> Gnus exits, and the unsaved message buffer dies with it, without prompts
>>>>> to save.
>>>>
>>>> It seems the behaviour is intentional ... This commit changed
>>>> `gnus-clear-system' to include this:
>>>>
>>>>   #+begin_src emacs-lisp
>>>>   ;; Kill Gnus buffers.
>>>>   (do-auto-save t)
>>>>   (dolist (buffer (gnus-buffers))
>>>>     (when (gnus-buffer-exists-p buffer)
>>>>       (with-current-buffer buffer
>>>>   	   (set-buffer-modified-p nil)
>>>>   	   (when (local-variable-p 'kill-buffer-hook)
>>>>   	     (setq kill-buffer-hook nil))))
>>>>     (gnus-kill-buffer buffer))
>>>>   #+end_src
>>>>
>>>> So gnus is at least auto-saving draft messages before zapping them.
>>>>
>>>> Is there a better way to do this though? I think the user should at
>>>> least have some warning that an unsaved buffer is about to be
>>>> automatically killed.
>>>
>>> One solution (though not a very good one IMHO) would be to make the
>>> auto-save depend on the user's value of guns-interactive-exit. For
>>> example:
>>>
>>> --- a/lisp/gnus/gnus-start.el	2017-10-26 12:49:43.000000000 +1300
>>> +++ b/lisp/gnus/gnus-start.el	2017-10-26 12:45:12.000000000 +1300
>>> @@ -731,11 +731,12 @@
>>>      (kill-buffer (get-file-buffer (gnus-newsgroup-kill-file nil))))
>>>    (gnus-kill-buffer nntp-server-buffer)
>>>    ;; Kill Gnus buffers.
>>> -  (do-auto-save t)
>>>    (dolist (buffer (gnus-buffers))
>>>      (when (gnus-buffer-exists-p buffer)
>>>        (with-current-buffer buffer
>>> -	(set-buffer-modified-p nil)
>>> +        (unless gnus-interactive-exit
>>> +          (do-auto-save t t)
>>> +	(set-buffer-modified-p nil))
>>>  	(when (local-variable-p 'kill-buffer-hook)
>>>  	  (setq kill-buffer-hook nil))))
>>>      (gnus-kill-buffer buffer))
>>
>> We could also consider mirroring the behavior of Emacs itself: if
>> `gnus-interactive-exit' is non-nil, prompt the user whether to save
>> changed buffers or not.
>
> Yes, that would be better. 
>
> One way to do that might be to kill unsaved message buffers earlier in
> the gnus exit process, say with `gnus-exit-gnus-hook', and rely on
> Emacs's standard unsaved buffer query to do `save-buffer' or
> `message-dont-send'. Gnus is still running at that point, so it should
> save to the drafts group just fine.

I guess it might be better to create an explicit function to do this. If
you look at `gnus-group-exit' versus `gnus-group-quit', the former calls
`gnus-offer-save-summaries' while the latter does not. I think the
offer-save-summaries situation is analogous to draft saving: ie, "group
quit" is expected to discard data; "group exit" is not.

For extra safety we could check `gnus-expert-user' and, if it's nil,
prompt anyway.

If the function were called a bit earlier, the prompt could also allow a
key saying "whoops, I didn't want to quit after all", which would abort
the process.

> Also, the doc for `message-dont-send' says it does an auto-save, but the
> code says it actually does `save-buffer'. 

I think that's just poor doc wording -- obviously we can't actually call
`do-auto-save' there, I think this "auto-save" just shorthand for
"automatically save".

bug#28843: 26.0.90; gnus kills unsaved message buffer

[Lars Ingebrigtsen]

Nick Helm <nick@tenpoint.co.nz> writes:

> One way to do that might be to kill unsaved message buffers earlier in
> the gnus exit process, say with `gnus-exit-gnus-hook', and rely on
> Emacs's standard unsaved buffer query to do `save-buffer' or
> `message-dont-send'. Gnus is still running at that point, so it should
> save to the drafts group just fine.

But haven't the buffers already been saved earlier in the shutdown by a
`do-auto-save'?  That how I interpret Katsumi in bug#26862...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#28843: 26.0.90; gnus kills unsaved message buffer

[Nick Helm]

On Thu, 12 Apr 2018 at 09:32:40 +1200, Lars Ingebrigtsen wrote:

> Nick Helm <nick@tenpoint.co.nz> writes:
>
>> One way to do that might be to kill unsaved message buffers earlier in
>> the gnus exit process, say with `gnus-exit-gnus-hook', and rely on
>> Emacs's standard unsaved buffer query to do `save-buffer' or
>> `message-dont-send'. Gnus is still running at that point, so it should
>> save to the drafts group just fine.
>
> But haven't the buffers already been saved earlier in the shutdown by a
> `do-auto-save'?  That how I interpret Katsumi in bug#26862...

Yes they have, but I was suggesting to remove that auto-save mechanism
and find a way to prompt the user to save the draft instead, mimicking
what happens when Emacs is shut down with an unsaved buffer.

bug#28843: 26.0.90; gnus kills unsaved message buffer

[Lars Ingebrigtsen]

Nick Helm <nick@tenpoint.co.nz> writes:

>> But haven't the buffers already been saved earlier in the shutdown by a
>> `do-auto-save'?  That how I interpret Katsumi in bug#26862...
>
> Yes they have, but I was suggesting to remove that auto-save mechanism
> and find a way to prompt the user to save the draft instead, mimicking
> what happens when Emacs is shut down with an unsaved buffer.

Yeah, the Messsage buffers are kinda special, I guess, in that they're
basically the only Gnus buffers what aren't generated somehow.

So handling them the same way as Emacs does on shutdown does make some
sense...  On the other hand, even if we prompt the user, they're still
saved to a pretty obscure place (i.e., the drafts group), so I'm not
sure we're gaining anything by prompting the user.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#28843: 26.0.90; gnus kills unsaved message buffer

[Nick Helm]

On Thu, 12 Apr 2018 at 23:36:15 +1200, Lars Ingebrigtsen wrote:

> Yeah, the Messsage buffers are kinda special, I guess, in that they're
> basically the only Gnus buffers what aren't generated somehow.
>
> So handling them the same way as Emacs does on shutdown does make some
> sense...  On the other hand, even if we prompt the user, they're still
> saved to a pretty obscure place (i.e., the drafts group), so I'm not
> sure we're gaining anything by prompting the user.

Personally, I think prompting gains us quite a bit. Most importantly, it
can remind users that an un-dealt-with message exists. Maybe they
intended to send it, but forgot, or mis-keyed? Or perhaps it contains
sensitive info that shouldn't be kept? By silently saving (to a
pretty obscure place) the user may never know about it.

Prompting can also give them immediate control over what to do – send,
save, discard? If they decide to save, they know to look for a draft
later. We could even pop up a message telling them where to look.

BTW, if auto-save is customized (say by changing
make-auto-save-file-name) can we always guarantee the current behaviour
will work?

bug#28843: 26.0.90; gnus kills unsaved message buffer

[Lars Ingebrigtsen]

Nick Helm <nick@tenpoint.co.nz> writes:

> Personally, I think prompting gains us quite a bit. Most importantly, it
> can remind users that an un-dealt-with message exists. Maybe they
> intended to send it, but forgot, or mis-keyed? Or perhaps it contains
> sensitive info that shouldn't be kept? By silently saving (to a
> pretty obscure place) the user may never know about it.

Yeah, that's true.  You've convinced me.  :-)

Do you have a patch to make Gnus prompt at the right time (while it's
still early enough that messages can be sent etc)?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#28843: 26.0.90; gnus kills unsaved message buffer

[Nick Helm]

On Sun, 15 Apr 2018 at 01:01:01 +1200, Lars Ingebrigtsen wrote:

> Nick Helm <nick@tenpoint.co.nz> writes:
>
>> Personally, I think prompting gains us quite a bit. Most importantly, it
>> can remind users that an un-dealt-with message exists. Maybe they
>> intended to send it, but forgot, or mis-keyed? Or perhaps it contains
>> sensitive info that shouldn't be kept? By silently saving (to a
>> pretty obscure place) the user may never know about it.
>
> Yeah, that's true.  You've convinced me.  :-)

That's great, thanks!

> Do you have a patch to make Gnus prompt at the right time (while it's
> still early enough that messages can be sent etc)?

I'm afraid I only got as far as thinking about how it might work,
possibly using `gnus-exit-gnus-hook', but that's about it.

bug#28843: 26.0.90; gnus kills unsaved message buffer

[Lars Ingebrigtsen]

I've now made Gnus query the user and abort exit if the user says so.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no