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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 18649 in the body.
You can then email your comments to 18649 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: bug-gnu-emacs <bug-gnu-emacs <at> gnu.org>
Subject: 25.0.50; Closing TTY menus on MS-Windows
Date: Tue, 7 Oct 2014 08:50:39 +0200

Recipe:
  emacs -Q -nw
  F10 C-g

C-g should close/exit the TTY menu, but it doesn't.

If I start to type something, the TTY menu dissapears, but the cursor is
not visible anymore.


In GNU Emacs 25.0.50.1 (i686-pc-mingw32)
 of 2014-10-06 on LEG570
Repository revision: 118063
monnier <at> iro.umontreal.ca-20141006174756-y7ha091r491l1ijw
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --enable-checking=yes,glyphs 'CFLAGS=-O0 -g3'
 CPPFLAGS=-DGLYPH_DEBUG=1'

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB

Important settings:
  value of $LANG: ESN
  locale-coding-system: cp1252

-- 
Dani Moncayo

Message #8 received at 18649 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 18649 <at> debbugs.gnu.org
Subject: Re: bug#18649: 25.0.50; Closing TTY menus on MS-Windows
Date: Tue, 07 Oct 2014 18:46:29 +0300

> Date: Tue, 7 Oct 2014 08:50:39 +0200
> From: Dani Moncayo <dmoncayo <at> gmail.com>
> 
> Recipe:
>   emacs -Q -nw
>   F10 C-g
> 
> C-g should close/exit the TTY menu, but it doesn't.
> 
> If I start to type something, the TTY menu dissapears, but the cursor is
> not visible anymore.

There's nothing wrong with TTY menus: ESC ESC ESC still pops the menu
down, as does clicking the mouse somewhere outside the menu.

The problem is with C-g: it somehow shortcuts too much, and bypasses
the code that was supposed to be seen by the menu displaying
functions.  For example, try "C-h k C-g": all you will see is "Quit"
in the echo area, but no help.  IOW, we throw to top level too early
or too radically.

I don't see this on GNU/Linux, probably again because the low-level
details of keyboard input are different.

The problem started somewhere between trunk revisions 117575 and
117589.  I have trunk binaries from these two revisions, and the
former still works correctly.  Unfortunately, this range of revisions
includes the jumbo changeset related to pixel-wise resizing, which at
the very least makes it easy to drown in the flood and miss the
important parts.

If someone has time to bisect more accurately, or debug this, or even
give an idea where to look, you are welcome.

Message #11 received at 18649 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 18649 <at> debbugs.gnu.org, dmoncayo <at> gmail.com
Subject: Re: bug#18649: 25.0.50; Closing TTY menus on MS-Windows
Date: Tue, 07 Oct 2014 22:58:57 +0300

> Date: Tue, 07 Oct 2014 18:46:29 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 18649 <at> debbugs.gnu.org
> 
> The problem started somewhere between trunk revisions 117575 and
> 117589.  I have trunk binaries from these two revisions, and the
> former still works correctly.  Unfortunately, this range of revisions
> includes the jumbo changeset related to pixel-wise resizing, which at
> the very least makes it easy to drown in the flood and miss the
> important parts.

Update: the problem is definitely caused by r117587; reverting it
fixes the problem.  I reviewed the diffs, more than once, and I cannot
see what could be the reason.  Martin, your help will be appreciated.

Message #14 received at 18649 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>, Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 18649 <at> debbugs.gnu.org
Subject: Re: bug#18649: 25.0.50; Closing TTY menus on MS-Windows
Date: Wed, 08 Oct 2014 11:32:31 +0200

> There's nothing wrong with TTY menus: ESC ESC ESC still pops the menu
> down, as does clicking the mouse somewhere outside the menu.

As does F10.

> The problem is with C-g: it somehow shortcuts too much, and bypasses
> the code that was supposed to be seen by the menu displaying
> functions.  For example, try "C-h k C-g": all you will see is "Quit"
> in the echo area, but no help.

Confirmed.

> IOW, we throw to top level too early
> or too radically.

Do you see any way to debug this?

> I don't see this on GNU/Linux, probably again because the low-level
> details of keyboard input are different.

Confirmed with all builds I have there.

> The problem started somewhere between trunk revisions 117575 and
> 117589.  I have trunk binaries from these two revisions, and the
> former still works correctly.  Unfortunately, this range of revisions
> includes the jumbo changeset related to pixel-wise resizing, which at
> the very least makes it easy to drown in the flood and miss the
> important parts.
>
> If someone has time to bisect more accurately, or debug this, or even
> give an idea where to look, you are welcome.

> Update: the problem is definitely caused by r117587; reverting it
> fixes the problem.  I reviewed the diffs, more than once, and I cannot
> see what could be the reason.  Martin, your help will be appreciated.

