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#63058: 28.2; Emacs is terminated by Windows when logging off even if modified buffers are open Date: Tue, 25 Apr 2023 09:21:05 +0300 Message-ID: <83sfcowkha.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26906"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 63058@debbugs.gnu.org To: Harald Sanftmann Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Apr 25 08:21:38 2023 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 1prC3W-0006m8-R7 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 25 Apr 2023 08:21:38 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1prC33-0001gw-NI; Tue, 25 Apr 2023 02:21:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1prC2x-0001gd-1L for bug-gnu-emacs@gnu.org; Tue, 25 Apr 2023 02:21:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1prC2w-0000gK-Pm for bug-gnu-emacs@gnu.org; Tue, 25 Apr 2023 02:21:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1prC2v-0000Uv-OM for bug-gnu-emacs@gnu.org; Tue, 25 Apr 2023 02:21:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 25 Apr 2023 06:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63058 X-GNU-PR-Package: emacs Original-Received: via spool by 63058-submit@debbugs.gnu.org id=B63058.16824036491885 (code B ref 63058); Tue, 25 Apr 2023 06:21:01 +0000 Original-Received: (at 63058) by debbugs.gnu.org; 25 Apr 2023 06:20:49 +0000 Original-Received: from localhost ([127.0.0.1]:51054 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1prC2j-0000UL-AV for submit@debbugs.gnu.org; Tue, 25 Apr 2023 02:20:49 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:56576) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1prC2h-0000U7-86 for 63058@debbugs.gnu.org; Tue, 25 Apr 2023 02:20:47 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1prC2b-0000fb-3Z; Tue, 25 Apr 2023 02:20:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=htfG8/NpzoSueK4TbOLrAwwKm+XH5r7noFDKtG330WM=; b=scQs1/F/UkdT 5YvmhaZ1GmW5J2AVZEW07ZL5BkNIjR2ErywuesUit9RdfGp1yQimCOHl0WQyBkJfu42HOk5a3gDah 30djUk1FcJuBC+jozt0vnGsYuq739FPDKYaiR8LEFIzoodCE85BUJNj6jSi2QY7kqfgcNZWhDh0uJ 5F6b9V3PDi84YjlKr7W1TvOipkUeTQPQLZhuNIfJGwfhLbFNFigb5sm93PgdWsEblbscFoCsoa/bv Tp7AzfrcN0LRHYm/IPS/TZIDCut9o9+OZjqkyDNzRYDxZAj9xU9hxc4vgUwt872Q+qAbvgJKpfeLj b5gcDlPoCyzVuty61X2AjQ==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1prC2a-0002nY-Cy; Tue, 25 Apr 2023 02:20:40 -0400 In-Reply-To: (message from Harald Sanftmann on Mon, 24 Apr 2023 17:48:59 +0200) 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:260593 Archived-At: > Date: Mon, 24 Apr 2023 17:48:59 +0200 > From: Harald Sanftmann > > From time to time it happens that I have not closed Emacs before > logging out. Windows just terminates the process even if modified > buffers are open. That's the expected behavior in that case. Emacs should auto-save when the OS tells Emacs it is shutting down, so you have auto-save files to restore the session later, when the system is restarted. > I searched for a solution and learned how Windows is telling > applications to prepare for the user logging off / Windows is shutting > down: > https://www.howtogeek.com/396277/what-exactly-happens-when-you-shut-down-or-sign-out-of-windows/ > > WM_QUERYENDSESSION and WM_ENDSESSION are the sent signals, if the > application does not respond it will be terminated after 5 seconds. > > Then I found some code which could be the Emacs implementation: > > > https://github.com/emacs-mirror/emacs/blob/master/src/w32fns.c > > switch (msg) > { > case WM_ERASEBKGND: > ... > case WM_ENDSESSION: > my_post_msg (&wmsg, hwnd, msg, wParam, lParam); > /* Allow time for Emacs to attempt an orderly shutdown. If we > return, the process will be terminated immediately. FIXME: > 1000 seconds is too long to sleep if the shutdown attempt > fails (see bug#25875). But if it fails, we want to find out > about it, so let's leave 1000 for now. */ > sleep (1000); > FALLTHROUGH; > > Seems like Emacs does not respond but sleeps for 1000 s. This will > probably not cut it. This is not what happens; you saw only the first part of how Emacs on Windows handles this situation, in the input thread. What actually happens is that before the input thread starts sleeping above, it posts the WM_ENDSESSION message, via the my_post_msg call, to the main thread, where we have this: case WM_ENDSESSION: inev.kind = END_SESSION_EVENT; break; So this event gets inserted into the Emacs input event queue, and when it is processed, we do: case END_SESSION_EVENT: /* Make an event (end-session). */ return list1 (Qend_session); The above produces a Lisp event 'end-session', for which we have a default binding: initial_define_lispy_key (Vspecial_event_map, "end-session", "kill-emacs"); IOW, this event by default calls the command kill-emacs. And that command auto-saves any modified buffers that visit files, then shuts down Emacs. > Would be great to have a proper handling. What is a proper handling in this case? delay the shutdown indefinitely? that'd be even less proper, IMO. See also bug#23483 (which led to the existing implementation) and specifically these messages there: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23483#37 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23483#40 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23483#43 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23483#46 You could, if you like, bind the end-session event to a different command, perhaps that will suit your usage better. But be very careful when you do this, because invoking commands that require user interaction will not work in this case: the Emacs' input thread, which handles all kinds of inputs, is sleeping, so the user cannot interact with Emacs.