GNU bug report logs - #18649
25.0.50; Closing TTY menus on MS-Windows

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 18649-done <at> debbugs.gnu.org
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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.