GNU bug report logs - #58909
29.0.50; [WIP PATCH] Deleting the last frame of an emacsclient doesn't ask to save

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 58909 in the body.
You can then email your comments to 58909 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; [WIP PATCH] Deleting the last frame of an emacsclient
 doesn't ask to save
Date: Sun, 30 Oct 2022 15:29:30 -0700

[Message part 1 (text/plain, inline)]

(Note: this is tangentially related to bug#51993, but it happens 
regardless of whether 'server-stop-automatically' is enabled.)

In most cases when you do something to exit an Emacs client, it prompts 
you to save buffers associated with that client. For example:

  $ emacs -Q -f server-start
  $ emacsclient -c foo.txt

  ;; type some random characters

  C-x #
  ;; or...
  C-x C-c

In both cases, Emacs will ask to save foo.txt, though the prompts will 
be slightly different. That's good, since whatever invoked "emacsclient 
-c foo.txt" is likely waiting for the user to have saved that file.

However, if you use 'C-x 5 0' instead, that terminates the Emacs client, 
but *doesn't* prompt to save foo.txt. I think it should prompt in this 
case too: all three of 'C-x #', 'C-x C-c', and 'C-x 5 0' have the effect 
(in this simple case) of deleting the Emacs client and returning to the 
calling process. (A user who wanted to bail out of an Emacs client 
without saving should use 'sever-edit-abort' instead.)

Attached is a WIP patch to do this. It's WIP because it will need to 
have some special handling for the 'server-stop-automatically' case so 
that it doesn't prompt twice in some cases. I also changed how 
'delete-frame' calls 'delete-frame-functions'. Hopefully the change I 
made is correct; I'm hesitant to change low-level code like that, but I 
think it's the right thing to do for this case at least. (Maybe that 
change should be called out in NEWS?)

Ultimately, it might make sense to merge this bug with bug#51993, but 
the discussion in that bug is already pretty long, and I think it would 
just confuse matters to add even more tangents to that discussion.

[0001-When-deleting-the-last-frame-of-an-Emacs-client-ask-.patch (text/plain, attachment)]

Message #8 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 58909 <at> debbugs.gnu.org
Subject: Re: bug#58909: 29.0.50;
 [WIP PATCH] Deleting the last frame of an emacsclient doesn't ask to
 save
Date: Mon, 31 Oct 2022 14:44:21 +0200

> Date: Sun, 30 Oct 2022 15:29:30 -0700
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
>    $ emacs -Q -f server-start
>    $ emacsclient -c foo.txt
> 
>    ;; type some random characters
> 
>    C-x #
>    ;; or...
>    C-x C-c
> 
> In both cases, Emacs will ask to save foo.txt, though the prompts will 
> be slightly different. That's good, since whatever invoked "emacsclient 
> -c foo.txt" is likely waiting for the user to have saved that file.
> 
> However, if you use 'C-x 5 0' instead, that terminates the Emacs client, 
> but *doesn't* prompt to save foo.txt. I think it should prompt in this 
> case too: all three of 'C-x #', 'C-x C-c', and 'C-x 5 0' have the effect 
> (in this simple case) of deleting the Emacs client and returning to the 
> calling process. (A user who wanted to bail out of an Emacs client 
> without saving should use 'sever-edit-abort' instead.)

I'm uneasy with this incompatible behavior change.  I can think of
some legitimate use cases where "C-x 5 0" should not prompt, e.g., if
the user intends to keep editing the file, and no application is
waiting for the client to finish.  Why break such flows?

Deleting a frame does no harm as long as Emacs is still up and running
after that, so IMO forcing the user to answer such a prompt could be
an annoyance.

Thanks.

Message #11 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58909 <at> debbugs.gnu.org
Subject: Re: bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Mon, 31 Oct 2022 10:36:57 -0700

On 10/31/2022 5:44 AM, Eli Zaretskii wrote:
> I'm uneasy with this incompatible behavior change.  I can think of
> some legitimate use cases where "C-x 5 0" should not prompt, e.g., if
> the user intends to keep editing the file, and no application is
> waiting for the client to finish.  Why break such flows?

Maybe we should add an option like 
'server-save-before-deleting-last-frame', in case users prefer the old 
behavior? I had originally planned to add an option like this for the 
same reason you mention, but I didn't want to be too aggressive with 
adding extra options if they aren't really needed. Since you mentioned 
it too though, I think this should at least have an option.

Alternately, we could add a keybinding for 'server-edit-abort'. Then 
users could easily use that command to support this flow. That has the 
benefit that it's a command which is explicitly for saying, "I'm done 
with this file and don't want to save it," though it does break users' 
muscle memory.

Still another possibility would be to prompt only when closing a frame 
by clicking the "X" on the frame's title bar. When using a 
non-client/server Emacs, doing this prompts the user to save when 
closing the last frame. ('C-x 5 0' in this case would just error out, 
since it refuses to delete the last frame.) That's because clicking the 
X calls 'handle-delete-frame' which calls 'save-buffers-kill-emacs' in 
that case. Then clicking the "X" would behave similarly when deleting 
the last frame of a client and deleting the last frame overall.

I think I prefer one of the first two though.

> Deleting a frame does no harm as long as Emacs is still up and running
> after that, so IMO forcing the user to answer such a prompt could be
> an annoyance.

I think it does about the same amount of harm as pressing 'C-x C-c' in 
an emacs client. Since my patch only affects the case when there's a 
single frame for the client, both 'C-x C-c' and 'C-x 5 0' would do the 
same thing (aside from prompting): they close the current frame and 
terminate the client connection.

Message #14 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 58909 <at> debbugs.gnu.org
Subject: Re: bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Mon, 31 Oct 2022 20:25:24 +0200

> Date: Mon, 31 Oct 2022 10:36:57 -0700
> Cc: 58909 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> On 10/31/2022 5:44 AM, Eli Zaretskii wrote:
> > I'm uneasy with this incompatible behavior change.  I can think of
> > some legitimate use cases where "C-x 5 0" should not prompt, e.g., if
> > the user intends to keep editing the file, and no application is
> > waiting for the client to finish.  Why break such flows?
> 
> Maybe we should add an option like 
> 'server-save-before-deleting-last-frame', in case users prefer the old 
> behavior?

I tend to think we shouldn't change the behavior here, not at all.
Not even as an option.  I see no problem here that we must solve.

> Alternately, we could add a keybinding for 'server-edit-abort'.

Users who need this can easily make a binding for them.  There's no
need to have such a binding by default.

> Still another possibility would be to prompt only when closing a frame 
> by clicking the "X" on the frame's title bar. When using a 
> non-client/server Emacs, doing this prompts the user to save when 
> closing the last frame. ('C-x 5 0' in this case would just error out, 
> since it refuses to delete the last frame.) That's because clicking the 
> X calls 'handle-delete-frame' which calls 'save-buffers-kill-emacs' in 
> that case. Then clicking the "X" would behave similarly when deleting 
> the last frame of a client and deleting the last frame overall.

But "last frame of a client" ≠ "the last frame".  So I see no reason
for a similar behavior.

> > Deleting a frame does no harm as long as Emacs is still up and running
> > after that, so IMO forcing the user to answer such a prompt could be
> > an annoyance.
> 
> I think it does about the same amount of harm as pressing 'C-x C-c' in 
> an emacs client.

How can you say that?  "C-x C-c" kills the entire terminal, whereas
"C-x 5 0" kills just one frame!

