[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.)
- bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an emacsclient doesn't ask to save, Eli Zaretskii, 2022/11/01
- bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an emacsclient doesn't ask to save,
Eli Zaretskii <=
- bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an emacsclient doesn't ask to save, Jim Porter, 2022/11/01
- bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an emacsclient doesn't ask to save, Jim Porter, 2022/11/01
- bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an emacsclient doesn't ask to save, Eli Zaretskii, 2022/11/02
- bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an emacsclient doesn't ask to save, Jim Porter, 2022/11/02
- bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an emacsclient doesn't ask to save, Eli Zaretskii, 2022/11/02
- bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an emacsclient doesn't ask to save, Jim Porter, 2022/11/02
- bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an emacsclient doesn't ask to save, Eli Zaretskii, 2022/11/02
- bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an emacsclient doesn't ask to save, Jim Porter, 2022/11/02
- bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an emacsclient doesn't ask to save, Eli Zaretskii, 2022/11/02
- bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an emacsclient doesn't ask to save, Jim Porter, 2022/11/02