From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#28542: Temporary failure in name resolution while quitting emacs Date: Mon, 30 Nov 2020 18:21:52 +0200 Message-ID: <83o8jeke73.fsf@gnu.org> References: <87lfejcdzv.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7700"; mail-complaints-to="usenet@ciao.gmane.io" Cc: bshanks3@hotmail.com, 28542@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Nov 30 17:23:25 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kjlxV-0001sZ-Ag for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 30 Nov 2020 17:23:25 +0100 Original-Received: from localhost ([::1]:33524 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kjlxU-0007Kv-AR for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 30 Nov 2020 11:23:24 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56612) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kjlxA-0007Jm-HL for bug-gnu-emacs@gnu.org; Mon, 30 Nov 2020 11:23:07 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44893) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kjlx8-0008SS-9S for bug-gnu-emacs@gnu.org; Mon, 30 Nov 2020 11:23:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kjlx8-0005yA-6X for bug-gnu-emacs@gnu.org; Mon, 30 Nov 2020 11:23:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 30 Nov 2020 16:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28542 X-GNU-PR-Package: emacs Original-Received: via spool by 28542-submit@debbugs.gnu.org id=B28542.160675333122863 (code B ref 28542); Mon, 30 Nov 2020 16:23:02 +0000 Original-Received: (at 28542) by debbugs.gnu.org; 30 Nov 2020 16:22:11 +0000 Original-Received: from localhost ([127.0.0.1]:56439 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kjlwJ-0005wh-J3 for submit@debbugs.gnu.org; Mon, 30 Nov 2020 11:22:11 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:38106) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kjlwI-0005wS-EI for 28542@debbugs.gnu.org; Mon, 30 Nov 2020 11:22:10 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58827) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kjlwB-0008Kf-Rx; Mon, 30 Nov 2020 11:22:03 -0500 Original-Received: from [176.228.60.248] (port=2909 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kjlw8-0004TZ-OV; Mon, 30 Nov 2020 11:22:01 -0500 In-Reply-To: <87lfejcdzv.fsf@gnus.org> (message from Lars Ingebrigtsen on Mon, 30 Nov 2020 11:53:24 +0100) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:194652 Archived-At: > From: Lars Ingebrigtsen > Date: Mon, 30 Nov 2020 11:53:24 +0100 > Cc: 28542@debbugs.gnu.org > > > 2) more importantly, if there is an error in something called from > > kill-emacs-hook, emacs should not just return to normal functioning > > (without quitting), but rather should give the user a choice of > > whether to continue to quit or not (if continue to quit is chosen, the > > remaining items in kill-emacs-hook should be called). It's really > > frustrating to a user when the user cannot figure out how to quit a > > program. > > I agree. To reproduce: > > (push (lambda () (error "this is an error")) kill-emacs-hook) > `C-x C-c' > > Result: Just an error message, and you can't kill Emacs. I think it > should catch the error and ask whether to continue anyway. Opinions? The ELisp manual says ab out kill-emacs-hook: Because ‘kill-emacs’ can be called in situations where user interaction is impossible (e.g., when the terminal is disconnected), functions on this hook should not attempt to interact with the user. If you want to interact with the user when Emacs is shutting down, use ‘kill-emacs-query-functions’, described below. So I don't think we can safely ask whether to continue. We could either use safe_run_hooks, as we do in the noninteractive case (thus silently ignoring errors in this hook even if we do have a means to communicate with the user), or maybe move the offending function to kill-emacs-query-functions. Or try a more limited solution of ensuring this particular function doesn't signal an error, or catches it and returns. > The flow control here is a bit odd, though. `save-buffers-kill-emacs' > calls Fkill_emacs, which starts: > > DEFUN ("kill-emacs", Fkill_emacs, Skill_emacs, 0, 1, "P", > [...] > /* Fsignal calls emacs_abort () if it sees that waiting_for_input is > set. */ > waiting_for_input = 0; > if (noninteractive) > safe_run_hooks (Qkill_emacs_hook); > else > run_hook (Qkill_emacs_hook); > > Is this bit done from the C level because of that waiting_for_input > setting? And... I don't understand the comment -- the `error' (which > calls signal?) doesn't abort Emacs? Anybody? I think the comment has this exact scenario in mind: if we don't make sure waiting_for_input is zero, and the hook just happens to signal an error, Emacs will dump core.