From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.bugs 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-ID: References: <5644F186.1000405@siancu.net> <5644F584.5060205@siancu.net> <83wptngcxy.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113fc40a5269b0052460aac3 X-Trace: ger.gmane.org 1447372520 19835 80.91.229.3 (12 Nov 2015 23:55:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 12 Nov 2015 23:55:20 +0000 (UTC) Cc: 21833@debbugs.gnu.org, Stelian Iancu To: Glenn Morris Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Nov 13 00:55:11 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zx1hv-0006Zd-56 for geb-bug-gnu-emacs@m.gmane.org; Fri, 13 Nov 2015 00:55:11 +0100 Original-Received: from localhost ([::1]:50336 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zx1hu-0004rb-Gc for geb-bug-gnu-emacs@m.gmane.org; Thu, 12 Nov 2015 18:55:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48664) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zx1hq-0004r3-Rd for bug-gnu-emacs@gnu.org; Thu, 12 Nov 2015 18:55:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zx1hm-0007we-Qb for bug-gnu-emacs@gnu.org; Thu, 12 Nov 2015 18:55:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:44533) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zx1hm-0007wQ-Ny for bug-gnu-emacs@gnu.org; Thu, 12 Nov 2015 18:55:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Zx1hm-0004c5-BT for bug-gnu-emacs@gnu.org; Thu, 12 Nov 2015 18:55:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Juanma Barranquero Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Nov 2015 23:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21833 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21833-submit@debbugs.gnu.org id=B21833.144737249817720 (code B ref 21833); Thu, 12 Nov 2015 23:55:02 +0000 Original-Received: (at 21833) by debbugs.gnu.org; 12 Nov 2015 23:54:58 +0000 Original-Received: from localhost ([127.0.0.1]:35241 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zx1hh-0004bj-QI for submit@debbugs.gnu.org; Thu, 12 Nov 2015 18:54:58 -0500 Original-Received: from mail-lf0-f51.google.com ([209.85.215.51]:33282) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zx1hN-0004bK-HY for 21833@debbugs.gnu.org; Thu, 12 Nov 2015 18:54:56 -0500 Original-Received: by lffz63 with SMTP id z63so43677801lff.0 for <21833@debbugs.gnu.org>; Thu, 12 Nov 2015 15:54:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=277Ys/a5UVSfEu9kXH05w1QPFWeFwPoZvRf9vwUkBn0=; b=NO98Q6Yx6ycgnpzmJfNqpjkF58NKgHCQVbjp7rjD/4bPGO3d9/V/XyCL4HBDFz8oUB cSMLRfMHIWn3etwncN28ZUC5YRzjwamoEDxM6RhU2MwaeFuAtof2oTgxE6xlyMuWAgVf t7bV1fNJROBaBqjBzFmhe3freboMbGtyeuxMQ5mVaVgRMg5189ZXxfvjubi93Jc8RKYt 8Q0k1qV19Uxa2Xv+0wogMWN7M5puf11+PfPzHgaRi2JFOg7SPptTe2+3PJZJLsQVlJNy u4CP+NKFugM5/lmVXRNmBw+6DZ2zARL3OrbKdihO8NtvyD4h5bI3eRXo0w+0qJpGSFAm ieww== X-Received: by 10.25.135.136 with SMTP id j130mr8481845lfd.95.1447372476539; Thu, 12 Nov 2015 15:54:36 -0800 (PST) Original-Received: by 10.25.21.198 with HTTP; Thu, 12 Nov 2015 15:53:56 -0800 (PST) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:108695 Archived-At: --001a113fc40a5269b0052460aac3 Content-Type: text/plain; charset=UTF-8 On Fri, Nov 13, 2015 at 12:38 AM, Glenn Morris 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. --001a113fc40a5269b0052460aac3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Nov 13, 2015 at 12:38 AM, Glenn Morris <rgm@gnu.org> wrote:

> The poi= nt 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 wil= l 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 guaran= tee, 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 fro= m the user. Decide on a sensible non-interactive behaviour,
> and for= the interactive case use kill-emacs-query-functions.
> The documenta= tion 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 th= e 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&= quot; is a recommendation, nothing more and nothing less. But certainly I w= on't argue this point to exhaustion.

--001a113fc40a5269b0052460aac3--