GNU bug report logs - #63058
28.2; Emacs is terminated by Windows when logging off even if modified buffers are open

Previous Next

Full log

Message #11 received at 63058 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: haraldsa <at> web.de
Cc: 63058 <at> debbugs.gnu.org
Subject: Re: bug#63058: 28.2;
 Emacs is terminated by Windows when logging off even if modified
 buffers are open
Date: Fri, 05 May 2023 08:59:13 +0300

tags 63058 notabug
close 63058
thanks

> Cc: 63058 <at> debbugs.gnu.org
> Date: Tue, 25 Apr 2023 09:21:05 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> 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.

No further comments, so I'm now closing this issue, as I see no bug
here: Emacs is behaving as intended.

Previous Next

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