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

[Eli Zaretskii]

> Date: Mon, 31 Oct 2022 12:38:04 -0700
> From: Jim Porter <jporterbugs@gmail.com>
> Cc: 58909@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.