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

[Jim Porter]

On 10/31/2022 12:43 PM, Eli Zaretskii wrote:
> > Date: Mon, 31 Oct 2022 12:28:23 -0700
> > Cc: 58909@debbugs.gnu.org
> > From: Jim Porter <jporterbugs@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.