From unknown Fri Jun 13 11:31:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28542: Temporary failure in name resolution while quitting emacs Resent-From: Baylis Shanks Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 21 Sep 2017 17:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 28542 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 28542@debbugs.gnu.org X-Debbugs-Original-To: "bug-gnu-emacs@gnu.org" Received: via spool by submit@debbugs.gnu.org id=B.150601448112190 (code B ref -1); Thu, 21 Sep 2017 17:22:02 +0000 Received: (at submit) by debbugs.gnu.org; 21 Sep 2017 17:21:21 +0000 Received: from localhost ([127.0.0.1]:51830 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dv5A9-0003AY-2v for submit@debbugs.gnu.org; Thu, 21 Sep 2017 13:21:21 -0400 Received: from eggs.gnu.org ([208.118.235.92]:52492) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dv53J-0002xt-5K for submit@debbugs.gnu.org; Thu, 21 Sep 2017 13:14:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dv53C-0001th-A0 for submit@debbugs.gnu.org; Thu, 21 Sep 2017 13:14:11 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: *** X-Spam-Status: No, score=3.6 required=5.0 tests=BAYES_50, FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE, RECEIVED_FROM_WINDOWS_HOST,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:57478) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dv53C-0001ta-5v for submit@debbugs.gnu.org; Thu, 21 Sep 2017 13:14:10 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43462) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dv53A-0004ft-Vc for bug-gnu-emacs@gnu.org; Thu, 21 Sep 2017 13:14:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dv536-0001rv-KK for bug-gnu-emacs@gnu.org; Thu, 21 Sep 2017 13:14:08 -0400 Received: from mail-oln040092009058.outbound.protection.outlook.com ([40.92.9.58]:45157 helo=NAM04-BN3-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dv536-0001pG-8h for bug-gnu-emacs@gnu.org; Thu, 21 Sep 2017 13:14:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=W91EQONFemjyGw+dx28tbR3FpM136f56AMIE9XrP1Wk=; b=uTpinUwUJp+uMBhGGe88D6b5Mge3P5QlxHQrNIxFPgy3XIP6g3qc98yzlxcEsB7CM/eqIXbXIjV7PX/Ek7HGXBqIF9x3MOKIv7Y5682z7yIjYpl+LYyCjNvu+2bIq64sinEPSFeHfPPSVlDjhP53DRR5tsfaTLIdJScBOuenqUHrdFHKVuHnmDZan6uwUrL8p2tYv6gTehkNmqPg9xEHvP4TJHVfyeflhQbcOH88CWknTgPVS6x8grM+5fDbst3aUSHOuuHYgNnNoY2JoUpTP4ePAmRDeSdTPHOpAnPFUhOwfDK+vzcc2xY0O3XlFf767/8sDAY/A1xLEvtowZJhkg== Received: from SN1NAM04FT027.eop-NAM04.prod.protection.outlook.com (10.152.88.57) by SN1NAM04HT125.eop-NAM04.prod.protection.outlook.com (10.152.89.194) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.35.14; Thu, 21 Sep 2017 17:14:00 +0000 Received: from BN6PR10MB1700.namprd10.prod.outlook.com (10.152.88.60) by SN1NAM04FT027.mail.protection.outlook.com (10.152.88.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.35.14 via Frontend Transport; Thu, 21 Sep 2017 17:14:00 +0000 Received: from BN6PR10MB1700.namprd10.prod.outlook.com ([10.172.20.18]) by BN6PR10MB1700.namprd10.prod.outlook.com ([10.172.20.18]) with mapi id 15.20.0077.011; Thu, 21 Sep 2017 17:14:00 +0000 From: Baylis Shanks Thread-Topic: Temporary failure in name resolution while quitting emacs Thread-Index: AQHTMvzO8L4pZHBVFE6FqXSDGBUJjQ== Date: Thu, 21 Sep 2017 17:13:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gnu.org; dkim=none (message not signed) header.d=none;gnu.org; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:5B6E2C10DB86385CEC2F2095B15FF690373CA5047EA7DD34F0F38963EDB1F735; UpperCasedChecksum:16DA1772A2FD20373A0BE52A09CEAA11D59D396D6A2D6B84832FAF91636BAD33; SizeAsReceived:6870; Count:44 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [QKDIVMwRSztFIrrDO2Xn5RHAwjJA4vd3] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1NAM04HT125; 6:HlJcunP7Bmg0iKsq1yQeQhx50mAvAl9S2kLba8thnO9TSTWqPB0QdGeuLQPOqYei3e2EQEJurXB3fzCw3Y8xXUsSFVx60MUw1RuH8BpbfR6P+eMLwwoXhcTNBF+6pF/evA7OKmNvnzP+XurF1HY++JmkCHSzZjK2w/MFtHCKjfuEZNpwcpUagLYvSICzfvJhpWsxehXxYDVTwMDOr4coq9HQXlCu0dRMoFPt9LiPYVRWQqd5Y8Sv1fO9sADaY4sd9z1BtpxzfDQZ2yz+NXYFkK7q2LYQ97GUUXBOcVRa6Fs1feLff4ZXKzf4Zujvl9ifM2SqtdzMafmuawThcY9pSA==; 5:7pDtnOoIYnT90SfWVQQZqNRbV5v2cqf/P2YMslYb9rknFDwj7G+pDb0mmKAeB3stsZHmj+ttSjJr2oiqX5/p87OoMUdbLdrGQfeGsnV9hzphpZk5UoCMQSh+CwxAcHmAYjrc1VnfqS2CcS8K3kL+4A==; 24:AIZa9l7tRIKaH4C+Nb0+eXtbf8SwW+oMYb0GmmVueSuHccW1ngWXMHsfqqDetGgUkYu2UczHHCVtg8VJe22EH5PUq6y8EbthS1Oq0Ztuj98=; 7:FF+hA3nUtRWoc0SrFc4q9uRVfxW3oolLtuyN+QF6K47E8dZXP9smm+hX2a6tYfUx1hbyadWM6XdmTnlHX2pjsR56nMxiPFZI387frUuaD+oubNYMUSbVpT4451xjnB41bPZDtRqwdnsgvUYvUl8QQU0CO3ry8ZvP8nZ0hJ6Q5Qz1k0uSHIFHvM3bNx2S5SdKyETcKUhaBcb9Omof3LhTYaDs6l4Dpi9F8hZH+2qnwso= x-incomingheadercount: 44 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 2d15b7ff-c0d4-4705-5f15-08d50114269d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN1NAM04HT125; x-ms-traffictypediagnostic: SN1NAM04HT125: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:SN1NAM04HT125; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN1NAM04HT125; x-forefront-prvs: 04371797A5 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:SN1NAM04HT125; H:BN6PR10MB1700.namprd10.prod.outlook.com; FPR:; SPF:None; LANG:; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR10MB17006C4999F9A9170DE674F992660BN6PR10MB1700namp_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Sep 2017 17:13:59.7552 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM04HT125 X-detected-operating-system: by eggs.gnu.org: Windows 7 or 8 [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -3.8 (---) X-Mailman-Approved-At: Thu, 21 Sep 2017 13:21:19 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.8 (---) --_000_BN6PR10MB17006C4999F9A9170DE674F992660BN6PR10MB1700namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I had an http address open in a buffer (i think i closed that buffer), and = then i disconnected from the internet and then attempted to quit emacs. Ema= cs would not quit; when i attempted to quit it, a message involving 'open-n= etwork-stream' and 'temporary failure in name resolution' would be displaye= d in *messages* and then nothing would happen. Manually opening an elisp buffer and using setq to remove save-place-kill-e= macs-hook from kill-emacs-hook solved the problem. I think there are really two bugs here; 1) whatever save-place-kill-emacs-hook is doing should be robust to 'tempor= ary failure in name resolution' errors 2) more importantly, if there is an error in something called from kill-ema= cs-hook, emacs should not just return to normal functioning (without quitti= ng), but rather should give the user a choice of whether to continue to qui= t 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 can= not figure out how to quit a program. --_000_BN6PR10MB17006C4999F9A9170DE674F992660BN6PR10MB1700namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I had an http address open in a buffer (i think i closed that buffer), a= nd then i disconnected from the internet and then attempted to quit emacs. = Emacs would not quit; when i attempted to quit it, a message involving 'ope= n-network-stream' and 'temporary failure in name resolution' would be displayed in *messages* and then= nothing would happen.


Manually opening an elisp buffer and using setq to remove save-place-kill-emacs-hook from kill-emacs-hook solved the problem= .


I think there are really two bugs here;


1) whatever save-place-kill-emacs-hook is doing should be r= obust to 'temporary failure in name resolution' errors


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 sho= uld be called). It's really frustrating to a user when the user cannot figu= re out how to quit a program.