> Since my patch only affects the case when there's a single frame for
> the client, both 'C-x C-c' and 'C-x 5 0' would do the same thing
> (aside from prompting): they close the current frame and terminate
> the client connection.

I disagree, sorry.  We are talking about maybe a minor inconvenience
in a pretty special use case.  It is unjustified to change long-time
behavior for such weak reasons.

Message #17 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58909 <at> debbugs.gnu.org
Subject: Re: bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Mon, 31 Oct 2022 12:28:23 -0700

[Message part 1 (text/plain, inline)]

On 10/31/2022 5:44 AM, Eli Zaretskii wrote:
>> Date: Sun, 30 Oct 2022 15:29:30 -0700
>> From: Jim Porter <jporterbugs <at> gmail.com>
>>
>> However, if you use 'C-x 5 0' instead, that terminates the Emacs client,
>> but *doesn't* prompt to save foo.txt. I think it should prompt in this
>> case too: all three of 'C-x #', 'C-x C-c', and 'C-x 5 0' have the effect
>> (in this simple case) of deleting the Emacs client and returning to the
>> calling process. (A user who wanted to bail out of an Emacs client
>> without saving should use 'sever-edit-abort' instead.)
> 
> I'm uneasy with this incompatible behavior change.  I can think of
> some legitimate use cases where "C-x 5 0" should not prompt, e.g., if
> the user intends to keep editing the file, and no application is
> waiting for the client to finish.  Why break such flows?

After thinking about this some more, I realized that I didn't properly 
address this part of your message. If no application is waiting for the 
client to finish, then the user hopefully used "--no-wait" when starting 
emacsclient. We could avoid prompting in that case.[1]

If an application *is* waiting for the client to finish, then 
"--no-wait" would be unset. In that case, prompting the user has some 
value. See the attached patch. (I changed the code to only prompt when 
deleting the last frame of a *non-nowait* client.)

[1] Currently, 'C-x C-c' from a nowait frame prompts via 
'save-some-buffers' (so long as there's another frame; see 
'server-save-buffers-kill-terminal'). Maybe we could avoid prompting 
then too? After prompting, it just calls 'delete-frame', so it's very 
similar to 'C-x 5 0' in this scenario... Still, as you say, it's 
probably good to be careful about making incompatible changes here.

[0001-When-deleting-the-last-frame-of-an-Emacs-client-ask-.patch (text/plain, attachment)]

Message #20 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58909 <at> debbugs.gnu.org
Subject: Re: bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Mon, 31 Oct 2022 12:38:04 -0700

On 10/31/2022 11:25 AM, Eli Zaretskii wrote:
>> I think it does about the same amount of harm as pressing 'C-x C-c' in
>> an emacs client.
> 
> How can you say that?  "C-x C-c" kills the entire terminal, whereas
> "C-x 5 0" kills just one frame!

When there's only one frame left for the client, 'C-x 5 0' *also* kills 
the entire terminal. That's the only case I want to add a prompt to. I 
agree that if you're only killing a frame, there's no sense in 
prompting. But when killing a frame gets upgraded into killing the 
entire terminal, it then has the same end result as having pressed 'C-x 
C-c'. Shouldn't Emacs then ask the user about what to do before killing 
the terminal?

Of course, 'C-x C-c' also has the effect of killing any other frames for 
that client, but that that doesn't apply there's only one frame. Still, 
'C-x C-c' still prompts in that case too. My understanding is that it 
does so because when an application is waiting for the emacsclient to 
finish, you can't go back from killing the terminal/client; you *can* 
(usually) go back if you're only killing a frame.

See my other message about this too: we could make sure Emacs only 
prompts the user when deleting a frame if doing so would kill a terminal 
that's actually waiting for some files to be saved. If the client was 
invoked with "--no-wait", we could just silently delete the frame: 
there's no application waiting for a file.

Message #23 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 58909 <at> debbugs.gnu.org
Subject: Re: bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Mon, 31 Oct 2022 21:43:24 +0200

> Date: Mon, 31 Oct 2022 12:28:23 -0700
> Cc: 58909 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> > I'm uneasy with this incompatible behavior change.  I can think of
> > some legitimate use cases where "C-x 5 0" should not prompt, e.g., if
> > the user intends to keep editing the file, and no application is
> > waiting for the client to finish.  Why break such flows?
> 
> After thinking about this some more, I realized that I didn't properly 
> address this part of your message. If no application is waiting for the 
> client to finish, then the user hopefully used "--no-wait" when starting 
> emacsclient.

No, I meant that the user invoked emacsclient from the shell prompt,
for example.  As opposed to some application invoking emacsclient via
$EDITOR or similar.

Message #26 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 58909 <at> debbugs.gnu.org
Subject: Re: bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Mon, 31 Oct 2022 21:52:12 +0200

> Date: Mon, 31 Oct 2022 12:38:04 -0700
> From: Jim Porter <jporterbugs <at> gmail.com>
> Cc: 58909 <at> debbugs.gnu.org
> 
> On 10/31/2022 11:25 AM, Eli Zaretskii wrote:
> >> I think it does about the same amount of harm as pressing 'C-x C-c' in
> >> an emacs client.
> > 
> > How can you say that?  "C-x C-c" kills the entire terminal, whereas
> > "C-x 5 0" kills just one frame!
> 
> When there's only one frame left for the client, 'C-x 5 0' *also* kills 
> the entire terminal.

But "C-x 5 0" doesn't have the same significance as "C-x C-c".  They
are different in the non-client use, and they are different in the
client use.  That someone could perceive them as very similar because
some aspects of what they do are the same doesn't mean they are
similar enough to behave the same wrt the prompt to save.

> Of course, 'C-x C-c' also has the effect of killing any other frames for 
> that client, but that that doesn't apply there's only one frame.

It would (or at least could) be possible to reason that way.  But it
could be argued that forcing the user to distinguish between the last
"C-x 5 0" and any other is bad UI.  When I type "C-x 5 0" I don't want
to expect different behavior depending on how many frames the current
client has.  "C-x 5 0" means "delete this frame", no more, no less.

> Still, 
> 'C-x C-c' still prompts in that case too. My understanding is that it 
> does so because when an application is waiting for the emacsclient to 
> finish, you can't go back from killing the terminal/client; you *can* 
> (usually) go back if you're only killing a frame.

My interpretation of why "C-x C-c" prompts is that it does the same as
when you use it from a non-client frame.  We want the same UX in both
cases.  "C-x 5 0" should IMO likewise produce the same behavior in
both cases.

> See my other message about this too: we could make sure Emacs only 
> prompts the user when deleting a frame if doing so would kill a terminal 
> that's actually waiting for some files to be saved. If the client was 
> invoked with "--no-wait", we could just silently delete the frame: 
> there's no application waiting for a file.

This has the same problem, IMO: it changes long-time behavior of
client frames in incompatible ways.  I don't think it's right, since
the reasons for these changes are rather weak.

Message #29 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58909 <at> debbugs.gnu.org
Subject: Re: bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Mon, 31 Oct 2022 13:01:55 -0700

