[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#18649: 25.0.50; Closing TTY menus on MS-Windows
From: |
martin rudalics |
Subject: |
bug#18649: 25.0.50; Closing TTY menus on MS-Windows |
Date: |
Wed, 08 Oct 2014 15:35:31 +0200 |
>> 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