--_000_BN6PR10MB17006C4999F9A9170DE674F992660BN6PR10MB1700namp_-- From unknown Fri Jun 13 11:31:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28542: Temporary failure in name resolution while quitting emacs Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 30 Nov 2020 10:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28542 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Baylis Shanks Cc: 28542@debbugs.gnu.org Received: via spool by 28542-submit@debbugs.gnu.org id=B28542.160673361724586 (code B ref 28542); Mon, 30 Nov 2020 10:54:02 +0000 Received: (at 28542) by debbugs.gnu.org; 30 Nov 2020 10:53:37 +0000 Received: from localhost ([127.0.0.1]:53662 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kjgoL-0006OU-1e for submit@debbugs.gnu.org; Mon, 30 Nov 2020 05:53:37 -0500 Received: from quimby.gnus.org ([95.216.78.240]:34552) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kjgoJ-0006OF-7C for 28542@debbugs.gnu.org; Mon, 30 Nov 2020 05:53:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=YUf57cAXpHZXjg/Z/avh+Vguykvw/GgISPmQq0jtt44=; b=uNuFyBgcwZX0Ge/UrYVBVmD3Ai aNKq7auNj9lkRiqJtv8nhIXDpuxBKMXokdQ3NgEzjs5BBR7+pu427fZAKAFnLAnBpE7p0XwkK16PJ mfmWVKFHkXd5qua/QKCP493eXHVkcSvpWzhK63i13VoK9/jFjZ/NRV8H+W6xHjnaD31Y=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kjgoA-0007wm-6g; Mon, 30 Nov 2020 11:53:28 +0100 From: Lars Ingebrigtsen References: X-Now-Playing: Lightning Bolt's _Sonic Citadel_: "Tom Thump" Date: Mon, 30 Nov 2020 11:53:24 +0100 In-Reply-To: (Baylis Shanks's message of "Thu, 21 Sep 2017 17:13:59 +0000") Message-ID: <87lfejcdzv.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Baylis Shanks writes: > I had an http address open in a buffer (i think i closed that buffer), > and then i disconnected from the internet and then attempted to quit > emacs. Emacs would not quit; when i attempted to quit [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Baylis Shanks writes: > I had an http address open in a buffer (i think i closed that buffer), > and then i disconnected from the internet and then attempted to quit > emacs. Emacs would not quit; when i attempted to quit it, a message > involving 'open-network-stream' and 'temporary failure in name > resolution' would be displayed in *messages* and then nothing would > happen. > > Manually opening an elisp buffer and using setq to remove > save-place-kill-emacs-hook from kill-emacs-hook solved the problem. (This bug report unfortunately got no response at the time.) I'm guessing you don't have a backtrace here to let us see what the code in question was after all this time? > 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 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? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Fri Jun 13 11:31:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28542: Temporary failure in name resolution while quitting emacs 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 X-GNU-PR-Keywords: To: Lars Ingebrigtsen Cc: bshanks3@hotmail.com, 28542@debbugs.gnu.org Received: via spool by 28542-submit@debbugs.gnu.org id=B28542.160675333122863 (code B ref 28542); Mon, 30 Nov 2020 16:23:02 +0000 Received: (at 28542) by debbugs.gnu.org; 30 Nov 2020 16:22:11 +0000 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 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 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 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 Date: Mon, 30 Nov 2020 18:21:52 +0200 Message-Id: <83o8jeke73.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87lfejcdzv.fsf@gnus.org> (message from Lars Ingebrigtsen on Mon, 30 Nov 2020 11:53:24 +0100) References: <87lfejcdzv.fsf@gnus.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. From unknown Fri Jun 13 11:31:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28542: Temporary failure in name resolution while quitting emacs Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Dec 2020 09:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28542 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: bshanks3@hotmail.com, 28542@debbugs.gnu.org Received: via spool by 28542-submit@debbugs.gnu.org id=B28542.16069024667191 (code B ref 28542); Wed, 02 Dec 2020 09:48:02 +0000 Received: (at 28542) by debbugs.gnu.org; 2 Dec 2020 09:47:46 +0000 Received: from localhost ([127.0.0.1]:34251 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kkOji-0001ru-17 for submit@debbugs.gnu.org; Wed, 02 Dec 2020 04:47:46 -0500 Received: from quimby.gnus.org ([95.216.78.240]:58534) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kkOjd-0001re-Gu for 28542@debbugs.gnu.org; Wed, 02 Dec 2020 04:47:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=K7W2gziqtxlZRx1vESeea0WTl/6gsnPbrnV7wafTZMA=; b=ZMTY4HL0zYyjeArAaU/HyLjfKr ykC2CB9j+0R8mWzXYAyt1AqI6BYQFI9m+yfVDHIM74SGnn41DWRQAttAxn0nYJNtEyQPqLGkaePfn xsaNFdQG3Wt28151OcS2eYSwXW9dd6MX97EqIHBZ0M25lUgpl78DCOb6YhEMtHwnRKyI=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kkOjU-0004UC-HE; Wed, 02 Dec 2020 10:47:35 +0100 From: Lars Ingebrigtsen References: <87lfejcdzv.fsf@gnus.org> <83o8jeke73.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAD1BMVEXp5OKzpqKKeHVS PTv///9X6rKaAAAAAWJLR0QEj2jZUQAAAAd0SU1FB+QMAgklKYtopboAAAGSSURBVDjLbZMLtsMg CETRbgBxA4obaHT/e3sDfpK2j9M0jdeBwRIKhEiNI9OJqBTJnwNAuUHoADP+UZDnyh8gKGUqW1G+ FMl3tvJRY6Zi/gV8in+DsH7m8lVjg1hiXbs5WY0bhLqyjMofYKUKqfWCzn8AtTau/xQkBsZxFesG quMNgM7hg5I8wRWbAQ+AGlaqBlDQudQFcIMpzjiPUQRZUtIKoC5lsh1SAXBXRLxCQrUA0EZNwTLJ AlXQc0hpDBgj3y72SSpFVNjAFUhPgFbp6qAracfjXAbIVdMGQ+b+jgvZsM2AzAY5ApinLuJgnLPS 1n3SNNdsQE2BC+m6tX5AWwqYtWGJAJeDtP5o1LT5enVpVzup7shdxgTVgWUh+3r1tEAhq30GyhQz +LFqrq8b8BqzBdpcv4j4U6ELuCLcoLbu4E3TLq3X5AA2EA1M1auOCeirxgY2u/xk+QBbfXQC0JZb 4mcy1d0epsT9LMdNp8KWps8FJG/F7ANgn8nYbu10Yc1f9gO6vxrknoN747COMPEfhaRNUtUweIMA AAAldEVYdGRhdGU6Y3JlYXRlADIwMjAtMTItMDJUMDk6Mzc6NDErMDA6MDBEeQz4AAAAJXRFWHRk YXRlOm1vZGlmeQAyMDIwLTEyLTAyVDA5OjM3OjQxKzAwOjAwNSS0RAAAAABJRU5ErkJggg== X-Now-Playing: David Sylvian's _Brilliant Trees_: "The Ink In The Well" Date: Wed, 02 Dec 2020 10:47:31 +0100 In-Reply-To: <83o8jeke73.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 30 Nov 2020 18:21:52 +0200") Message-ID: <875z5k5yks.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > The ELisp manual says ab out kill-emacs-hook: > > Because =?UTF-8?Q?=E2=80=98kill-emacs=E2=80=99?= can be called in situations where user > interaction is impossible (e.g., when the terminal is > disconnected), functions o [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > The ELisp manual says ab out kill-emacs-hook: > > Because =E2=80=98kill-emacs=E2=80=99 can be called in situations whe= re 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 =E2=80=98kill-emacs-query-functions=E2= =80=99, described > below. > > So I don't think we can safely ask whether to continue. I don't quite interpret it that way -- this only says that if your intention is to communicate with the user, then use `kill-emacs-query-functions'. The current situation is that if you have an error in `kill-emacs-hook' (and you're running an interactive Emacs), then you can't kill Emacs at all. Adding a query to the user about what to do is an improvement, and won't regress anything. > 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. I'm a bit leery at doing anything automatically (either ignoring the error or re-running it from a different context). The hook may be, for instance, writing stuff to a data file and then clearing out some structures, and re-writing the stuff may clear the data, for instance. Only the user should be making a judgement call in the error situation here. >> The flow control here is a bit odd, though. `save-buffers-kill-emacs' >> calls Fkill_emacs, which starts: >>=20 >> 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 =3D 0; >> if (noninteractive) >> safe_run_hooks (Qkill_emacs_hook); >> else >> run_hook (Qkill_emacs_hook); >>=20 >> 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. Oh, I interpreted it the opposite way -- that "waiting_for_input =3D 0" is setting it. To zero. But it means "isn't cleared"? --=20 (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Fri Jun 13 11:31:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28542: Temporary failure in name resolution while quitting emacs Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Dec 2020 15:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28542 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Lars Ingebrigtsen Cc: bshanks3@hotmail.com, 28542@debbugs.gnu.org Received: via spool by 28542-submit@debbugs.gnu.org id=B28542.16069216203768 (code B ref 28542); Wed, 02 Dec 2020 15:07:02 +0000 Received: (at 28542) by debbugs.gnu.org; 2 Dec 2020 15:07:00 +0000 Received: from localhost ([127.0.0.1]:36802 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kkTie-0000yi-0E for submit@debbugs.gnu.org; Wed, 02 Dec 2020 10:07:00 -0500 Received: from eggs.gnu.org ([209.51.188.92]:55394) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kkTib-0000yG-Sy for 28542@debbugs.gnu.org; Wed, 02 Dec 2020 10:06:58 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:51183) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kkTiV-00010d-Qz; Wed, 02 Dec 2020 10:06:52 -0500 Received: from [176.228.60.248] (port=3949 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kkTiV-0003aq-07; Wed, 02 Dec 2020 10:06:51 -0500 Date: Wed, 02 Dec 2020 17:06:48 +0200 Message-Id: <837dq0gsc7.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <875z5k5yks.fsf@gnus.org> (message from Lars Ingebrigtsen on Wed, 02 Dec 2020 10:47:31 +0100) References: <87lfejcdzv.fsf@gnus.org> <83o8jeke73.fsf@gnu.org> <875z5k5yks.fsf@gnus.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: bshanks3@hotmail.com, 28542@debbugs.gnu.org > Date: Wed, 02 Dec 2020 10:47:31 +0100 > > Eli Zaretskii writes: > > > 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. > > I don't quite interpret it that way -- this only says that if your > intention is to communicate with the user, then use > `kill-emacs-query-functions'. But your suggestion was to ask the user whether to continue -- doesn't that qualify as "communicating with the user"? > The current situation is that if you have an error in `kill-emacs-hook' > (and you're running an interactive Emacs), then you can't kill Emacs at > all. Adding a query to the user about what to do is an improvement, and > won't regress anything. That's true, but I don't suggest to do nothing, I was trying to find a better way, one which would work also when there's no way to get any answer from the user. > > 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. > > I'm a bit leery at doing anything automatically (either ignoring the > error or re-running it from a different context). The hook may be, for > instance, writing stuff to a data file and then clearing out some > structures, and re-writing the stuff may clear the data, for instance. > > Only the user should be making a judgement call in the error situation > here. Then perhaps waiting for the response for some finite time would cover the cases where the user cannot answer the question? > >> /* 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. > > Oh, I interpreted it the opposite way -- that "waiting_for_input = 0" is > setting it. To zero. But it means "isn't cleared"? Yes, setting to zero is "resetting". The abort happens if the value is non-zero. From unknown Fri Jun 13 11:31:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28542: Temporary failure in name resolution while quitting emacs Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Dec 2020 08:48:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28542 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: bshanks3@hotmail.com, 28542@debbugs.gnu.org Received: via spool by 28542-submit@debbugs.gnu.org id=B28542.160698524632000 (code B ref 28542); Thu, 03 Dec 2020 08:48:01 +0000 Received: (at 28542) by debbugs.gnu.org; 3 Dec 2020 08:47:26 +0000 Received: from localhost ([127.0.0.1]:38272 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kkkGs-0008Jt-0T for submit@debbugs.gnu.org; Thu, 03 Dec 2020 03:47:26 -0500 Received: from quimby.gnus.org ([95.216.78.240]:42860) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kkkGq-0008Ga-Sv for 28542@debbugs.gnu.org; Thu, 03 Dec 2020 03:47:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=RvrufwHKzFW4TJYzYlZQfMcHA1ZKE3uynS2yix6WLK8=; b=Z1sjKrwBIC+gjmBYrGRaGkEBwL eBlayhXWyn3xDWzgogBmbrvurFVpQi1W//OUyN5QThA7XDB8/J97eU9w7DSQgul/1ESJ8Q1HtfSIZ 1U2jyADPAfwrhOOf8QVpSDnuh7Sefd2ZRw1HXjUpMa1mbfhI2KJVnGgptPr2snW2J3DA=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kkkGi-00012q-A4; Thu, 03 Dec 2020 09:47:19 +0100 From: Lars Ingebrigtsen References: <87lfejcdzv.fsf@gnus.org> <83o8jeke73.fsf@gnu.org> <875z5k5yks.fsf@gnus.org> <837dq0gsc7.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAD1BMVEVZTT8uJRyIgZ8F BAP///+2LH48AAAAAWJLR0QEj2jZUQAAAAd0SU1FB+QMAwgnLQdNDnMAAAGBSURBVDjLbZPtmQMh CITBNABrA54VhLP/3jKAnuvm/JMnvgvDx0hMVBorTh3DeqeOgwsiIeIxzxt3CSzAa4HS86yIusC8 7zTBurcVAU0ivUks8AIYQrqAtCwqIlj0T4KQOMCPp9oBVhqAp2sAsmtKiWumUq5fRSXYEkZ3wDcg JSfSUdERIQTZMqva90hFlCEP4H2sIdYHaNhO9HECwc7KFanG7jtBJwdY0B2YArTfAHYC1Nsd8NhL CoCZtneIO7BRVc2iQVX2wTcqFB+ifR0KgBFTgHsq3KMaayXB0QaAlpIuORrHH/kHuISb8QlMeW3L nbgbNOZl0xYRtpj4+usGMq1oHF8FgD+rrZoB8IXmAwmLInJW5UByheQO6DMkKskIckB9Ph2VOqty 57p9U16z9W9gYXCL1ssEkR3i6ETma1ugugTe6XL2PQKNpK2eEe7ERhtIqLv8BdA3yJDmg8VPeYCL FTtq0soWRy7WN4sP7QT+egaJMCx9pFJRfZGwhMYkH4kThDOIAyfIAAAAJXRFWHRkYXRlOmNyZWF0 ZQAyMDIwLTEyLTAzVDA4OjM5OjQ1KzAwOjAw3QFQTAAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMC0x Mi0wM1QwODozOTo0NSswMDowMKxc6PAAAAAASUVORK5CYII= X-Now-Playing: Mia Doi Todd's _Floresta_: "Menina, =?UTF-8?Q?Amanh=C3=A3?= De =?UTF-8?Q?Manh=C3=A3?=" Date: Thu, 03 Dec 2020 09:47:14 +0100 In-Reply-To: <837dq0gsc7.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 02 Dec 2020 17:06:48 +0200") Message-ID: <87o8jbxoml.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: >> > The ELisp manual says ab out kill-emacs-hook: >> > >> > Because =?UTF-8?Q?=E2=80=98kill-emacs=E2=80=99?= can be called in situations where user >> > interaction is impossible (e.g., when the terminal is >> > disconnecte [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> > The ELisp manual says ab out kill-emacs-hook: >> > >> > Because =E2=80=98kill-emacs=E2=80=99 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 wh= en >> > Emacs is shutting down, use =E2=80=98kill-emacs-query-functions= =E2=80=99, described >> > below. >> > >> > So I don't think we can safely ask whether to continue. >>=20 >> I don't quite interpret it that way -- this only says that if your >> intention is to communicate with the user, then use >> `kill-emacs-query-functions'. > > But your suggestion was to ask the user whether to continue -- doesn't > that qualify as "communicating with the user"? It does. But the manual talks about intent -- "if you want to interact" -- but doesn't prohibit Emacs itself from interacting with the user. Obviously an error doesn't happen by intent. > Then perhaps waiting for the response for some finite time would cover > the cases where the user cannot answer the question? Do you mean in the noninteractive case? I don't propose to change anything unless interactive. --=20 (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Fri Jun 13 11:31:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28542: Temporary failure in name resolution while quitting emacs Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Dec 2020 15:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28542 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Lars Ingebrigtsen Cc: bshanks3@hotmail.com, 28542@debbugs.gnu.org Received: via spool by 28542-submit@debbugs.gnu.org id=B28542.160700863215669 (code B ref 28542); Thu, 03 Dec 2020 15:18:01 +0000 Received: (at 28542) by debbugs.gnu.org; 3 Dec 2020 15:17:12 +0000 Received: from localhost ([127.0.0.1]:41372 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kkqM4-00044O-1t for submit@debbugs.gnu.org; Thu, 03 Dec 2020 10:17:12 -0500 Received: from eggs.gnu.org ([209.51.188.92]:60422) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kkqM1-0003y4-AS for 28542@debbugs.gnu.org; Thu, 03 Dec 2020 10:17:10 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:45223) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kkqLv-0006oS-VM; Thu, 03 Dec 2020 10:17:03 -0500 Received: from [176.228.60.248] (port=1865 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kkqLv-0007er-EA; Thu, 03 Dec 2020 10:17:03 -0500 Date: Thu, 03 Dec 2020 17:16:43 +0200 Message-Id: <83h7p2gbs4.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87o8jbxoml.fsf@gnus.org> (message from Lars Ingebrigtsen on Thu, 03 Dec 2020 09:47:14 +0100) References: <87lfejcdzv.fsf@gnus.org> <83o8jeke73.fsf@gnu.org> <875z5k5yks.fsf@gnus.org> <837dq0gsc7.fsf@gnu.org> <87o8jbxoml.fsf@gnus.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: bshanks3@hotmail.com, 28542@debbugs.gnu.org > Date: Thu, 03 Dec 2020 09:47:14 +0100 > > Eli Zaretskii writes: > > >> > 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. > >> > >> I don't quite interpret it that way -- this only says that if your > >> intention is to communicate with the user, then use > >> `kill-emacs-query-functions'. > > > > But your suggestion was to ask the user whether to continue -- doesn't > > that qualify as "communicating with the user"? > > It does. But the manual talks about intent -- "if you want to interact" > -- but doesn't prohibit Emacs itself from interacting with the user. > Obviously an error doesn't happen by intent. I think the manual talks about situations where the communications are impossible. What do we do in that case? > > Then perhaps waiting for the response for some finite time would cover > > the cases where the user cannot answer the question? > > Do you mean in the noninteractive case? I don't propose to change > anything unless interactive. No, I was talking about the interactive case. Are you assuming that in the interactive case it is always possible to ask a question and get a response from the user? From unknown Fri Jun 13 11:31:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28542: Temporary failure in name resolution while quitting emacs Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 04 Dec 2020 09:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28542 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: bshanks3@hotmail.com, 28542@debbugs.gnu.org Received: via spool by 28542-submit@debbugs.gnu.org id=B28542.16070745055792 (code B ref 28542); Fri, 04 Dec 2020 09:36:02 +0000 Received: (at 28542) by debbugs.gnu.org; 4 Dec 2020 09:35:05 +0000 Received: from localhost ([127.0.0.1]:42617 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kl7UW-0001VM-NV for submit@debbugs.gnu.org; Fri, 04 Dec 2020 04:35:04 -0500 Received: from quimby.gnus.org ([95.216.78.240]:56284) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kl7UV-0001Uk-7T for 28542@debbugs.gnu.org; Fri, 04 Dec 2020 04:35:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=iscVJi7gMbg/Lflbgyxs9+wAYd2bwzSNretPNLnowxw=; b=MdfEdgehPr2ar/Mdoiemm3WUiK tLY+s5rhBMv/c3BnZmpTS/EsoVenKauhgtppLQUxPWrHMmUJY2ax3vJ1ttiqZNdy5i3Mpr8fHf98V Ge3siOB0E2byzSxXoA8lJA/g+uWQjZYqmcnv+o88BPnI+aNjtBj86VNWBsNiwGOnzglo=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kl7UI-0006in-RC; Fri, 04 Dec 2020 10:34:56 +0100 From: Lars Ingebrigtsen References: <87lfejcdzv.fsf@gnus.org> <83o8jeke73.fsf@gnu.org> <875z5k5yks.fsf@gnus.org> <837dq0gsc7.fsf@gnu.org> <87o8jbxoml.fsf@gnus.org> <83h7p2gbs4.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAHlBMVEU4Xo1JbpdNdaBg j62aqrbv8+MtRnXZtYAnN2H///+0oGb7AAAAAWJLR0QJ8dml7AAAAAd0SU1FB+QMBAggJkIJeYUA AAGASURBVDjLdZNLTsQwDIZTCc16DFyg7g2aIPbTVByAZt9VNXuQ5gYox8aPPCvwLEb1l992HNsY YwDgGSerhvQF5DTXQfxoM8AEYIDnsQrsjCPAVeMgVgGRUSUcBquAJSASOd8IUvqrgqkFkgVM63dL JRk47xbvl5omARfC5gvgyySwhhD8ui0lDRqNFNS2WprJkdRaMNMlCvAVaKkZLI2C/3wGa9LMnKOJ JCIuOoG30Nun1XLn9QRCAnhWhBuF4ocN/4Cn8FcoepHXs3/jJhoaBud8Y9p3s8swtG/O9x6Bx+T0 5uIXQFP1zX2hFnxZ+76oX+p9YfBBTgU0JIMA0E6qwt1QJlFH+pQhjWgPUEpSSQfmBnAOVwQICdCG EHjo8Yn9lOJidm4K2umRB0q346CfrkIf6EJgL0siprUyYMmga4Vjznww2JUQk4UdRMBANHJR3bEE YgJUNh0u/ruJlRQ7FMSfE2FBZBCPTsRfUYGQvRxnQQIcrbVYQE/uDegQf/4CJrPmcJViBpAAAAAl dEVYdGRhdGU6Y3JlYXRlADIwMjAtMTItMDRUMDg6MzI6MzgrMDA6MDCzCjsXAAAAJXRFWHRkYXRl Om1vZGlmeQAyMDIwLTEyLTA0VDA4OjMyOjM4KzAwOjAwwleDqwAAAABJRU5ErkJggg== X-Now-Playing: Edh's =?UTF-8?Q?=5FV=C3=A4nskap?= 002_: "Slaughter" Date: Fri, 04 Dec 2020 10:34:49 +0100 In-Reply-To: <83h7p2gbs4.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 03 Dec 2020 17:16:43 +0200") Message-ID: <875z5hoqx2.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > No, I was talking about the interactive case. Are you assuming that > in the interactive case it is always possible to ask a question and > get a response from the user? Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > No, I was talking about the interactive case. Are you assuming that > in the interactive case it is always possible to ask a question and > get a response from the user? Isn't that usually the case? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Fri Jun 13 11:31:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28542: Temporary failure in name resolution while quitting emacs Resent-From: Robert Pluim Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 04 Dec 2020 09:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28542 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Lars Ingebrigtsen Cc: Eli Zaretskii , bshanks3@hotmail.com, 28542@debbugs.gnu.org Received: via spool by 28542-submit@debbugs.gnu.org id=B28542.16070754437581 (code B ref 28542); Fri, 04 Dec 2020 09:51:02 +0000 Received: (at 28542) by debbugs.gnu.org; 4 Dec 2020 09:50:43 +0000 Received: from localhost ([127.0.0.1]:42709 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kl7je-0001yD-Pw for submit@debbugs.gnu.org; Fri, 04 Dec 2020 04:50:42 -0500 Received: from mail-wr1-f49.google.com ([209.85.221.49]:39126) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kl7jc-0001xx-NN for 28542@debbugs.gnu.org; Fri, 04 Dec 2020 04:50:41 -0500 Received: by mail-wr1-f49.google.com with SMTP id e7so4683115wrv.6 for <28542@debbugs.gnu.org>; Fri, 04 Dec 2020 01:50:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:mail-copies-to:gmane-reply-to-list :date:in-reply-to:message-id:mime-version:content-transfer-encoding; bh=RNXDQQYdBKdhMUIpSyNszhYkBM6MfCKLfSKImBMI4NE=; b=lJ+5+kV5xlWzKjHOkIh0HSlvA5DY8/yUE0oX323LiHiSd7i1M0QUD0HnkwItnI0JrM AonBBfcxw+m8j8ITME82jsxST91pzQJGL+Lzr38tofqjzrw1+C/8ZYHqPftOuum8tYmB IficjkN47AuvLcda/zyqNzd8FULRhl7gIbJCF17f8raKmixUL2+o4RJzeLsFfvvUQuHe tG7TwpTvlbBN6shYDj2ai3LL6eZpNE433v8c/W20cbKNTCgvlUrMsoWDvdMIxeRYs6VW s++QBbLgo5OTAe4n/lXAI68FPAeLTfdmpvanOpJQcGm0SYUK2C/+Qv9hAc8Klfo97Gm7 T/7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:mail-copies-to :gmane-reply-to-list:date:in-reply-to:message-id:mime-version :content-transfer-encoding; bh=RNXDQQYdBKdhMUIpSyNszhYkBM6MfCKLfSKImBMI4NE=; b=OBEnCJ4JentssUloUwUJQq8mROXJ8REUIysZogyfCEL6jAhMNLBkpXMqijpUlV4LCG uxaKj1Oq17YG6eqveqxUcE/peQoBgOhxYRe/QjFO0Sd0YWmLHZmmrQlv4nV2pWf/bds5 SRXJ3wjlAfuB9Mn+vUqCl8p46Oo88AN3vxOccy0sk8hvwwtcqRF93VViTM6AtDmUu9CP n4uBO+ZFvbjSlfbIPh3hN1O0E2Hedyx8Lnmw/b8PwgevN0vY77h/4ZVlD5Ye2VmnRx1r WRZkcfXt4vugSBZVIqiap2eBRz3g1I7e117epYFT08Zn0Wg5eqvjTrDycK09ulLyJ+RU y/eg== X-Gm-Message-State: AOAM5326ZeHp++posHGuZuiZEMdQ277X9x1uTBO58d+GhBcJi86u520n Sr9TY0seHlEfbBqwucH+92cx+Q/lCqY= X-Google-Smtp-Source: ABdhPJyQ10OIetexzqf4S0eN1qD/pe6k8wlF//4BrgTSDSiFVNN4rUgNcqBfYqRQcVvDmDUoh7JB3g== X-Received: by 2002:adf:a1c2:: with SMTP id v2mr3903425wrv.95.1607075434740; Fri, 04 Dec 2020 01:50:34 -0800 (PST) Received: from rltb ([2a01:e34:ecfc:a860:a462:1b7f:725d:c239]) by smtp.gmail.com with ESMTPSA id m81sm1529303wmf.29.2020.12.04.01.50.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Dec 2020 01:50:34 -0800 (PST) From: Robert Pluim References: <87lfejcdzv.fsf@gnus.org> <83o8jeke73.fsf@gnu.org> <875z5k5yks.fsf@gnus.org> <837dq0gsc7.fsf@gnu.org> <87o8jbxoml.fsf@gnus.org> <83h7p2gbs4.fsf@gnu.org> <875z5hoqx2.fsf@gnus.org> Mail-Copies-To: never Gmane-Reply-To-List: yes Date: Fri, 04 Dec 2020 10:50:33 +0100 In-Reply-To: <875z5hoqx2.fsf@gnus.org> (Lars Ingebrigtsen's message of "Fri, 04 Dec 2020 10:34:49 +0100") Message-ID: <87im9hew7q.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Lars Ingebrigtsen writes: > Eli Zaretskii writes: > >> No, I was talking about the interactive case. Are you assuming that >> in the interactive case it is always possible to ask a question and >> get a response from the user? > > Isn't that usually the case? I=CA=BCd say most of the time, but given the (incomprehensible to me) enthusiasm for running 'emacs --daemon', I wouldn't be surprised if there were cases where it=CA=BCs not true. Robert From unknown Fri Jun 13 11:31:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28542: Temporary failure in name resolution while quitting emacs Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 04 Dec 2020 11:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28542 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Lars Ingebrigtsen Cc: bshanks3@hotmail.com, 28542@debbugs.gnu.org Received: via spool by 28542-submit@debbugs.gnu.org id=B28542.160708215212150 (code B ref 28542); Fri, 04 Dec 2020 11:43:02 +0000 Received: (at 28542) by debbugs.gnu.org; 4 Dec 2020 11:42:32 +0000 Received: from localhost ([127.0.0.1]:43123 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kl9Ts-00039u-Fe for submit@debbugs.gnu.org; Fri, 04 Dec 2020 06:42:32 -0500 Received: from eggs.gnu.org ([209.51.188.92]:55402) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kl9Tr-00039j-FF for 28542@debbugs.gnu.org; Fri, 04 Dec 2020 06:42:31 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:42195) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kl9Tm-0006OR-51; Fri, 04 Dec 2020 06:42:26 -0500 Received: from [176.228.60.248] (port=1800 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kl9Tl-0006I4-6F; Fri, 04 Dec 2020 06:42:25 -0500 Date: Fri, 04 Dec 2020 13:42:06 +0200 Message-Id: <83pn3per1t.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <875z5hoqx2.fsf@gnus.org> (message from Lars Ingebrigtsen on Fri, 04 Dec 2020 10:34:49 +0100) References: <87lfejcdzv.fsf@gnus.org> <83o8jeke73.fsf@gnu.org> <875z5k5yks.fsf@gnus.org> <837dq0gsc7.fsf@gnu.org> <87o8jbxoml.fsf@gnus.org> <83h7p2gbs4.fsf@gnu.org> <875z5hoqx2.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: bshanks3@hotmail.com, 28542@debbugs.gnu.org > Date: Fri, 04 Dec 2020 10:34:49 +0100 > > Eli Zaretskii writes: > > > No, I was talking about the interactive case. Are you assuming that > > in the interactive case it is always possible to ask a question and > > get a response from the user? > > Isn't that usually the case? Usually, yes. But what about the "unusual" cases? If they exist, waiting for an answer there will leave Emacs hung. I proposed to use a timeout for those cases. From unknown Fri Jun 13 11:31:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28542: Temporary failure in name resolution while quitting emacs Resent-From: Glenn Morris Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 04 Dec 2020 18:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28542 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 28542@debbugs.gnu.org, Eli Zaretskii , bshanks3@hotmail.com Cc: Lars Ingebrigtsen Received: via spool by 28542-submit@debbugs.gnu.org id=B28542.160710732829396 (code B ref 28542); Fri, 04 Dec 2020 18:43:01 +0000 Received: (at 28542) by debbugs.gnu.org; 4 Dec 2020 18:42:08 +0000 Received: from localhost ([127.0.0.1]:45782 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1klG1w-0007e3-DN for submit@debbugs.gnu.org; Fri, 04 Dec 2020 13:42:08 -0500 Received: from eggs.gnu.org ([209.51.188.92]:49314) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1klG1u-0007df-Nl for 28542@debbugs.gnu.org; Fri, 04 Dec 2020 13:42:07 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56814) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1klG1p-0003Pj-26; Fri, 04 Dec 2020 13:42:01 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1klG1m-0005rl-5w; Fri, 04 Dec 2020 13:41:58 -0500 From: Glenn Morris References: <87lfejcdzv.fsf@gnus.org> <83o8jeke73.fsf@gnu.org> <875z5k5yks.fsf@gnus.org> <837dq0gsc7.fsf@gnu.org> <87o8jbxoml.fsf@gnus.org> <83h7p2gbs4.fsf@gnu.org> <875z5hoqx2.fsf@gnus.org> <87im9hew7q.fsf@gmail.com> X-Spook: Crypto AG Disaster medical assistance team kilo class X-Ran: w/o*MgEH{%sD!@1#]yQDGW%nl2Ol)d+er#B;c-.NM!Ogu*0'R:-sctGdKF0>'sp/Ty]-^/ X-Hue: brightwhite X-Attribution: GM Date: Fri, 04 Dec 2020 13:41:57 -0500 In-Reply-To: <87im9hew7q.fsf@gmail.com> (Robert Pluim's message of "Fri, 04 Dec 2020 10:50:33 +0100") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Robert Pluim wrote: >>> No, I was talking about the interactive case. Are you assuming that >>> in the interactive case it is always possible to ask a question and >>> get a response from the user? >> >> Isn't that usually the case? > > I=CA=BCd say most of the time, but given the (incomprehensible to me) > enthusiasm for running 'emacs --daemon', I wouldn't be surprised if > there were cases where it=CA=BCs not true. See https://debbugs.gnu.org/13697 Putting anything on kill-emacs-hook that may need user input will hang Emacs in certain circumstances. (The lispref text on this reads clearly to = me.) From unknown Fri Jun 13 11:31:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28542: Temporary failure in name resolution while quitting emacs Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Dec 2020 12:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28542 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: bshanks3@hotmail.com, 28542@debbugs.gnu.org Received: via spool by 28542-submit@debbugs.gnu.org id=B28542.160725902717427 (code B ref 28542); Sun, 06 Dec 2020 12:51:02 +0000 Received: (at 28542) by debbugs.gnu.org; 6 Dec 2020 12:50:27 +0000 Received: from localhost ([127.0.0.1]:49110 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kltUh-0004X0-8L for submit@debbugs.gnu.org; Sun, 06 Dec 2020 07:50:27 -0500 Received: from quimby.gnus.org ([95.216.78.240]:52172) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kltUe-0004Wl-Vk for 28542@debbugs.gnu.org; Sun, 06 Dec 2020 07:50:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=RW3iUQX2Mlrz/7Lq7zUiBaPeEoNo9DP9JpmY+S7BzPg=; b=VDTA16vVbuKVZAtwuwswlUGjJm UCNL/WFWLVfDRKohJMTYhzsTk8A+n0PzO9Sj/zTW+j1pI3JxYIAWXfu4evydfQH1orHrPPhr3EQ2f bt+I1AKgne421OUVc2BVJumAo8V8aZKkz8KiwLCVJTPi7qnSWhWR72F+oJ4Z698xayq4=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kltUW-0004Fi-CF; Sun, 06 Dec 2020 13:50:18 +0100 From: Lars Ingebrigtsen References: <87lfejcdzv.fsf@gnus.org> <83o8jeke73.fsf@gnu.org> <875z5k5yks.fsf@gnus.org> <837dq0gsc7.fsf@gnu.org> <87o8jbxoml.fsf@gnus.org> <83h7p2gbs4.fsf@gnu.org> <875z5hoqx2.fsf@gnus.org> <83pn3per1t.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAIVBMVEXtp6LitLf00NTT fIf0pVrTQ0L47Ng8Hjr7sUz8+vP///8C4WxoAAAAAWJLR0QKaND0VgAAAAd0SU1FB+QMBgwtMdl0 4lgAAAGZSURBVDjLdZM9a8MwEIbPjbP7bEpnqxDIluKUkC2DChk7WGTPIPBYSmu6Z/CcQaB/25Nk 2ZKrvoTEvgd93CMFoEDEkj6rFQBiAVwI0QLCAxvz3BCoC8gNOCGUK8Qsy9jmseVAofpFmEeGNoyt heCUnL+ZhwH8TOXaTDFQbvZnBLS4AUIMAz8BcAdqArUD7QmQ1Qg5B6217Dpp0ukxUl4Z+Me57DIB lgb6vxFaq6Ao9plfQ6tghKLNZdNUwQgC5Ma/RIDaT07Vnqlz/3INgFXi9hpvFYFzN0LWWB1nQEYY SLmRDA+H/t0cE2QlWbUNOrvMHpRo9gDlCPym0koi6dTH7mFUouR1EwIRKFm4gpRdJc75LbW4cTXM dlNK7FsAZiWxRE09Fw50XQSmBo1dpROAZq2a4wJsqfzUU37mxZsd3ZIPrHqbb+2P605KAPopr18v iNtJSb8Iq7bulkTVy4W+Pp0ScxJyDi2kVH52wDp35eCWjCCsGyUAfg5C6m/n7jxSwPwRU67iSx3Y XRSDe1U1h6Vd7PR9YdfmF6X7CfqABWmUAAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIwLTEyLTA2VDEy OjQ1OjQ5KzAwOjAw9K+VcwAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMC0xMi0wNlQxMjo0NTo0OSsw MDowMIXyLc8AAAAASUVORK5CYII= X-Now-Playing: Max de Wardener's _Music For Detuned Pianos_: "Blueshift" Date: Sun, 06 Dec 2020 13:50:14 +0100 In-Reply-To: <83pn3per1t.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 04 Dec 2020 13:42:06 +0200") Message-ID: <874kkzf69l.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > Usually, yes. But what about the "unusual" cases? If they exist, > waiting for an answer there will leave Emacs hung. I proposed to use > a timeout for those cases. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > Usually, yes. But what about the "unusual" cases? If they exist, > waiting for an answer there will leave Emacs hung. I proposed to use > a timeout for those cases. Sure, a prompt with a timeout would be fine by me. Looking at the code again: /* 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); Would it make sense to create a new Lisp-level function to do the run-hook/prompting stuff, and call out to that? And move the setting of waiting_for_input into the "then" branch? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Fri Jun 13 11:31:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28542: Temporary failure in name resolution while quitting emacs Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Dec 2020 12:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28542 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Glenn Morris Cc: Eli Zaretskii , bshanks3@hotmail.com, 28542@debbugs.gnu.org Received: via spool by 28542-submit@debbugs.gnu.org id=B28542.160725920817692 (code B ref 28542); Sun, 06 Dec 2020 12:54:01 +0000 Received: (at 28542) by debbugs.gnu.org; 6 Dec 2020 12:53:28 +0000 Received: from localhost ([127.0.0.1]:49114 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kltXb-0004bI-N1 for submit@debbugs.gnu.org; Sun, 06 Dec 2020 07:53:27 -0500 Received: from quimby.gnus.org ([95.216.78.240]:52206) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kltXa-0004b6-OL for 28542@debbugs.gnu.org; Sun, 06 Dec 2020 07:53:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=QyzNhMINTxWBj4rC8xi9P/8Vc5tZ5DcazdqIcTwJlJ8=; b=BT3NjHVxqnr8sNsZc9cyauz53G rsHwArDJ33eOYffm7Ci2NaIVSZWFwhtm0QULI4kJDvJfDlYiMUlTvb3tGWPbNawyHKr89zExb41WZ G7BF+miwbZZw/9s4Cn2kwag7TN9OXhBJ9A1MwPwfycLekA2mUZPbmfWRgub1uUUUp5JY=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kltXS-0004GP-7v; Sun, 06 Dec 2020 13:53:20 +0100 From: Lars Ingebrigtsen References: <87lfejcdzv.fsf@gnus.org> <83o8jeke73.fsf@gnu.org> <875z5k5yks.fsf@gnus.org> <837dq0gsc7.fsf@gnu.org> <87o8jbxoml.fsf@gnus.org> <83h7p2gbs4.fsf@gnu.org> <875z5hoqx2.fsf@gnus.org> <87im9hew7q.fsf@gmail.com> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAIVBMVEXtp6LitLf00NTT fIf0pVrTQ0L47Ng8Hjr7sUz8+vP///8C4WxoAAAAAWJLR0QKaND0VgAAAAd0SU1FB+QMBgwtMdl0 4lgAAAGZSURBVDjLdZM9a8MwEIbPjbP7bEpnqxDIluKUkC2DChk7WGTPIPBYSmu6Z/CcQaB/25Nk 2ZKrvoTEvgd93CMFoEDEkj6rFQBiAVwI0QLCAxvz3BCoC8gNOCGUK8Qsy9jmseVAofpFmEeGNoyt heCUnL+ZhwH8TOXaTDFQbvZnBLS4AUIMAz8BcAdqArUD7QmQ1Qg5B6217Dpp0ukxUl4Z+Me57DIB lgb6vxFaq6Ao9plfQ6tghKLNZdNUwQgC5Ma/RIDaT07Vnqlz/3INgFXi9hpvFYFzN0LWWB1nQEYY SLmRDA+H/t0cE2QlWbUNOrvMHpRo9gDlCPym0koi6dTH7mFUouR1EwIRKFm4gpRdJc75LbW4cTXM dlNK7FsAZiWxRE09Fw50XQSmBo1dpROAZq2a4wJsqfzUU37mxZsd3ZIPrHqbb+2P605KAPopr18v iNtJSb8Iq7bulkTVy4W+Pp0ScxJyDi2kVH52wDp35eCWjCCsGyUAfg5C6m/n7jxSwPwRU67iSx3Y XRSDe1U1h6Vd7PR9YdfmF6X7CfqABWmUAAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIwLTEyLTA2VDEy OjQ1OjQ5KzAwOjAw9K+VcwAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMC0xMi0wNlQxMjo0NTo0OSsw MDowMIXyLc8AAAAASUVORK5CYII= X-Now-Playing: Max de Wardener's _Music For Detuned Pianos_: "Deranged Landscape" Date: Sun, 06 Dec 2020 13:53:16 +0100 In-Reply-To: (Glenn Morris's message of "Fri, 04 Dec 2020 13:41:57 -0500") Message-ID: <87zh2rdrk3.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Glenn Morris writes: > See https://debbugs.gnu.org/13697 > > Putting anything on kill-emacs-hook that may need user input will hang > Emacs in certain circumstances. (The lispref text on this reads clearly to me.) Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Glenn Morris writes: > See https://debbugs.gnu.org/13697 > > Putting anything on kill-emacs-hook that may need user input will hang > Emacs in certain circumstances. (The lispref text on this reads clearly to me.) I'm not quite sure I see the relevance here -- any prompt that Emacs issues may hang Emacs in some circumstances, and there's nothing special about adding a prompt here. (I agree that there should be a way to make Emacs non-interactive -- I run Emacs as a remote daemon a lot, and slapping down all the interactive queries that pepper the Emacs code is a chore.) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Fri Jun 13 11:31:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28542: Temporary failure in name resolution while quitting emacs Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Dec 2020 19:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28542 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Lars Ingebrigtsen Cc: bshanks3@hotmail.com, 28542@debbugs.gnu.org Received: via spool by 28542-submit@debbugs.gnu.org id=B28542.1607282300480 (code B ref 28542); Sun, 06 Dec 2020 19:19:02 +0000 Received: (at 28542) by debbugs.gnu.org; 6 Dec 2020 19:18:20 +0000 Received: from localhost ([127.0.0.1]:51328 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1klzY4-00007g-1n for submit@debbugs.gnu.org; Sun, 06 Dec 2020 14:18:20 -0500 Received: from eggs.gnu.org ([209.51.188.92]:58730) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1klzY2-00007U-MP for 28542@debbugs.gnu.org; Sun, 06 Dec 2020 14:18:18 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:41322) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1klzXt-0000kX-L6; Sun, 06 Dec 2020 14:18:10 -0500 Received: from [176.228.60.248] (port=2189 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1klzXs-0001rq-4Y; Sun, 06 Dec 2020 14:18:09 -0500 Date: Sun, 06 Dec 2020 21:17:55 +0200 Message-Id: <83im9eagm4.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <874kkzf69l.fsf@gnus.org> (message from Lars Ingebrigtsen on Sun, 06 Dec 2020 13:50:14 +0100) References: <87lfejcdzv.fsf@gnus.org> <83o8jeke73.fsf@gnu.org> <875z5k5yks.fsf@gnus.org> <837dq0gsc7.fsf@gnu.org> <87o8jbxoml.fsf@gnus.org> <83h7p2gbs4.fsf@gnu.org> <875z5hoqx2.fsf@gnus.org> <83pn3per1t.fsf@gnu.org> <874kkzf69l.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: bshanks3@hotmail.com, 28542@debbugs.gnu.org > Date: Sun, 06 Dec 2020 13:50:14 +0100 > > Sure, a prompt with a timeout would be fine by me. > > Looking at the code again: > > /* 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); > > Would it make sense to create a new Lisp-level function to do the > run-hook/prompting stuff, and call out to that? And move the setting of > waiting_for_input into the "then" branch? I think it'd be good to have a run_hook_with_timeout function, yes. Whether it should be exposed to Lisp, I'm less certain: what would be the use case that isn't this single place? As for zeroing waiting_for_input: it's almost certainly shouldn't be part of that, since it should always be zero when Emacs signals an error. We do this here because this might be exiting due to a fatal signal, in which case all bets are off, and we should better be safe than sorry. From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 07 09:40:51 2020 Received: (at control) by debbugs.gnu.org; 7 Dec 2020 14:40:51 +0000 Received: from localhost ([127.0.0.1]:53006 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmHh5-0006Tm-GE for submit@debbugs.gnu.org; Mon, 07 Dec 2020 09:40:51 -0500 Received: from quimby.gnus.org ([95.216.78.240]:37570) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmHh3-0006TY-Cj for control@debbugs.gnu.org; Mon, 07 Dec 2020 09:40:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=EpjpRAvdOWyrtyPrnB6HepXMa8Ac3dWJguEZkjZHoKM=; b=hfVczF0h1FlcnXxDtzoc9vo0LM 4BDi0M2JMr19y879Cpj+eWn76UvLJmcaQK1RvwUksnT49uGKlphFlNFl0L1n2d4Dx6qEkV8Cj6ru9 V8qnodRk69goNjZTC2T5SF0lU1IV728oE3etIhB2gkR142XfSQJojQfyB4phTAR+RjXc=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kmHgu-0006Rv-Sp for control@debbugs.gnu.org; Mon, 07 Dec 2020 15:40:43 +0100 Date: Mon, 07 Dec 2020 15:40:36 +0100 Message-Id: <87v9ddisrf.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #28542 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: tags 28542 fixed close 28542 28.1 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) tags 28542 fixed close 28542 28.1 quit From unknown Fri Jun 13 11:31:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28542: Temporary failure in name resolution while quitting emacs Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 07 Dec 2020 14:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28542 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed To: Eli Zaretskii Cc: bshanks3@hotmail.com, 28542@debbugs.gnu.org Received: via spool by 28542-submit@debbugs.gnu.org id=B28542.160735223325263 (code B ref 28542); Mon, 07 Dec 2020 14:44:02 +0000 Received: (at 28542) by debbugs.gnu.org; 7 Dec 2020 14:43:53 +0000 Received: from localhost ([127.0.0.1]:53021 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmHk1-0006ZO-It for submit@debbugs.gnu.org; Mon, 07 Dec 2020 09:43:53 -0500 Received: from quimby.gnus.org ([95.216.78.240]:37782) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmHk0-0006ZA-EG for 28542@debbugs.gnu.org; Mon, 07 Dec 2020 09:43:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=mtf/OSXoWaKopv1BMrVNjtWuQ41Zp48pXCAmABXYzWA=; b=prVIesVoUb0OgiykEUv76Gzb3m VWKT/4Jqj6D/Gwszw5sOyrTPrD3GjAEKvKFgjyuZhAXq2DiDRtsvbysB9Ehe1TvAR9ZtClPqpcCVK WQ60DfshIt30KLwekrg3y22keeaDLIU78CxLwcBjMX6XIvjBR5AZTaUyU9JWtCPBWp4A=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kmHjs-0006UG-6B; Mon, 07 Dec 2020 15:43:46 +0100 From: Lars Ingebrigtsen References: <87lfejcdzv.fsf@gnus.org> <83o8jeke73.fsf@gnu.org> <875z5k5yks.fsf@gnus.org> <837dq0gsc7.fsf@gnu.org> <87o8jbxoml.fsf@gnus.org> <83h7p2gbs4.fsf@gnu.org> <875z5hoqx2.fsf@gnus.org> <83pn3per1t.fsf@gnu.org> <874kkzf69l.fsf@gnus.org> <83im9eagm4.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAGFBMVEU2BQg1BQlCFQ9W MBpgPSBgPh5lQyL///+IZ1FlAAAAAWJLR0QHFmGI6wAAAAd0SU1FB+QMBw4FOTHKd8sAAAFmSURB VDjLdZONccMwCIWBCYBmAKEs0KRpB4jbLtANet1/hoJ+bMlOyF185hO8JywBMrRAGAKBTFpkVf+r kaZVQyTxmgJReAKR5AcSqSVEtgW9oubVHmhAOJ4lwArwpIiB7ACiIXuzqchCA80lRFlCTIZW5DvV nJmrGq4AmQlfJSqw7zM1gJxapvBeYUjSpF1UPSfdLrk1fxYNoBR+ApBosdMFFLgCDBAF1Sv7+rJB J1ndrHiqfgFrIwHUaM7oKOpYZQCeQv+1COD1qJ4Kww5cjguoPmQLaxUV8I4EwLVirdMVkL/hVqNr K5IpGkCQQ1RQDM7pPt2XPHeSPsS3hTdffgD6EPV6s229rRo+kq9LT2vfeZnc6efoKval74sdQDxu nx9X2wM3on95OV/EDuD0K+fvJ0AXObYCuqPeD4AIkCyb7FuRnwyEuCC8B+VjsCTYg/E2l5E2kB+F jRcScPQFz8gEZDgs/xMKOjpwY0wGAAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIwLTEyLTA3VDE0OjA1 OjU3KzAwOjAw1m7TfgAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMC0xMi0wN1QxNDowNTo1NyswMDow MKcza8IAAAAASUVORK5CYII= X-Now-Playing: The Soft Pink Truth's _Shall We Go On Sinning So That Grace May Increase_: "So That Grace May Increase" Date: Mon, 07 Dec 2020 15:43:43 +0100 In-Reply-To: <83im9eagm4.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 06 Dec 2020 21:17:55 +0200") Message-ID: <87r1o1ism8.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > I think it'd be good to have a run_hook_with_timeout function, yes. > Whether it should be exposed to Lisp, I'm less certain: what would be > the use case that isn't this single place? Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > I think it'd be good to have a run_hook_with_timeout function, yes. > Whether it should be exposed to Lisp, I'm less certain: what would be > the use case that isn't this single place? It is somewhat special-purpose; yes. On the other hand, implementing it in Lisp is a lot easier, and I guess I could envision people actually using it for other things, too? So I just put it in subr.el. (But I did not document it in the manual, because it does not seem to warrant that.) Pushed to the trunk now and the test case seems to work fine. > As for zeroing waiting_for_input: it's almost certainly shouldn't be > part of that, since it should always be zero when Emacs signals an > error. We do this here because this might be exiting due to a fatal > signal, in which case all bets are off, and we should better be safe > than sorry. I'm not quite sure I'm reading this paragraph right -- I'm not sure what "that" in "shouldn't be part of that" refers to here. :-) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Fri Jun 13 11:31:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28542: Temporary failure in name resolution while quitting emacs Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 07 Dec 2020 16:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28542 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed To: Lars Ingebrigtsen Cc: bshanks3@hotmail.com, 28542@debbugs.gnu.org Received: via spool by 28542-submit@debbugs.gnu.org id=B28542.160735688731286 (code B ref 28542); Mon, 07 Dec 2020 16:02:01 +0000 Received: (at 28542) by debbugs.gnu.org; 7 Dec 2020 16:01:27 +0000 Received: from localhost ([127.0.0.1]:55048 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmIx5-00088H-2f for submit@debbugs.gnu.org; Mon, 07 Dec 2020 11:01:27 -0500 Received: from eggs.gnu.org ([209.51.188.92]:33284) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmIx1-00080t-7T for 28542@debbugs.gnu.org; Mon, 07 Dec 2020 11:01:25 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:57887) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kmIwu-0000Tt-So; Mon, 07 Dec 2020 11:01:17 -0500 Received: from [176.228.60.248] (port=2486 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kmIwq-0002iy-4X; Mon, 07 Dec 2020 11:01:15 -0500 Date: Mon, 07 Dec 2020 18:01:02 +0200 Message-Id: <83pn3l8v29.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87r1o1ism8.fsf@gnus.org> (message from Lars Ingebrigtsen on Mon, 07 Dec 2020 15:43:43 +0100) References: <87lfejcdzv.fsf@gnus.org> <83o8jeke73.fsf@gnu.org> <875z5k5yks.fsf@gnus.org> <837dq0gsc7.fsf@gnu.org> <87o8jbxoml.fsf@gnus.org> <83h7p2gbs4.fsf@gnu.org> <875z5hoqx2.fsf@gnus.org> <83pn3per1t.fsf@gnu.org> <874kkzf69l.fsf@gnus.org> <83im9eagm4.fsf@gnu.org> <87r1o1ism8.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: bshanks3@hotmail.com, 28542@debbugs.gnu.org > Date: Mon, 07 Dec 2020 15:43:43 +0100 > > Eli Zaretskii writes: > > > I think it'd be good to have a run_hook_with_timeout function, yes. > > Whether it should be exposed to Lisp, I'm less certain: what would be > > the use case that isn't this single place? > > It is somewhat special-purpose; yes. On the other hand, implementing it > in Lisp is a lot easier, and I guess I could envision people actually > using it for other things, too? So I just put it in subr.el. (But I > did not document it in the manual, because it does not seem to warrant > that.) Beware: calling Lisp when we are about to crash due to a fatal signal could cause more problems than it solves. > > As for zeroing waiting_for_input: it's almost certainly shouldn't be > > part of that, since it should always be zero when Emacs signals an > > error. We do this here because this might be exiting due to a fatal > > signal, in which case all bets are off, and we should better be safe > > than sorry. > > I'm not quite sure I'm reading this paragraph right -- I'm not sure what > "that" in "shouldn't be part of that" refers to here. :-) "That" refers to the function you wanted to provide. From unknown Fri Jun 13 11:31:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28542: Temporary failure in name resolution while quitting emacs Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 07 Dec 2020 16:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28542 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed To: Eli Zaretskii Cc: bshanks3@hotmail.com, 28542@debbugs.gnu.org Received: via spool by 28542-submit@debbugs.gnu.org id=B28542.16073577909013 (code B ref 28542); Mon, 07 Dec 2020 16:17:01 +0000 Received: (at 28542) by debbugs.gnu.org; 7 Dec 2020 16:16:30 +0000 Received: from localhost ([127.0.0.1]:55112 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmJBe-0002L4-A7 for submit@debbugs.gnu.org; Mon, 07 Dec 2020 11:16:30 -0500 Received: from quimby.gnus.org ([95.216.78.240]:39026) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmJBd-0002FD-1D for 28542@debbugs.gnu.org; Mon, 07 Dec 2020 11:16:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=KsBL1v0ZcJ3zU0KKai9IxO/kaQElnG3/fKT7KrKYoLs=; b=XxZ+uk+vXW7GIqJ+kT5JOoKeN8 EEkRvpdjhcavKh6VWhm9wO0FEQeLNmvSWjM5AEMQR79mGPuMuh2FD8paX7AJ0OQyQvc+mj+vYjQxc TgIa/tsL9EQSaBtVSJwAY14P5DOzB1cvAkvAhAVp+J7fhUKBfhKxRDYc0pwZIQ8gXzq0=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kmJBS-0007V8-CZ; Mon, 07 Dec 2020 17:16:22 +0100 From: Lars Ingebrigtsen References: <87lfejcdzv.fsf@gnus.org> <83o8jeke73.fsf@gnu.org> <875z5k5yks.fsf@gnus.org> <837dq0gsc7.fsf@gnu.org> <87o8jbxoml.fsf@gnus.org> <83h7p2gbs4.fsf@gnu.org> <875z5hoqx2.fsf@gnus.org> <83pn3per1t.fsf@gnu.org> <874kkzf69l.fsf@gnus.org> <83im9eagm4.fsf@gnu.org> <87r1o1ism8.fsf@gnus.org> <83pn3l8v29.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAMFBMVEX4+Pj+/v78/Pzq 6eiBgX48Ojo/Pz9bW1qenZ3V1dUZGBclIyMgHx4PDQ7g39////97POhzAAAAAWJLR0QPGLoA2QAA AAd0SU1FB+QMBw8kEhAr8V8AAAEuSURBVDjL7ZI/S8NAFMBfOunWu8lsvWxu4gcQRFTQxaUK7o2T gxSsRDsbx26Cs1ru7CQ43Kv5AG12IdDZzc/gy59Lzia7CP4gQ96Pd7x/4LBm4F80Cc/8cM8SG9Aq 44y1oWS3e3xVCOHu97oFPgRayj7PEtwbSbzM6IvnMJRz/MheEw8KZ9IAe77G921Bon2K+s03gMM/ lT7KXlL4vFlV1epQIOK5eLXKFWwtD6QiqhqB+/AQ9YUoMnglhlKhHjWIAFGPOWsQk+QpTaiJyzAc FY3/FNd9xoURkf2U2qHBE531NMMzQDB9vMuXRRljq8EDpdXJIIPqOxsYYPVcoZSTZLFIEFFW03VW gkTGmBLHUyyhxbq3PYxxGRo7bWLrqwZdiX0by3fl1fn1o/5D4hsdleEG/6J9EAAAACV0RVh0ZGF0 ZTpjcmVhdGUAMjAyMC0xMi0wN1QxNTozNjoxOCswMDowMAsvqeoAAAAldEVYdGRhdGU6bW9kaWZ5 ADIwMjAtMTItMDdUMTU6MzY6MTgrMDA6MDB6chFWAAAAAElFTkSuQmCC X-Now-Playing: Alva Noto's _Xerrox Vol. 04_: "Xerrox Utopia" Date: Mon, 07 Dec 2020 17:16:17 +0100 In-Reply-To: <83pn3l8v29.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 07 Dec 2020 18:01:02 +0200") Message-ID: <87360hfv72.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > Beware: calling Lisp when we are about to crash due to a fatal signal > could cause more problems than it solves. Indeed, but it's a hook runner -- it will almost inevitably call other Lisp functions. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > Beware: calling Lisp when we are about to crash due to a fatal signal > could cause more problems than it solves. Indeed, but it's a hook runner -- it will almost inevitably call other Lisp functions. But by default, kill-emacs-hook is nil, so perhaps it would be a good idea to check that first, and avoid calling the function if that's the case. I'll make that change. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no