On 10/31/2022 12:43 PM, Eli Zaretskii wrote:
>> Date: Mon, 31 Oct 2022 12:28:23 -0700
>> Cc: 58909 <at> debbugs.gnu.org
>> From: Jim Porter <jporterbugs <at> gmail.com>
>>
>>> I'm uneasy with this incompatible behavior change.  I can think of
>>> some legitimate use cases where "C-x 5 0" should not prompt, e.g., if
>>> the user intends to keep editing the file, and no application is
>>> waiting for the client to finish.  Why break such flows?
>>
>> After thinking about this some more, I realized that I didn't properly
>> address this part of your message. If no application is waiting for the
>> client to finish, then the user hopefully used "--no-wait" when starting
>> emacsclient.
> 
> No, I meant that the user invoked emacsclient from the shell prompt,
> for example.  As opposed to some application invoking emacsclient via
> $EDITOR or similar.

If a user simply typed "emacsclient file.txt", that would visit file.txt 
in an existing frame (if possible), so that frame wouldn't be associated 
with the emacsclient process the user just started. Pressing 'C-x 5 0' 
wouldn't need to prompt then: it's not deleting the last frame 
associated with that client, so the code in 'server-handle-delete-frame' 
doesn't apply. (Note: It's possible that the frame in question is the 
last frame of some *other* client though.)

A user might instead type "emacsclient -c file.txt" (or use "-t", etc) 
to create an all-new frame. In that case, my patch would prompt. But if 
the user is already typing "emacsclient -c file.txt", then "emacsclient 
-nc foo.txt" is just one more character, and it would make it explicit 
that the client isn't waiting around for file.txt. Then my patch would 
*not* prompt.

Message #32 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 58909 <at> debbugs.gnu.org
Subject: Re: bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Mon, 31 Oct 2022 22:21:42 +0200

> Date: Mon, 31 Oct 2022 13:01:55 -0700
> Cc: 58909 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> A user might instead type "emacsclient -c file.txt" (or use "-t", etc) 
> to create an all-new frame. In that case, my patch would prompt. But if 
> the user is already typing "emacsclient -c file.txt", then "emacsclient 
> -nc foo.txt" is just one more character, and it would make it explicit 
> that the client isn't waiting around for file.txt. Then my patch would 
> *not* prompt.

Yes, this new behavior can be worked around, in more than one way.
But people get annoyed by changes which invalidate their muscle memory
of many years.  So we must in each case like this to have a very good
reason for such changes, otherwise people would rightfully conclude
that our decisions are more-or-less are arbitrary and basically prefer
someone's workflows over those of others.  I'm sorry, but past
behavior gets more weight in such situations, just because it was here
first.

Message #35 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58909 <at> debbugs.gnu.org
Subject: Re: bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Mon, 31 Oct 2022 13:28:01 -0700

On 10/31/2022 12:52 PM, Eli Zaretskii wrote:
>> Date: Mon, 31 Oct 2022 12:38:04 -0700
>> From: Jim Porter <jporterbugs <at> gmail.com>
>> Cc: 58909 <at> debbugs.gnu.org
>>
>> Still,
>> 'C-x C-c' still prompts in that case too. My understanding is that it
>> does so because when an application is waiting for the emacsclient to
>> finish, you can't go back from killing the terminal/client; you *can*
>> (usually) go back if you're only killing a frame.
> 
> My interpretation of why "C-x C-c" prompts is that it does the same as
> when you use it from a non-client frame.  We want the same UX in both
> cases.  "C-x 5 0" should IMO likewise produce the same behavior in
> both cases.

That's actually my goal too: I'd like to ensure that the UX for a client 
frame is as similar as possible as for a non-client frame. Since we 
disagree on what that similarity should be, I guess that means we have 
different mental models for some part of this. If it helps, I'll try to 
explain how I think of it.

From a client frame, 'C-x C-c' prompts to save all the file-buffers 
associated with that client, and then kills the client, which kills the 
frames for that client. That's similar to 'C-x C-c' in a non-client 
setting: it kills *all* frames and prompts to save *all* file-buffers. 
So I see the client as a "sub" Emacs: it owns some frames and 
(partially) owns some buffers. Commands on the client then work on that 
subset, and only that subset. Since frames can only be owned by a single 
client, in my mind frame commands also work within that client's subset.

For frame-deletion, non-client Emacs lets you kill a single frame via 
'C-x 5 0' or clicking the X in the frame's title bar. However, if it's 
the last frame, then:

  C-x 5 0    -> Error: "Attempt to delete the sole visible or iconified 
frame"
  Clicking X -> Call 'save-buffers-kill-emacs' (see 'handle-delete-frame')

To me, that would mean that the matching UX for a client with a single 
frame (but possibly other frames for Emacs overall) is:

  C-x 5 0    -> Error
  Clicking X -> Call 'save-buffers-kill-terminal'

Signaling an error for 'C-x 5 0' seems excessively strict to me, so 
calling 'save-buffers-kill-terminal' in both cases seemed like a good 
compromise to me. Instead of getting an error, the user gets a prompt, 
but can still proceed with killing that frame if they're sure.

Message #38 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58909 <at> debbugs.gnu.org
Subject: Re: bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Mon, 31 Oct 2022 14:06:16 -0700

On 10/31/2022 1:21 PM, Eli Zaretskii wrote:
>> Date: Mon, 31 Oct 2022 13:01:55 -0700
>> Cc: 58909 <at> debbugs.gnu.org
>> From: Jim Porter <jporterbugs <at> gmail.com>
>>
>> A user might instead type "emacsclient -c file.txt" (or use "-t", etc)
>> to create an all-new frame. In that case, my patch would prompt. But if
>> the user is already typing "emacsclient -c file.txt", then "emacsclient
>> -nc foo.txt" is just one more character, and it would make it explicit
>> that the client isn't waiting around for file.txt. Then my patch would
>> *not* prompt.
> 
> Yes, this new behavior can be worked around, in more than one way.
> But people get annoyed by changes which invalidate their muscle memory
> of many years.  So we must in each case like this to have a very good
> reason for such changes, otherwise people would rightfully conclude
> that our decisions are more-or-less are arbitrary and basically prefer
> someone's workflows over those of others.

I can definitely understand that position. It's an aspect of Emacs that 
I know I appreciate very much. Emacs has been around for a long time, 
and hopefully will be around for a lot longer. I'm not sure I have a 
great sense of how to balance Emacs' history with ensuring that the next 
decade (and more!) of Emacs is on the best footing possible.

In any case, unless my other recent messages have convinced you 
otherwise, what do you think of the following:

1) For now, just make the change in my patch to 'delete-frame' in 
src/frame.c to allow hooks in 'delete-frame-functions' to quit out of 
frame deletion. That way, users who want the rest of the behavior in my 
patch can just replace 'server-handle-delete-frame' with their own Elisp 
function. This change isn't entirely without risk, since it could cause 
some hooks to go from silently signaling an error to making it 
impossible to delete frames, but I'm not sure that will come up in 
practice (and if it does, the hooks can be fixed easily enough).

2) After the Emacs 29 branch is cut, maybe (emphasis on maybe) discuss 
the changes to prompting on emacs-devel, and possibly even commit it to 
the master branch with the caveat that if it causes problems for anyone, 
we back it out. Obviously not everyone follows emacs-devel, but this 
would give people a chance to provide feedback, positive or negative.

Message #41 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 58909 <at> debbugs.gnu.org
Subject: Re: bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Tue, 01 Nov 2022 08:17:06 +0200

