bug#18649: 25.0.50; Closing TTY menus on MS-Windows

[martin rudalics <rudalics@gmx.at>]

 >> BTW: Is there a way to turn `blink-cursor-mode' off on a TTY?
 >
 > No, it blinks "in hardware" (i.e., the terminal software does it).
 > And there's no reason to disable it, because it should never do
 > anything on a TTY.  Or do you have evidence to the contrary?

No.  I just wondered why the cursor disappeared (as Dani also observed)
when doing C-g with an open menu.

 > It wasn't an old bug, it was indeed caused by the pixel-wise changes.
 > Specifically, the fact that as part of the call to change_frame_size,
 > we can now call Lisp (in frame_windows_min_size).

But this is not new, change_frame_size called resize_frame_windows,
which called Lisp before.

 > The other part of
 > the puzzle is that w32_console_read_socket calls change_frame_size
 > unconditionally on every event it reads, because Windows doesn't tell
 > us about resizes of the console window.
 >
 > So what happened was that we read the C-g key, called
 > kbd_buffer_store_event for it, which set Vquit_flag, and then we
 > called change_frame_size, which did QUIT when frame_windows_min_size
 > called Lisp.

Ah, I seem to understand.  resize_frame_windows never gets called here
because the size of the root window apparently doesn't change.  OTOH
frame_windows_min_size gets called unconditionally.  So it's merely
coincidental that this problem didn't hit us before.

BTW, I call frame_windows_min_size unconditionally in order to detect
the case where

(1) the frame size itself should be conceptually left unchanged, but

(2) something _within_ the frame changes (like adding a tool or scroll
     bar) which requires a larger frame size to keep all windows of the
     frame visible.

All this is unnecessary on TTYs.

 > I fixed that by passing a non-zero DELAY argument to
 > change_frame_size, so that it delays the actual resize to the next
 > opportunity, like the next redisplay cycle.

Works here.

 > I'm closing this bug.

Many thanks, martin