From: Jim Porter <jporterbugs@gmail.com>
To: 58877@debbugs.gnu.org
Subject: bug#58877: 29.0.50; [PATCH] When killing Emacs from a client frame with no other frames, Emacs shows a useless error prompt
Date: Sat, 29 Oct 2022 14:33:42 -0700 [thread overview]
Message-ID: <8121efd5-77c3-0682-ce0f-6be9375dadd8@gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1236 bytes --]
(Note: I originally mentioned this in bug#51993, but it's only
somewhat-related to that bug. To make things easier to follow, I pulled
this part out into a separate bug.)
To see this in action:
$ emacs -Q -f server-start
$ emacsclient -c foo.txt
;; From the first (non-client) frame:
C-x 5 0 ;; delete-frame
;; From the second (client) frame:
M-x kill-emacs
;; Emacs prompts:
Error (error Attempt to delete the sole visible or iconified frame);
continue? (y or n)
Pressing "y" will properly kill Emacs, but there's no real use for the
warning in this case. It happens because 'server-force-stop'
(indirectly) tries to delete the last (client) frame before killing
Emacs, meaning that Emacs would have zero frames for a bit.
Since 'server-force-stop's docstring says, "This function is meant to be
called from `kill-emacs-hook'," it should be safe to have
'server-force-stop' avoid deleting any frames: they'll just get deleted
when Emacs is actually killed.
Attached is a patch to do this. Note that I named the new argument
"noframe" because that matches the existing code in server.el (see
'server-delete-client'). It's a bit of a misnomer though, and maybe
"keep-frames" would be better...
[-- Attachment #2: 0001-Don-t-explicitly-delete-client-frames-when-killing-E.patch --]
[-- Type: text/plain, Size: 2175 bytes --]
From 522574ce69e3c198a40b57e2e211e14562334f33 Mon Sep 17 00:00:00 2001
From: Jim Porter <jporterbugs@gmail.com>
Date: Fri, 19 Nov 2021 20:14:33 -0800
Subject: [PATCH] Don't explicitly delete client frames when killing Emacs
anyway
This eliminates a useless error prompt when killing Emacs from a
client frame when there are no other frames.
* lisp/server.el (server-start): Add NOFRAME argument to avoid
deleting frames.
(server-force-stop): Pass 'noframe' to 'server-stop'.
---
lisp/server.el | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/lisp/server.el b/lisp/server.el
index 90d97c1538..2b7213b890 100644
--- a/lisp/server.el
+++ b/lisp/server.el
@@ -611,7 +611,7 @@ server-get-auth-key
(server-generate-key)))
;;;###autoload
-(defun server-start (&optional leave-dead inhibit-prompt)
+(defun server-start (&optional leave-dead inhibit-prompt noframe)
"Allow this Emacs process to be a server for client processes.
This starts a server communications subprocess through which client
\"editors\" can send your editing commands to this Emacs job.
@@ -625,6 +625,11 @@ server-start
running, ask the user for confirmation first, unless optional
argument INHIBIT-PROMPT is non-nil.
+If NOFRAME is non-nil, don't delete any existing frames
+associated with a client process. This is useful, for example,
+when killing Emacs, in which case the frames will get deleted
+anyway.
+
To force-start a server, do \\[server-force-delete] and then
\\[server-start].
@@ -683,7 +688,7 @@ server-start
(setq leave-dead t)))
;; If this Emacs already had a server, clear out associated status.
(while server-clients
- (server-delete-client (car server-clients)))
+ (server-delete-client (car server-clients) noframe))
;; Now any previous server is properly stopped.
(if leave-dead
(progn
@@ -742,7 +747,7 @@ server-start
(defun server-force-stop ()
"Kill all connections to the current server.
This function is meant to be called from `kill-emacs-hook'."
- (server-start t t))
+ (server-start t t 'noframe))
;;;###autoload
(defun server-force-delete (&optional name)
--
2.25.1
next reply other threads:[~2022-10-29 21:33 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-29 21:33 Jim Porter [this message]
2022-10-30 6:14 ` bug#58877: 29.0.50; [PATCH] When killing Emacs from a client frame with no other frames, Emacs shows a useless error prompt Eli Zaretskii
2022-10-30 21:14 ` Jim Porter
2022-11-22 5:06 ` Jim Porter
2022-11-24 11:51 ` Eli Zaretskii
2022-11-25 1:36 ` Jim Porter
2022-11-25 13:25 ` Eli Zaretskii
2022-11-25 19:31 ` Jim Porter
2022-11-25 20:18 ` Eli Zaretskii
2022-11-25 20:57 ` Jim Porter
2022-11-26 14:43 ` Eli Zaretskii
2022-11-26 19:04 ` Jim Porter
2022-11-26 19:45 ` Eli Zaretskii
2022-11-26 20:17 ` Jim Porter
2022-11-26 20:35 ` Eli Zaretskii
2022-11-26 21:44 ` Jim Porter
2022-11-28 1:28 ` Jim Porter
2022-11-28 3:31 ` Eli Zaretskii
2022-11-28 6:27 ` 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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8121efd5-77c3-0682-ce0f-6be9375dadd8@gmail.com \
--to=jporterbugs@gmail.com \
--cc=58877@debbugs.gnu.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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).