> Date: Mon, 31 Oct 2022 13:28:01 -0700
> Cc: 58909 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> > My interpretation of why "C-x C-c" prompts is that it does the same as
> > when you use it from a non-client frame.  We want the same UX in both
> > cases.  "C-x 5 0" should IMO likewise produce the same behavior in
> > both cases.
> 
> That's actually my goal too: I'd like to ensure that the UX for a client 
> frame is as similar as possible as for a non-client frame. Since we 
> disagree on what that similarity should be, I guess that means we have 
> different mental models for some part of this. If it helps, I'll try to 
> explain how I think of it.

Thanks.  Our notions of "similarity" are different.  For me, it's the
immediate effect of the command; for you, it's what happens in Emacs
under the hood, in particular how many other "similar" frames remain.

Message #44 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 58909 <at> debbugs.gnu.org
Subject: Re: bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Tue, 01 Nov 2022 08:39:25 +0200

> Date: Mon, 31 Oct 2022 14:06:16 -0700
> Cc: 58909 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> 1) For now, just make the change in my patch to 'delete-frame' in 
> src/frame.c to allow hooks in 'delete-frame-functions' to quit out of 
> frame deletion. That way, users who want the rest of the behavior in my 
> patch can just replace 'server-handle-delete-frame' with their own Elisp 
> function. This change isn't entirely without risk, since it could cause 
> some hooks to go from silently signaling an error to making it 
> impossible to delete frames, but I'm not sure that will come up in 
> practice (and if it does, the hooks can be fixed easily enough).

I don't see how this would serve well the use case you want to enable.
We are talking about prompting the user to save unsaved buffers, yes?
So adding a hook in server-delete-client sounds like a much better
solution to me, as it doesn't affect the (much more general)
delete-frame in any way.

> 2) After the Emacs 29 branch is cut, maybe (emphasis on maybe) discuss 
> the changes to prompting on emacs-devel, and possibly even commit it to 
> the master branch with the caveat that if it causes problems for anyone, 
> we back it out. Obviously not everyone follows emacs-devel, but this 
> would give people a chance to provide feedback, positive or negative.

You can start the discussion now, from my POV.  But if having a hook
in server-delete-client is good enough, I don't see why we would need
to discuss an actual behavior change.

(And the proviso of backing out changes doesn't work in this project,
IME: people get defensive about their changes, and perceive reverting
them as personal insult.  So we do that only in very extreme cases.)

Message #47 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58909 <at> debbugs.gnu.org
Subject: Re: bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Tue, 1 Nov 2022 09:11:40 -0700

On 10/31/2022 11:39 PM, Eli Zaretskii wrote:
>> Date: Mon, 31 Oct 2022 14:06:16 -0700
>> Cc: 58909 <at> debbugs.gnu.org
>> From: Jim Porter <jporterbugs <at> gmail.com>
>>
>> 1) For now, just make the change in my patch to 'delete-frame' in
>> src/frame.c to allow hooks in 'delete-frame-functions' to quit out of
>> frame deletion. That way, users who want the rest of the behavior in my
>> patch can just replace 'server-handle-delete-frame' with their own Elisp
>> function. This change isn't entirely without risk, since it could cause
>> some hooks to go from silently signaling an error to making it
>> impossible to delete frames, but I'm not sure that will come up in
>> practice (and if it does, the hooks can be fixed easily enough).
> 
> I don't see how this would serve well the use case you want to enable.
> We are talking about prompting the user to save unsaved buffers, yes?
> So adding a hook in server-delete-client sounds like a much better
> solution to me, as it doesn't affect the (much more general)
> delete-frame in any way.

I think a hook on 'server-delete-client' could work well. It'd make it 
easier to write hooks that run at the right time compared to using other 
existing hooks. In fact, I had a similar idea for bug#51993[1]. In that 
case I ended up adding 2 hooks to 'server-delete-client', but that was 
just to work around a strange bug I saw in testing; I could probably fix 
that in a better way with some more effort so that we only need one new 
hook.

However, I'm not sure how to do this in a complete way without tweaking 
'delete-frame-functions'. Deleting a frame can cause Emacs to delete the 
client if that was the last frame for the client; that's 
long-established behavior, so we shouldn't change it. But that poses a 
problem. If 1) I delete a frame, 2) it calls 'server-delete-client', and 
3) some 'server-delete-client-hook' prompts me, then I might try to quit 
out via C-g. Without my change to how 'delete-frame-functions' are run, 
then C-g would only quit out of 'server-delete-client', but would still 
delete the frame. At least for some emacsclient use cases, that could be 
a problem.

For example, suppose I have a system called "remotehost" with an "emacs 
--daemon" instance and EDITOR="emacsclient -c":

  me <at> localhost $ ssh -X remotehost
  ...
  me <at> remotehost $ git commit

  ;; emacsclient starts and creates a new frame on my local display.
  ;; Start editing the git commit message.
  ;; Get distracted, do some other stuff...

  ;; ... finish up the other stuff, click "X" on the emacsclient frame.
  Save file /home/me/src/project/.git/COMMIT_EDITMSG?
  ;; Realize, "Oh yeah! I forgot to finish this commit message."
  C-g

Without the 'delete-frame-functions' change, I'd now be left with no 
Emacs frames on my localhost, but the emacsclient is still running. That 
would be inconvenient, since I'd have to do more work to fix the 
situation. The best way I can think of would be to start another 
emacsclient locally, do the edits to COMMIT_EDITMSG, and then 'C-x #' to 
finish editing. It'd be a lot nicer if 'C-g' stopped the frame from 
getting deleted. (Incidentally, that's how it would work in a regular, 
non-client/server Emacs. Clicking "X" on the last frame actually calls 
'save-buffer-kill-emacs' instead of 'delete-frame', and you can 'C-g' 
out of that to keep the frame open.)

> You can start the discussion now, from my POV.  But if having a hook
> in server-delete-client is good enough, I don't see why we would need
> to discuss an actual behavior change.

Yeah, let's finish up the discussion here, and if I have any open 
questions that could use a wider audience, I'll post to emacs-devel 
afterwards.

[1] https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-10/msg00908.html

Message #50 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58909 <at> debbugs.gnu.org
Subject: Re: bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Tue, 1 Nov 2022 15:39:29 -0700

[Message part 1 (text/plain, inline)]

On 11/1/2022 9:11 AM, Jim Porter wrote:
> However, I'm not sure how to do this in a complete way without tweaking 
> 'delete-frame-functions'. ...
Attached is a (hopefully) safer version of my change to 'delete-frame'. 
In this patch, a hook can only cancel frame deletion if FORCE is 
non-nil. This way, if there were ever some bug with a hook, you (or some 
code) can still force-delete the frame.

This would probably still need a NEWS entry, but I'm personally less 
worried about this change compared to my previous revision. What do you 
think?

[0001-Let-delete-frame-functions-quit-out-of-frame-deletio.patch (text/plain, attachment)]

Message #53 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 58909 <at> debbugs.gnu.org
Subject: Re: bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Wed, 02 Nov 2022 14:16:04 +0200

> Date: Tue, 1 Nov 2022 15:39:29 -0700
> From: Jim Porter <jporterbugs <at> gmail.com>
> Cc: 58909 <at> debbugs.gnu.org
> 
> Attached is a (hopefully) safer version of my change to 'delete-frame'. 
> In this patch, a hook can only cancel frame deletion if FORCE is 
> non-nil. This way, if there were ever some bug with a hook, you (or some 
> code) can still force-delete the frame.

