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

View this message in rfc822 format

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58909 <at> debbugs.gnu.org
Subject: 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)]

Previous Next

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