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

Previous Next

Full log

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.

Previous Next

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