Sorry, but I still don't like this.  We currently call this hook via
safe_call because we don't want to let the hook prevent the deletion
of the frame.

I prefer to solve this in server.el, not in lower-level primitives.

Message #56 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58909 <at> debbugs.gnu.org
Subject: Re: bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Wed, 2 Nov 2022 09:36:52 -0700

[Message part 1 (text/plain, inline)]

On 11/2/2022 5:16 AM, Eli Zaretskii wrote:
>> Date: Tue, 1 Nov 2022 15:39:29 -0700
>> From: Jim Porter <jporterbugs <at> gmail.com>
>> Cc: 58909 <at> debbugs.gnu.org
>>
>> Attached is a (hopefully) safer version of my change to 'delete-frame'.
>> In this patch, a hook can only cancel frame deletion if FORCE is
>> non-nil. This way, if there were ever some bug with a hook, you (or some
>> code) can still force-delete the frame.
> 
> Sorry, but I still don't like this.  We currently call this hook via
> safe_call because we don't want to let the hook prevent the deletion
> of the frame.
> 
> I prefer to solve this in server.el, not in lower-level primitives.

Hm, ok. That means I'd need to make sure 'C-x 5 0' calls something other 
than 'delete-frame', so that I could add a prompt to it that can prevent 
deletion of the frame.

Two questions then:

1. If 'delete-frame' is a lower-level primitive, should 'C-x 5 0' call 
it directly, or should there be a higher-level function for it to call? 
If we had some higher-level function, then user-level commands could 
call that, but low-level code could still use 'delete-frame'. This 
user-level command would then be able to run some hook that can prevent 
deletion of the frame.

2. Since server.el has a minor mode (unsurprisingly named 
'server-mode'), maybe one option is to do command remapping. If we remap 
'delete-frame' to some new 'server-delete-frame' when 'server-mode' is 
active, then this should work. See attached for a quick sketch of how 
this would look.

What do you think about one of these?

[0001-WIP-Try-using-a-keymap-for-server-mode.patch (text/plain, attachment)]

Message #59 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 58909 <at> debbugs.gnu.org
Subject: Re: bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Wed, 02 Nov 2022 19:11:57 +0200

> Date: Wed, 2 Nov 2022 09:36:52 -0700
> Cc: 58909 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> > Sorry, but I still don't like this.  We currently call this hook via
> > safe_call because we don't want to let the hook prevent the deletion
> > of the frame.
> > 
> > I prefer to solve this in server.el, not in lower-level primitives.
> 
> Hm, ok. That means I'd need to make sure 'C-x 5 0' calls something other 
> than 'delete-frame', so that I could add a prompt to it that can prevent 
> deletion of the frame.

Why?  delete-frame eventually calls a function from server.el, doesn't
it?  We've been through that already.  Why cannot you do this inside
that server.el function?

If that's because you want to support the C-g case, then don't: that
is a separate problem.  You wanted to give the user the opportunity to
save the buffers, and that doesn't require any support for C-g.
Besides, if the user types C-g when presented with the save-buffers
prompt, how do you know that the user intends to abort deletion of the
frame, and not break out of the saving operation?

And finally, even if the user does want to prevent the deletion of the
frame, and fails in doing that, how is that a catastrophe?  Emacs is
still running and the unsaved buffers are still in the session.

I really don't see why we need to jump through any hoops for such a
simple situation.

> 1. If 'delete-frame' is a lower-level primitive, should 'C-x 5 0' call 
> it directly, or should there be a higher-level function for it to call? 
> If we had some higher-level function, then user-level commands could 
> call that, but low-level code could still use 'delete-frame'. This 
> user-level command would then be able to run some hook that can prevent 
> deletion of the frame.
> 
> 2. Since server.el has a minor mode (unsurprisingly named 
> 'server-mode'), maybe one option is to do command remapping. If we remap 
> 'delete-frame' to some new 'server-delete-frame' when 'server-mode' is 
> active, then this should work. See attached for a quick sketch of how 
> this would look.
> 
> What do you think about one of these?

Waaaay too complicated for such a simple problem.  Please, let's just
prompt the user from server-delete-client (and do that under some
opt-in option), and be done with that.

Message #62 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58909 <at> debbugs.gnu.org
Subject: Re: bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Wed, 2 Nov 2022 11:17:00 -0700

First, I just wanted to say thanks for your patience with this. I think 
this discussion has gone on a lot longer than either of us intended. I 
want to emphasize that while I'm not flexible in how my Emacs 
configuration works, I *am* flexible in what actually gets committed to 
Emacs proper. If you think my changes belong in Emacs, then I'll do the 
necessary work to get them in a merge-able state; if not, I can just 
apply them to my local configuration. Thanks again.

On 11/2/2022 10:11 AM, Eli Zaretskii wrote:
>> Date: Wed, 2 Nov 2022 09:36:52 -0700
>> Cc: 58909 <at> debbugs.gnu.org
>> From: Jim Porter <jporterbugs <at> gmail.com>
>>
>> Hm, ok. That means I'd need to make sure 'C-x 5 0' calls something other
>> than 'delete-frame', so that I could add a prompt to it that can prevent
>> deletion of the frame.
> 
> Why?  delete-frame eventually calls a function from server.el, doesn't
> it?  We've been through that already.  Why cannot you do this inside
> that server.el function?
> 
> If that's because you want to support the C-g case, then don't: that
> is a separate problem.

Yeah, this subthread about 'delete-frame' was just to support the C-g 
case. Aside from that, I think doing this inside 'server-delete-client' 
would be fine. However, at least for this bug, adding a hook that runs 
in 'server-delete-client' doesn't add anything that 
'delete-frame-functions' doesn't already allow. ('server-delete-client' 
is called from a hook in 'delete-frame-functions' in this case anyway.)

> Waaaay too complicated for such a simple problem.  Please, let's just
> prompt the user from server-delete-client (and do that under some
> opt-in option), and be done with that.

If you mean adding a defcustom, I thought we'd agreed not to do that 
(see the beginning of your message here[1]). I'm fine with that; if I 
have to write a hook to fix the issue I saw in the original message, I 
don't mind. (Of course, I'm happy to upstream my code if there's 
interest, but if not, that's ok too.) Instead, my goal was just to 
provide the bare minimum of changes to Emacs to enable a user to modify 
this to their liking without relying too heavily on 'advice-add'. :)

Would it make sense (possibly in a separate bug) to at least make sure 
that the 'server-mode' minor mode is always active when the server is 
running? The server.el code sometimes uses 'server-mode' and sometimes 
uses 'server-start', with the end result being that the minor mode may 
or may not be active depending on the way the server was started. That 
seems like a bug all on its own. If just this part were fixed, it would 
go 95% of the way to make it easy for me to make Emacs work just the way 
I like, and without having to make any major changes to Emacs itself. 
This change could be as simple as renaming 'server-start' to 
'server--start', and then have a new 'server-start' that activates the 
minor mode.

[1] https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-10/msg02642.html

Message #65 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 58909 <at> debbugs.gnu.org
Subject: Re: bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Wed, 02 Nov 2022 20:42:20 +0200

> Date: Wed, 2 Nov 2022 11:17:00 -0700
> Cc: 58909 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> > If that's because you want to support the C-g case, then don't: that
> > is a separate problem.
> 
> Yeah, this subthread about 'delete-frame' was just to support the C-g 
> case. Aside from that, I think doing this inside 'server-delete-client' 
> would be fine. However, at least for this bug, adding a hook that runs 
> in 'server-delete-client' doesn't add anything that 
> 'delete-frame-functions' doesn't already allow. ('server-delete-client' 
> is called from a hook in 'delete-frame-functions' in this case anyway.)

