all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Jim Porter <jporterbugs@gmail.com>
Cc: larsi@gnus.org, 51993@debbugs.gnu.org, gregory@heytings.org
Subject: bug#51993: 29.0.50; [PATCH] Killing emacsclient terminal with `server-stop-automatically' doesn't prompt to save files
Date: Thu, 01 Dec 2022 19:29:31 +0200	[thread overview]
Message-ID: <83lenrghhg.fsf@gnu.org> (raw)
In-Reply-To: <b7c81fd1-76ae-1054-a4be-229ac7e16c9b@gmail.com> (message from Jim Porter on Mon, 28 Nov 2022 21:31:02 -0800)

> Date: Mon, 28 Nov 2022 21:31:02 -0800
> From: Jim Porter <jporterbugs@gmail.com>
> Cc: larsi@gnus.org, 51993@debbugs.gnu.org, gregory@heytings.org
> 
> >>> The issue in the quote above is that if you enable automatic server
> >>> shutdown in Emacs 29, it changes the behavior of exiting an emacsclient
> >>> even when it wouldn't stop the server (i.e. when there are other active
> >>> clients). That's surprising to me, I wouldn't expect that setting to
> >>> affect cases when it decides *not* to kill the Emacs daemon.
> >>
> >> Sounds like a bug to me, because it contradicts what the doc string
> >> says.
> > 
> > That's how it seems to me too. ...
> Ok, after quite a delay, here's a patch for this. Previously, the 
> function 'server-stop-automatically--handle-delete-frame' responded to 
> both 'C-x C-c' ('save-buffers-kill-terminal') and 'delete-frame', which 
> made it more complex. I've moved the 'C-x C-c' case into 
> 'server-save-buffers-kill-terminal', which simplifies 
> 'server-stop-automatically--handle-delete-frame'.
> 
> The updated 'server-save-buffers-kill-terminal' should now make sure 
> that the new stop-automatically behavior only happens when there are no 
> other client processes (or nowait frames).

We want this on the release branch, right?  Then please make it the minimal
change which fixes the immediate cause of the bug, and does nothing else: no
refactoring, no reshuffling of the code or making it nicer or less
complicated -- all that just makes the risk of new bugs higher and the job
of reviewing the patch harder.

> +	   (if (length> (frame-list) (if server-stop-automatically 2 1))
> +               ;; If there are any other frames, only delete this one.
> +               ;; When `server-stop-automatically' is set, don't count
> +               ;; the daemon frame.
>  	       (progn (save-some-buffers arg)
>  		      (delete-frame))
>  	     ;; If we're the last frame standing, kill Emacs.
>  	     (save-buffers-kill-emacs arg)))

This part is easily understood.

>  	  ((processp proc)
> +           (if (or (not server-stop-automatically)
> +                   (length> server-clients 1)
> +                   (seq-some
> +                    (lambda (frame)
> +                      (when-let ((p (frame-parameter frame 'client)))
> +                        (not (eq proc p))))
> +                    (frame-list)))
>  	       (let ((buffers (process-get proc 'buffers)))
>  	         (save-some-buffers
>  	          arg (if buffers

This part is also easily understood.

> @@ -1801,31 +1809,20 @@ server-save-buffers-kill-terminal
>                          ;; ARG is non-nil), since we're not killing
>                          ;; Emacs (unlike `save-buffers-kill-emacs').
>  		        (and arg t)))
> -	       (server-delete-client proc)))
> -	    (t (error "Invalid client frame"))))))
> +	         (server-delete-client proc))
> +             ;; If `server-stop-automatically' is set, there are no
> +             ;; other client processes, and no other client frames
> +             ;; (e.g. `nowait' frames), kill Emacs.
> +             (save-buffers-kill-emacs arg)))
> +	  (t (error "Invalid client frame")))))

But this one is problematic: it adds save-buffers-kill-emacs which wasn't in
the original code, and I don't understand why.  The bug wasn't about this,
was it?

