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

Previous Next

Package: emacs;

Reported by: Jim Porter <jporterbugs <at> gmail.com>

Date: Sun, 30 Oct 2022 22:30:02 UTC

Severity: normal

Tags: patch

Found in version 29.0.50

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

Bug is archived. No further changes may be made.

Full log


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.




This bug report was last modified 1 year and 259 days ago.

Previous Next


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