bug#63058: 28.2; Emacs is terminated by Windows when logging off even if modified buffers are open

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 24 Apr 2023 17:48:59 +0200
> From: Harald Sanftmann <haraldsa@web.de>
> 
>  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.