>  (defun server-stop-automatically--handle-delete-frame (frame)
>    "Handle deletion of FRAME when `server-stop-automatically' is used."
> -  (when server-stop-automatically
> -    (if (if (and (processp (frame-parameter frame 'client))
> -		 (eq this-command 'save-buffers-kill-terminal))
> -	    (progn
> -	      (dolist (f (frame-list))
> -		(when (and (eq (frame-parameter frame 'client)
> -			       (frame-parameter f 'client))
> -			   (not (eq frame f)))
> -		  (set-frame-parameter f 'client nil)
> -		  (let ((server-stop-automatically nil))
> -		    (delete-frame f))))
> -	      (if (cddr (frame-list))
> -		  (let ((server-stop-automatically nil))
> -		    (delete-frame frame)
> -		    nil)
> -		t))
> +  (when (and server-stop-automatically
>               (null (cddr (frame-list))))
>      (let ((server-stop-automatically nil))
>        (save-buffers-kill-emacs)
> -	  (delete-frame frame)))))
> +      (delete-frame frame))))

And here you completely rewrote a function.

I'm okay with installing the original changes on master, if you indeed
believe the new code is much cleaner (but then please explain why you think
so, because I don't think I see that just by looking at the diffs).  But for
the release branch, I'm not comfortable with making such serious changes in
a part of server.el that is already way too complicated, what with all the
fancy shutdown options we strive to support.  There be dragons, and I have
no intention to release Emacs 29 with buggy server-client editing.  So for
the release branch, please prepare a safer version of the change, which only
changes the code which is the immediate cause of the incorrect behavior.

Thanks.





  reply	other threads:[~2022-12-01 17:29 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-20  4:29 bug#51993: 29.0.50; [PATCH] Killing emacsclient terminal with `server-stop-automatically' doesn't prompt to save files Jim Porter
2021-11-20  7:13 ` Eli Zaretskii
2021-11-23  9:48   ` Gregory Heytings
2021-11-23 18:25     ` Jim Porter
2021-11-23 20:37       ` Gregory Heytings
2021-11-23 22:08         ` Jim Porter
2021-11-23 22:49           ` Gregory Heytings
2021-11-23 23:42             ` Jim Porter
2021-11-23 23:59               ` Gregory Heytings
2021-11-24  1:10                 ` Jim Porter
2021-11-29  5:39 ` Jim Porter
2021-11-29 12:41   ` Eli Zaretskii
2021-11-29 13:40     ` Gregory Heytings
2021-11-29 19:31       ` Jim Porter
2022-01-01  0:11         ` Jim Porter
2022-09-09 17:55       ` Lars Ingebrigtsen
2022-09-09 18:04         ` Jim Porter
2022-10-09 22:09           ` Jim Porter
2022-10-10  6:04             ` Eli Zaretskii
2022-10-20  3:14               ` Jim Porter
2022-10-20  6:23                 ` Eli Zaretskii
2022-10-21  5:51                   ` Jim Porter
2022-10-21  6:38                     ` Eli Zaretskii
2022-10-22  3:46                       ` Jim Porter
2022-10-22  6:57                         ` Eli Zaretskii
2022-10-25  3:10                           ` Jim Porter
2022-10-30 22:32                             ` Jim Porter
2022-11-29  5:31                             ` Jim Porter
2022-12-01 17:29                               ` Eli Zaretskii [this message]
2022-12-02  1:09                                 ` bug#51993: 29.0.50; [PATCH for 29.1] " Jim Porter
2022-12-02 14:10                                   ` Eli Zaretskii
2022-12-02 21:33                                     ` Jim Porter
2022-12-04 17:56                                       ` Eli Zaretskii
2022-12-04 22:26                                         ` Jim Porter
2022-12-06 22:20                                           ` Jim Porter
2022-12-02  1:42                                 ` bug#51993: 29.0.50; [PATCH explanation] " Jim Porter
2022-12-02 14:31                                   ` Eli Zaretskii
2021-11-29 19:12     ` bug#51993: 29.0.50; [PATCH] " Jim Porter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83lenrghhg.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=51993@debbugs.gnu.org \
    --cc=gregory@heytings.org \
    --cc=jporterbugs@gmail.com \
    --cc=larsi@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.