We cannot have behavior specific to server.el coded outside of
server.el.  So I don't think I understand what you are saying here.
My suggestion is not to add a hook, it is to add a prompt for the user
when the last client frame is deleted, and do it optionally.

> > Waaaay too complicated for such a simple problem.  Please, let's just
> > prompt the user from server-delete-client (and do that under some
> > opt-in option), and be done with that.
> 
> If you mean adding a defcustom, I thought we'd agreed not to do that 
> (see the beginning of your message here[1]).

Yes, but you keep pushing...

> Would it make sense (possibly in a separate bug) to at least make sure 
> that the 'server-mode' minor mode is always active when the server is 
> running? The server.el code sometimes uses 'server-mode' and sometimes 
> uses 'server-start', with the end result being that the minor mode may 
> or may not be active depending on the way the server was started. That 
> seems like a bug all on its own.

Maybe it's a bug, but then it's really old.

I'm not sure I understand the purpose of this minor mode, and we
ourselves start the server in the daemon mode by a direct call to
server-start.  Also, server-start is a command, and many users (myself
included) invoke it interactively.

Why is it important to have the mode turned on?  What can a mode do
that we cannot do without a mode?

Message #68 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58909 <at> debbugs.gnu.org
Subject: Re: bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Wed, 2 Nov 2022 12:16:30 -0700

[Message part 1 (text/plain, inline)]

On 11/2/2022 11:42 AM, Eli Zaretskii wrote:
>> Date: Wed, 2 Nov 2022 11:17:00 -0700
>> Cc: 58909 <at> debbugs.gnu.org
>> From: Jim Porter <jporterbugs <at> gmail.com>
>>
>>> If that's because you want to support the C-g case, then don't: that
>>> is a separate problem.
>>
>> Yeah, this subthread about 'delete-frame' was just to support the C-g
>> case. Aside from that, I think doing this inside 'server-delete-client'
>> would be fine. However, at least for this bug, adding a hook that runs
>> in 'server-delete-client' doesn't add anything that
>> 'delete-frame-functions' doesn't already allow. ('server-delete-client'
>> is called from a hook in 'delete-frame-functions' in this case anyway.)
> 
> We cannot have behavior specific to server.el coded outside of
> server.el.  So I don't think I understand what you are saying here.
> My suggestion is not to add a hook, it is to add a prompt for the user
> when the last client frame is deleted, and do it optionally.

I just meant that the existing 'delete-frame-functions' hook lets me do 
what I want by writing a hook in my local configuration (except for the 
C-g issue). I agree that for any changes to Emacs, the changes should be 
in server.el as much as possible.

>> If you mean adding a defcustom, I thought we'd agreed not to do that
>> (see the beginning of your message here[1]).
> 
> Yes, but you keep pushing...

Sorry if I seem pushy. I really am open to different solutions here, and 
I just want to present some various options I see to make it 
possible/easy to adjust the behavior of server.el. My goal is really 
just to offer what improvements I can to Emacs; if they don't belong, 
that's ok. I can just use them locally.

In short, consider my messages/patches as just an offer to help.

> I'm not sure I understand the purpose of this minor mode, and we
> ourselves start the server in the daemon mode by a direct call to
> server-start.  Also, server-start is a command, and many users (myself
> included) invoke it interactively.
> 
> Why is it important to have the mode turned on?  What can a mode do
> that we cannot do without a mode?

If starting the server activates a minor mode, then Emacs can use a 
minor-mode keymap for server-mode. That would make it easy for users to 
add keybindings that only take effect when the server is running. In my 
case, I could locally remap 'delete-frame' to some new function when the 
server is running, and then I could make that function do exactly what I 
want. Other users might want to add other keybindings to this keymap 
(maybe one for 'server-edit-abort').

In fact, for my purposes, even just having daemon mode call 
'(server-mode 1)' instead of '(server-start)' would be a good improvement.

There are other ways to do this, but having a minor mode makes it 
easier. I attached a quick patch that shows the changes I'd make so that 
users could have a 'sever-mode-keymap' to add to; if you think any of 
these changes are too risky, I don't mind removing them. If you think 
*all* of them are too risky, that's ok too. I can just do something 
equivalent in my local config.

[0001-WIP-Try-using-a-keymap-for-server-mode.patch (text/plain, attachment)]

Message #71 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 58909 <at> debbugs.gnu.org
Subject: Re: bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Wed, 02 Nov 2022 21:23:15 +0200

> Date: Wed, 2 Nov 2022 12:16:30 -0700
> Cc: 58909 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> >> If you mean adding a defcustom, I thought we'd agreed not to do that
> >> (see the beginning of your message here[1]).
> > 
> > Yes, but you keep pushing...
> 
> Sorry if I seem pushy. I really am open to different solutions here, and 
> I just want to present some various options I see to make it 
> possible/easy to adjust the behavior of server.el. My goal is really 
> just to offer what improvements I can to Emacs; if they don't belong, 
> that's ok. I can just use them locally.
> 
> In short, consider my messages/patches as just an offer to help.

Isn't the last suggestion, of having an optional prompt in
server-delete-client, good enough?

> > Why is it important to have the mode turned on?  What can a mode do
> > that we cannot do without a mode?
> 
> If starting the server activates a minor mode, then Emacs can use a 
> minor-mode keymap for server-mode. That would make it easy for users to 
> add keybindings that only take effect when the server is running. In my 
> case, I could locally remap 'delete-frame' to some new function when the 
> server is running, and then I could make that function do exactly what I 
> want. Other users might want to add other keybindings to this keymap 
> (maybe one for 'server-edit-abort').
> 
> In fact, for my purposes, even just having daemon mode call 
> '(server-mode 1)' instead of '(server-start)' would be a good improvement.

I'm fine with doing that, but we must also make sure this mode is
turned on when users invoke server-start interactively.

Message #74 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58909 <at> debbugs.gnu.org
Subject: Re: bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Wed, 2 Nov 2022 12:57:57 -0700

On 11/2/2022 12:23 PM, Eli Zaretskii wrote:
> Isn't the last suggestion, of having an optional prompt in
> server-delete-client, good enough?

'server-delete-client' is called in a bunch of spots, so at minimum, I'd 
want to be extra-careful that prompting doesn't break one of those 
cases. It would also be nice if I could fix the C-g issue, at least in 
my local configuration.

Still, I'll take a look at doing this if you think it would be good to 
add to Emacs. (If you think it's not needed, I really don't mind leaving 
the code as-is.)

>>> Why is it important to have the mode turned on?  What can a mode do
>>> that we cannot do without a mode?
>>
>> If starting the server activates a minor mode, then Emacs can use a
>> minor-mode keymap for server-mode. [snip]
> 
> I'm fine with doing that, but we must also make sure this mode is
> turned on when users invoke server-start interactively.

I think that makes sense, and it should be fairly straightforward. I'll 
work on a patch for this.

Thanks again for the extensive feedback.

Message #77 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 58909 <at> debbugs.gnu.org
Subject: Re: bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Wed, 02 Nov 2022 22:09:21 +0200