I'm just as lost as you are.  I tried to partially revert changes that
could have affected this on w32 but with no luck.

BTW: Is there a way to turn `blink-cursor-mode' off on a TTY?

martin

Message #17 received at 18649 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 18649 <at> debbugs.gnu.org, dmoncayo <at> gmail.com
Subject: Re: bug#18649: 25.0.50; Closing TTY menus on MS-Windows
Date: Wed, 08 Oct 2014 13:29:52 +0300

> Date: Wed, 08 Oct 2014 11:32:31 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 18649 <at> debbugs.gnu.org
> 
>  > IOW, we throw to top level too early
>  > or too radically.
> 
> Do you see any way to debug this?

If no other idea presents itself, the hard way: by stepping through
the code in keyboard.c that processes keyboard input.

>  > Update: the problem is definitely caused by r117587; reverting it
>  > fixes the problem.  I reviewed the diffs, more than once, and I cannot
>  > see what could be the reason.  Martin, your help will be appreciated.
> 
> I'm just as lost as you are.  I tried to partially revert changes that
> could have affected this on w32 but with no luck.

Sigh.  I guess that commit just exposed some other bug, then.

Thanks for trying.

> 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?

Message #22 received at 18649-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: rudalics <at> gmx.at
Cc: 18649-done <at> debbugs.gnu.org
Subject: Re: bug#18649: 25.0.50; Closing TTY menus on MS-Windows
Date: Wed, 08 Oct 2014 15:49:37 +0300

> Date: Wed, 08 Oct 2014 13:29:52 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 18649 <at> debbugs.gnu.org
> 
> > Date: Wed, 08 Oct 2014 11:32:31 +0200
> > From: martin rudalics <rudalics <at> gmx.at>
> > CC: 18649 <at> debbugs.gnu.org
> > 
> >  > IOW, we throw to top level too early
> >  > or too radically.
> > 
> > Do you see any way to debug this?
> 
> If no other idea presents itself, the hard way: by stepping through
> the code in keyboard.c that processes keyboard input.

There _is_ a better way: set a breakpoint in process_quit_flag (which
is called as part of QUIT), and see who called it.  Using this method,
I was able to catch the villain in no time, see below.

> >  > Update: the problem is definitely caused by r117587; reverting it
> >  > fixes the problem.  I reviewed the diffs, more than once, and I cannot
> >  > see what could be the reason.  Martin, your help will be appreciated.
> > 
> > I'm just as lost as you are.  I tried to partially revert changes that
> > could have affected this on w32 but with no luck.
> 
> Sigh.  I guess that commit just exposed some other bug, then.

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).  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.

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.

I'm closing this bug.

For the record, here's the backtrace I obtained from the breakpoint
set in process_quit_flag:

  #0  process_quit_flag () at eval.c:1440
  #1  0x0118e71f in Ffuncall (nargs=4, args=0x82e780) at eval.c:2659
  #2  0x0118e5bd in call3 (fn=22541890, arg1=22499637, arg2=22425250,
      arg3=22425250) at eval.c:2592
  #3  0x01010acd in frame_windows_min_size (frame=22499637,
      horizontal=22425250, pixelwise=22425250) at frame.c:333
  #4  0x01010cce in adjust_frame_size (f=0x1575130 <dumped_data+85776>,
      new_width=80, new_height=56, inhibit=5, pretend=false) at frame.c:409
  #5  0x0100e9a2 in change_frame_size_1 (f=0x1575130 <dumped_data+85776>,
      new_width=80, new_height=56, pretend=false, delay=false, safe=false,
      pixelwise=false) at dispnew.c:5531
  #6  0x0100ea00 in change_frame_size (f=0x1575130 <dumped_data+85776>,
      new_width=80, new_height=56, pretend=false, delay=false, safe=false,
      pixelwise=false) at dispnew.c:5562
  #7  0x0123c934 in maybe_generate_resize_event () at w32inevt.c:605
  #8  0x0123cc99 in w32_console_read_socket (
      terminal=0x18fd358 <dumped_data+3789112>, hold_quit=0x82e9ac)
      at w32inevt.c:795
  #9  0x0110a875 in gobble_input () at keyboard.c:6911
  #10 0x01104e33 in kbd_buffer_get_event (kbp=0x82eac4,
      used_mouse_menu=0x82ed93, end_time=0x0) at keyboard.c:3957
  #11 0x011011f4 in read_event_from_main_queue (end_time=0x0,
      local_getcjmp=0x82ebec, used_mouse_menu=0x82ed93) at keyboard.c:2254
  #12 0x01101430 in read_decoded_event_from_main_queue (end_time=0x0,
      local_getcjmp=0x82ebec, prev_event=22425218, used_mouse_menu=0x82ed93)
      at keyboard.c:2319
  #13 0x01102886 in read_char (commandflag=0, map=24485206,
      prev_event=22425218, used_mouse_menu=0x82ed93, end_time=0x0)
      at keyboard.c:2916
  #14 0x0110f4cb in read_key_sequence (keybuf=0x82eeb4, bufsize=30,
      prompt=19897305, dont_downcase_last=false, can_return_switch_frame=false,
      fix_current_buffer=false, prevent_redisplay=false) at keyboard.c:9171
  #15 0x01110bf6 in read_key_sequence_vs (prompt=19897305,
      continue_echo=22425218, dont_downcase_last=22425218,
      can_return_switch_frame=22425218, cmd_loop=22425218, allow_string=true)
      at keyboard.c:9865
  #16 0x01110cad in Fread_key_sequence (prompt=19897305,
      continue_echo=22425218, dont_downcase_last=22425218,
      can_return_switch_frame=22425218, cmd_loop=22425218) at keyboard.c:9938
  #17 0x0118eaf4 in Ffuncall (nargs=2, args=0x82f014) at eval.c:2739
  #18 0x011d05f9 in exec_byte_code (bytestr=19897113, vector=19897141,
      maxdepth=16, args_template=22425218, nargs=0, args=0x0) at bytecode.c:920
  #19 0x011cfa56 in Fbyte_code (bytestr=19897113, vector=19897141, maxdepth=16)
      at bytecode.c:486
  #20 0x0118d70c in eval_sub (form=19897102) at eval.c:2184
  #21 0x0118cf0e in Feval (form=19897102, lexical=22425218) at eval.c:1993
  #22 0x01186634 in Fcall_interactively (function=24528330,
      record_flag=22425218, keys=22450893) at callint.c:379
  #23 0x0118ea75 in Ffuncall (nargs=4, args=0x82f56c) at eval.c:2730
  #24 0x011d05f9 in exec_byte_code (bytestr=19853809, vector=19853829,
      maxdepth=52, args_template=4100, nargs=1, args=0x82f8a0) at bytecode.c:920
  #25 0x0118f24d in funcall_lambda (fun=19853789, nargs=1, arg_vector=0x82f89c)
      at eval.c:2890
  #26 0x0118ec5a in Ffuncall (nargs=2, args=0x82f898) at eval.c:2772
  #27 0x0118e55d in call1 (fn=22471274, arg1=24528330) at eval.c:2576
  #28 0x010ffab9 in command_loop_1 () at keyboard.c:1569
  #29 0x0118b976 in internal_condition_case (bfun=0x10ff458 <command_loop_1>,
      handlers=22478818, hfun=0x10fecbd <cmd_error>) at eval.c:1344
  #30 0x010ff110 in command_loop_2 (ignore=22425218) at keyboard.c:1197
  #31 0x0118af11 in internal_catch (tag=22476146,
      func=0x10ff0ec <command_loop_2>, arg=22425218) at eval.c:1105
  #32 0x010ff0c6 in command_loop () at keyboard.c:1176
  #33 0x010fe85a in recursive_edit_1 () at keyboard.c:786
  #34 0x010fea16 in Frecursive_edit () at keyboard.c:857
  #35 0x010fcafd in main (argc=3, argv=0xa42808) at emacs.c:1643

  Lisp Backtrace:
  "read-key-sequence" (0x82f018)
  "byte-code" (0x82f298)
  "call-interactively" (0x82f570)
  "command-execute" (0x82f89c)

Message #25 received at 18649 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 18649 <at> debbugs.gnu.org
Subject: Re: bug#18649: 25.0.50; Closing TTY menus on MS-Windows
Date: Wed, 8 Oct 2014 15:13:12 +0200

Wow!  Great job.  Thank you!

-- 
Dani Moncayo

Message #28 received at 18649-done <at> debbugs.gnu.org (full text, mbox):

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

Message #31 received at 18649 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 18649 <at> debbugs.gnu.org
Subject: Re: bug#18649: 25.0.50; Closing TTY menus on MS-Windows
Date: Wed, 08 Oct 2014 16:57:26 +0300

> Date: Wed, 08 Oct 2014 15:35:31 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 18649-done <at> debbugs.gnu.org
> 
>  >> 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.

Because the TTY menu code hides the cursor, and since C-g bypassed
that code, the part of it that restores the cursor after popping down
the menu didn't execute.  It has nothing to do with blink-cursor-mode.

> 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.

Yes.  In general, calling change_frame_size from the input handler was
simply wrong.

> 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.

Maybe, but who knows what happens with all the latest hot stuff, like
tmux etc.?

Previous Next

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