GNU bug report logs - #21833
24.4; desktop-kill, which is interactive, is in kill-emacs-hook

Previous Next

Full log

View this message in rfc822 format

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 21833 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, Stelian Iancu <si <at> siancu.net>
Subject: bug#21833: 24.4; desktop-kill, which is interactive, is in kill-emacs-hook
Date: Fri, 13 Nov 2015 00:53:56 +0100

[Message part 1 (text/plain, inline)]

On Fri, Nov 13, 2015 at 12:38 AM, Glenn Morris <rgm <at> gnu.org> wrote:

> The point is, kill-emacs-hook can run in situations where it is
> impossible for Emacs to interact with the user.
> Any yes-or-no-p questions will never be answered.
> Emacs will hang and have to be forcibly killed.
> Exactly as it says in the OP.

Yes, I understand. My point being, kill-emacs does *not* guarantee that it
will kill Emacs (as my simple hook example shows). It could be designed to
offer that guarantee, but it doesn't currently. So the possibility of
having to forcibly kill Emacs is always there.

> So don't put anything on kill-emacs-hook that needs an interactive
> response from the user. Decide on a sensible non-interactive behaviour,
> and for the interactive case use kill-emacs-query-functions.
> The documentation seems clear to me.

I'd agree, but in some cases, the "sensible non-interactive behaviour" is
just to abort killing Emacs (that's what emacs-lock does, for example, if
it has one or more exit-locked buffers). Which is conceptually different of
asking the user and never getting an answer...? OK, it is, but Emacs will
"hang and have to be forcibly killed" anyway. Same difference.

I suppose what I'm trying to say is that "should not" is a recommendation,
nothing more and nothing less. But certainly I won't argue this point to
exhaustion.

[Message part 2 (text/html, inline)]

Previous Next

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