> Date: Wed, 2 Nov 2022 12:57:57 -0700
> Cc: 58909 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> On 11/2/2022 12:23 PM, Eli Zaretskii wrote:
> > Isn't the last suggestion, of having an optional prompt in
> > server-delete-client, good enough?
> 
> 'server-delete-client' is called in a bunch of spots, so at minimum, I'd 
> want to be extra-careful that prompting doesn't break one of those 
> cases.

Sorry, I meant server-handle-delete-frame.

> It would also be nice if I could fix the C-g issue, at least in my
> local configuration.

You could rebind "C-x 5 0" to a different command, and do whatever you
want there.

> Still, I'll take a look at doing this if you think it would be good to 
> add to Emacs. (If you think it's not needed, I really don't mind leaving 
> the code as-is.)

I thought my opinions on this were clear from the very beginning...

> >> If starting the server activates a minor mode, then Emacs can use a
> >> minor-mode keymap for server-mode. [snip]
> > 
> > I'm fine with doing that, but we must also make sure this mode is
> > turned on when users invoke server-start interactively.
> 
> I think that makes sense, and it should be fairly straightforward. I'll 
> work on a patch for this.

Thanks.

Message #80 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58909 <at> debbugs.gnu.org
Subject: Re: bug#58909: 29.0.50; [PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Wed, 2 Nov 2022 15:09:21 -0700

[Message part 1 (text/plain, inline)]

On 11/2/2022 1:09 PM, Eli Zaretskii wrote:
>> 'server-delete-client' is called in a bunch of spots, so at minimum, I'd
>> want to be extra-careful that prompting doesn't break one of those
>> cases.
> 
> Sorry, I meant server-handle-delete-frame.

Oh, ok. That would be easy then. But since your preference was to just 
leave things as they are, let's not make this change. I can adjust 
things locally without it.

>>>> If starting the server activates a minor mode, then Emacs can use a
>>>> minor-mode keymap for server-mode. [snip]
>>>
>>> I'm fine with doing that, but we must also make sure this mode is
>>> turned on when users invoke server-start interactively.
>>
>> I think that makes sense, and it should be fairly straightforward. I'll
>> work on a patch for this.
> 
> Thanks.

Ok, here's a patch for that. It just sets the 'server-mode' variable 
(and 'global-minor-modes' to be polite) inside 'server-start'. It would 
probably be more elegant if we could make 'server-start' just call 
'(server-mode)' (instead of the other way around like it is now), but I 
think it would be hard to do that while staying 100% compatible. Does 
this seem ok?

[0001-Enable-disable-server-mode-when-starting-stopping-th.patch (text/plain, attachment)]

Message #83 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 58909 <at> debbugs.gnu.org
Subject: Re: bug#58909: 29.0.50; [PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Thu, 03 Nov 2022 08:25:32 +0200

> Date: Wed, 2 Nov 2022 15:09:21 -0700
> Cc: 58909 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> >>> I'm fine with doing that, but we must also make sure this mode is
> >>> turned on when users invoke server-start interactively.
> >>
> >> I think that makes sense, and it should be fairly straightforward. I'll
> >> work on a patch for this.
> > 
> > Thanks.
> 
> Ok, here's a patch for that. It just sets the 'server-mode' variable 
> (and 'global-minor-modes' to be polite) inside 'server-start'. It would 
> probably be more elegant if we could make 'server-start' just call 
> '(server-mode)' (instead of the other way around like it is now), but I 
> think it would be hard to do that while staying 100% compatible. Does 
> this seem ok?

Yes, but let's wait for a few days before installing to give people
chance to chime in.

Thanks.

Message #86 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58909 <at> debbugs.gnu.org
Subject: Re: bug#58909: 29.0.50; [PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Sun, 6 Nov 2022 12:23:58 -0800

[Message part 1 (text/plain, inline)]

On 11/2/2022 11:25 PM, Eli Zaretskii wrote:
>> Date: Wed, 2 Nov 2022 15:09:21 -0700
>> Cc: 58909 <at> debbugs.gnu.org
>> From: Jim Porter <jporterbugs <at> gmail.com>
>>
>> Ok, here's a patch for that. It just sets the 'server-mode' variable
>> (and 'global-minor-modes' to be polite) inside 'server-start'. It would
>> probably be more elegant if we could make 'server-start' just call
>> '(server-mode)' (instead of the other way around like it is now), but I
>> think it would be hard to do that while staying 100% compatible. Does
>> this seem ok?
> 
> Yes, but let's wait for a few days before installing to give people
> chance to chime in.

Sounds good to me. In the meantime, I added some regression tests for my 
change (see the first attached patch). I'll take a look at adding some 
more tests for server.el code too (in another bug#, though).

I also attached a second patch to show an idea I had: since the first 
patch adds a minor-mode keymap for 'server-mode' (and ensures that the 
mode is activated whenever the server is running), we could get rid of 
the server-specific logic from lisp/files.el. Instead of mapping 'C-x 
C-c' to 'save-buffers-kill-terminal' all the time, Emacs could map it to 
'save-buffers-kill-emacs' by default. Then, when the server is running, 
remap 'save-buffers-kill-emacs' to 'save-buffers-kill-terminal'.

Given that the old code already works, I'm not sure this change is worth 
the risk (it would be very bad if I made a mistake and broke the ability 
to exit Emacs). Still, I *think* this should work just the same as the 
old code, and it helps keep server-specific code inside server.el.

I don't have any strong opinions on whether this second patch should get 
merged (I'm totally fine with throwing it out), but I wanted to show off 
at least one theoretical benefit of the new keymap.

[0001-Enable-disable-server-mode-when-starting-stopping-th.patch (text/plain, attachment)]

[0002-IDEA-Take-advantage-of-new-server-mode-map-to-handle.patch (text/plain, attachment)]

Message #89 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 58909 <at> debbugs.gnu.org
Subject: Re: bug#58909: 29.0.50; [PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Tue, 08 Nov 2022 16:47:02 +0200

> Date: Sun, 6 Nov 2022 12:23:58 -0800
> Cc: 58909 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> I also attached a second patch to show an idea I had: since the first 
> patch adds a minor-mode keymap for 'server-mode' (and ensures that the 
> mode is activated whenever the server is running), we could get rid of 
> the server-specific logic from lisp/files.el. Instead of mapping 'C-x 
> C-c' to 'save-buffers-kill-terminal' all the time, Emacs could map it to 
> 'save-buffers-kill-emacs' by default. Then, when the server is running, 
> remap 'save-buffers-kill-emacs' to 'save-buffers-kill-terminal'.

This means a different binding for "C-x C-c" depending on situation,
and the binding to save-buffers-kill-terminal depending on a minor
mode.  Previously, "C-x C-c" would do its job regardless of the mode.
I'm not sure this is for the best.  I'd be interested to hear from
others, if anyone has an opinion.

Message #92 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Jim Porter <jporterbugs <at> gmail.com>, 58909 <at> debbugs.gnu.org
Subject: Re: bug#58909: 29.0.50; [PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Tue, 08 Nov 2022 16:08:04 +0100

>>>>> On Tue, 08 Nov 2022 16:47:02 +0200, Eli Zaretskii <eliz <at> gnu.org> said:

    >> Date: Sun, 6 Nov 2022 12:23:58 -0800
    >> Cc: 58909 <at> debbugs.gnu.org
    >> From: Jim Porter <jporterbugs <at> gmail.com>
    >> 
    >> I also attached a second patch to show an idea I had: since the first 
    >> patch adds a minor-mode keymap for 'server-mode' (and ensures that the 
    >> mode is activated whenever the server is running), we could get rid of 
    >> the server-specific logic from lisp/files.el. Instead of mapping 'C-x 
    >> C-c' to 'save-buffers-kill-terminal' all the time, Emacs could map it to 
    >> 'save-buffers-kill-emacs' by default. Then, when the server is running, 
    >> remap 'save-buffers-kill-emacs' to 'save-buffers-kill-terminal'.

    Eli> This means a different binding for "C-x C-c" depending on situation,
    Eli> and the binding to save-buffers-kill-terminal depending on a minor
    Eli> mode.  Previously, "C-x C-c" would do its job regardless of the mode.
    Eli> I'm not sure this is for the best.  I'd be interested to hear from
    Eli> others, if anyone has an opinion.

Rules of Emacs:

1. If it works, donʼt change it
2. See Rule 1
3. No, really, see Rule 1

I honestly donʼt see what benefit the minor mode would bring here (and
it might just bring new and 'interesting' bugs).

Robert
-- 

Message #95 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: jporterbugs <at> gmail.com, 58909 <at> debbugs.gnu.org
Subject: Re: bug#58909: 29.0.50; [PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Tue, 08 Nov 2022 17:13:02 +0200

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: Jim Porter <jporterbugs <at> gmail.com>,  58909 <at> debbugs.gnu.org
> Date: Tue, 08 Nov 2022 16:08:04 +0100
> 
> I honestly donʼt see what benefit the minor mode would bring here (and
> it might just bring new and 'interesting' bugs).

The minor mode already exists, and has been with us for many years.

Message #98 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jporterbugs <at> gmail.com, 58909 <at> debbugs.gnu.org
Subject: Re: bug#58909: 29.0.50; [PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Tue, 08 Nov 2022 16:29:17 +0100

>>>>> On Tue, 08 Nov 2022 17:13:02 +0200, Eli Zaretskii <eliz <at> gnu.org> said:

    >> From: Robert Pluim <rpluim <at> gmail.com>
    >> Cc: Jim Porter <jporterbugs <at> gmail.com>,  58909 <at> debbugs.gnu.org
    >> Date: Tue, 08 Nov 2022 16:08:04 +0100
    >> 
    >> I honestly donʼt see what benefit the minor mode would bring here (and
    >> it might just bring new and 'interesting' bugs).

    Eli> The minor mode already exists, and has been with us for many years.

OK. I donʼt see what benefit the *use* of the minor mode in this way
brings :-)

Robert
-- 

Message #101 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Robert Pluim <rpluim <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 58909 <at> debbugs.gnu.org
Subject: Re: bug#58909: 29.0.50; [PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Tue, 8 Nov 2022 08:52:10 -0800

On 11/8/2022 7:29 AM, Robert Pluim wrote:
> OK. I donʼt see what benefit the *use* of the minor mode in this way
> brings :-)

