Re: Emacs does not listen on w32

["Lennart Borgman (gmail)" <lennart.borgman@gmail.com>]

Stefan Monnier wrote:
>>>> In any case, the first
>>>> thing to do is to figure out what *really* happened in the first place.
>>>> We don't even know why Emacs didn't respond.  Maybe it has nothing to do
>>>> with the processing of WM_CLOSE.
>>> I don't think the problem was related to WM_CLOSE. What you suggested
>>> is much more likely: a memory leak. Windows tends to be *extremely*
>>> unresponsive on low-memory situations.
> 
>> I think you and Stefan are right about the memory problem but that there are
>> two different problems. In response to Eli's message I tested a simple loop,
>> something like
> 
>>   (let (x y)
>>      (while (not x)
>> 	(setq y (current-time-string))
>>         (when (string= y "something")
>> 	  (setq x t))))
> 
>> Running this Emacs does not hang the pc, but it still does not answer when
>> clicking the [X]. (I could kill it with C-g here though.)
> 
> Yes, that's perfectly normal.  The current semantics of WM_CLOSE (for
> Emacs) is more or less the same as C-x C-c (or C-x 5 0): it waits for
> the current command to finish and then runs another command that deletes
> the frame.

Yes, I know, but I think there are at least two problems here:

- I do not believe this is the right semantics for WM_CLOSE.

- If you run the above code in a timer (like I did) it is worse. There 
is no way at all to stop it. (Except from Task Manager.)

For both these problems I think a change in the semantics for WM_CLOSE 
(and related messages) are the best cure.

For Juanmas very relevant question how this should work I suggest 
something like this:

- Give Emacs say 4 seconds to finish what it is doing. (The 
documentation for IsHungAppWindow says that an application should be 
considered hung if it does not respond in 5 seconds.) If it did not 
finish then ask the user whether to interrupt or not.


BTW, related to this is WM_QUERYENDSESSION which I believe Emacs 
currently does not handle (or even look at).