GNU bug report logs -
#18649
25.0.50; Closing TTY menus on MS-Windows
Previous Next
Reported by: Dani Moncayo <dmoncayo <at> gmail.com>
Date: Tue, 7 Oct 2014 06:52:01 UTC
Severity: normal
Found in version 25.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #28 received at 18649-done <at> debbugs.gnu.org (full text, mbox):
>> 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
This bug report was last modified 10 years and 232 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.