The actual change that I'd like to merge is just to make the minor mode 
activate/deactivate consistently, whereas previously it would activate 
in some situations where you start the Emacs server, but not others. I'd 
classify that as "not working".

Having the minor mode makes it easier for third-party code (user configs 
or packages) to define key bindings that are only active when the server 
is running. That's useful to me, since I don't *always* use the Emacs 
server.

As for the change to how 'C-x C-c' is bound, I don't have any strong 
opinion on merging it. It's probably more risk than it's worth, and if 
we were to merge it, I'd prefer to do so after cutting the 29 branch, 
since then there'd be more time to find any bugs.[1] However, since the 
only real benefit is to clean up some dependencies in the code, I'm not 
sure it's worth the effort.

[1] I'd also want to have regression tests for all of that.

Message #104 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 58909 <at> debbugs.gnu.org
Subject: Re: bug#58909: 29.0.50; [PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Wed, 09 Nov 2022 11:06:08 +0100

>>>>> On Tue, 8 Nov 2022 08:52:10 -0800, Jim Porter <jporterbugs <at> gmail.com> said:

    Jim> On 11/8/2022 7:29 AM, Robert Pluim wrote:
    >> OK. I donʼt see what benefit the *use* of the minor mode in this way
    >> brings :-)

    Jim> The actual change that I'd like to merge is just to make the minor
    Jim> mode activate/deactivate consistently, whereas previously it would
    Jim> activate in some situations where you start the Emacs server, but not
    Jim> others. I'd classify that as "not working".

That sounds good

    Jim> Having the minor mode makes it easier for third-party code (user
    Jim> configs or packages) to define key bindings that are only active when
    Jim> the server is running. That's useful to me, since I don't *always* use
    Jim> the Emacs server.

as does this

    Jim> As for the change to how 'C-x C-c' is bound, I don't have any strong
    Jim> opinion on merging it. It's probably more risk than it's worth, and if
    Jim> we were to merge it, I'd prefer to do so after cutting the 29 branch,
    Jim> since then there'd be more time to find any bugs.[1] However, since
    Jim> the only real benefit is to clean up some dependencies in the code,
    Jim> I'm not sure it's worth the effort.

I think it would be too risky a change.

Robert
-- 

Message #107 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 58909 <at> debbugs.gnu.org
Subject: Re: bug#58909: 29.0.50; [PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Wed, 16 Nov 2022 21:17:44 -0800

On 11/9/2022 2:06 AM, Robert Pluim wrote:
> That sounds good
[snip]
> as does this
[snip]
> I think it would be too risky a change.

Thanks. I agree with all that.

Since there haven't been any further comments in the past week, I've 
merged just the first patch (to make 'server-mode' (de)activate at the 
right times) as 0147e1ed831151dddac65727886d5a70bbab9f02.

Message #110 received at 58909 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 58909 <at> debbugs.gnu.org, Robert Pluim <rpluim <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Thu, 7 Sep 2023 14:03:39 -0700

Jim Porter <jporterbugs <at> gmail.com> writes:

> On 11/9/2022 2:06 AM, Robert Pluim wrote:
>> That sounds good
> [snip]
>> as does this
> [snip]
>> I think it would be too risky a change.
>
> Thanks. I agree with all that.
>
> Since there haven't been any further comments in the past week, I've merged just the first patch (to make
> 'server-mode' (de)activate at the right times) as 0147e1ed831151dddac65727886d5a70bbab9f02.

This was a long thread.  From skimming it, it's not clear to me if
there's anything left to do here?

Message #115 received at 58909-done <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 58909-done <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Robert Pluim <rpluim <at> gmail.com>
Subject: Re: bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an
 emacsclient doesn't ask to save
Date: Thu, 7 Sep 2023 18:21:34 -0700

On 9/7/2023 2:03 PM, Stefan Kangas wrote:
> Jim Porter <jporterbugs <at> gmail.com> writes:
> 
>> On 11/9/2022 2:06 AM, Robert Pluim wrote:
>>> That sounds good
>> [snip]
>>> as does this
>> [snip]
>>> I think it would be too risky a change.
>>
>> Thanks. I agree with all that.
>>
>> Since there haven't been any further comments in the past week, I've merged just the first patch (to make
>> 'server-mode' (de)activate at the right times) as 0147e1ed831151dddac65727886d5a70bbab9f02.
> 
> This was a long thread.  From skimming it, it's not clear to me if
> there's anything left to do here?

Yeah, I'd say we're done here; I just forgot to close the bug at the 
time. Closing this now.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.