bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an emacsclien


From: Eli Zaretskii
Subject: bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an emacsclient doesn't ask to save
Date: Tue, 01 Nov 2022 08:39:25 +0200

> Date: Mon, 31 Oct 2022 14:06:16 -0700
> Cc: 58909@debbugs.gnu.org
> From: Jim Porter <jporterbugs@gmail.com>
> 
> 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).

I don't see how this would serve well the use case you want to enable.
We are talking about prompting the user to save unsaved buffers, yes?
So adding a hook in server-delete-client sounds like a much better
solution to me, as it doesn't affect the (much more general)
delete-frame in any way.

> 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.

You can start the discussion now, from my POV.  But if having a hook
in server-delete-client is good enough, I don't see why we would need
to discuss an actual behavior change.

(And the proviso of backing out changes doesn't work in this project,
IME: people get defensive about their changes, and perceive reverting
them as personal insult.  So we do that only in very extreme cases.)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]