From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.bugs Subject: bug#28843: 26.0.90; gnus kills unsaved message buffer Date: Wed, 08 Nov 2017 08:22:58 -0800 Message-ID: <87y3ngvixp.fsf@ericabrahamsen.net> References: <877ev1xzjf.fsf@ericabrahamsen.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1510158381 2060 195.159.176.226 (8 Nov 2017 16:26:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 8 Nov 2017 16:26:21 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) To: 28843@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Nov 08 17:26:17 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eCTB7-0000Ev-Q6 for geb-bug-gnu-emacs@m.gmane.org; Wed, 08 Nov 2017 17:26:14 +0100 Original-Received: from localhost ([::1]:60693 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eCTBF-0002lx-1w for geb-bug-gnu-emacs@m.gmane.org; Wed, 08 Nov 2017 11:26:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48314) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eCTB2-0002ju-7K for bug-gnu-emacs@gnu.org; Wed, 08 Nov 2017 11:26:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eCTAx-0003Ma-9F for bug-gnu-emacs@gnu.org; Wed, 08 Nov 2017 11:26:08 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50097) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eCTAx-0003M8-5U for bug-gnu-emacs@gnu.org; Wed, 08 Nov 2017 11:26:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eCTAv-0005Bu-UA; Wed, 08 Nov 2017 11:26:01 -0500 X-Loop: help-debbugs@gnu.org In-Reply-To: Resent-From: Eric Abrahamsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bugs@gnus.org Resent-Date: Wed, 08 Nov 2017 16:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28843 X-GNU-PR-Package: emacs,gnus X-GNU-PR-Keywords: X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.151015831019884 (code B ref -1); Wed, 08 Nov 2017 16:26:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 8 Nov 2017 16:25:10 +0000 Original-Received: from localhost ([127.0.0.1]:58776 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eCTA5-0005Ac-P7 for submit@debbugs.gnu.org; Wed, 08 Nov 2017 11:25:10 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:57042) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eCTA4-0005AN-GH for submit@debbugs.gnu.org; Wed, 08 Nov 2017 11:25:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eCT9y-0002em-3b for submit@debbugs.gnu.org; Wed, 08 Nov 2017 11:25:03 -0500 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:34557) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eCT9y-0002ee-0H for submit@debbugs.gnu.org; Wed, 08 Nov 2017 11:25:02 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48001) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eCT9w-0001pE-C8 for bug-gnu-emacs@gnu.org; Wed, 08 Nov 2017 11:25:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eCT9r-0002bg-FC for bug-gnu-emacs@gnu.org; Wed, 08 Nov 2017 11:25:00 -0500 Original-Received: from [195.159.176.226] (port=39103 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eCT9r-0002b0-6E for bug-gnu-emacs@gnu.org; Wed, 08 Nov 2017 11:24:55 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1eCT9f-0005I2-JH for bug-gnu-emacs@gnu.org; Wed, 08 Nov 2017 17:24:43 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 87 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:4T47/8H9To1Nyd3pt9viFyHTLjo= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:139614 Archived-At: Nick Helm writes: > On Tue, 7 Nov 2017 at 18:41:24 -0800, Eric Abrahamsen wrote: > >> Nick Helm 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".