* bug#18649: 25.0.50; Closing TTY menus on MS-Windows
@ 2014-10-07 6:50 Dani Moncayo
2014-10-07 15:46 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Dani Moncayo @ 2014-10-07 6:50 UTC (permalink / raw
To: 18649
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@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
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#18649: 25.0.50; Closing TTY menus on MS-Windows
2014-10-07 6:50 bug#18649: 25.0.50; Closing TTY menus on MS-Windows Dani Moncayo
@ 2014-10-07 15:46 ` Eli Zaretskii
2014-10-07 19:58 ` Eli Zaretskii
2014-10-08 9:32 ` martin rudalics
0 siblings, 2 replies; 9+ messages in thread
From: Eli Zaretskii @ 2014-10-07 15:46 UTC (permalink / raw
To: Dani Moncayo; +Cc: 18649
> Date: Tue, 7 Oct 2014 08:50:39 +0200
> From: Dani Moncayo <dmoncayo@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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#18649: 25.0.50; Closing TTY menus on MS-Windows
2014-10-07 15:46 ` Eli Zaretskii
@ 2014-10-07 19:58 ` Eli Zaretskii
2014-10-08 9:32 ` martin rudalics
1 sibling, 0 replies; 9+ messages in thread
From: Eli Zaretskii @ 2014-10-07 19:58 UTC (permalink / raw
To: martin rudalics; +Cc: 18649
> Date: Tue, 07 Oct 2014 18:46:29 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 18649@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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#18649: 25.0.50; Closing TTY menus on MS-Windows
2014-10-07 15:46 ` Eli Zaretskii
2014-10-07 19:58 ` Eli Zaretskii
@ 2014-10-08 9:32 ` martin rudalics
2014-10-08 10:29 ` Eli Zaretskii
1 sibling, 1 reply; 9+ messages in thread
From: martin rudalics @ 2014-10-08 9:32 UTC (permalink / raw
To: Eli Zaretskii, Dani Moncayo; +Cc: 18649
> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#18649: 25.0.50; Closing TTY menus on MS-Windows
2014-10-08 9:32 ` martin rudalics
@ 2014-10-08 10:29 ` Eli Zaretskii
2014-10-08 12:49 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2014-10-08 10:29 UTC (permalink / raw
To: martin rudalics; +Cc: 18649
> Date: Wed, 08 Oct 2014 11:32:31 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 18649@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?
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#18649: 25.0.50; Closing TTY menus on MS-Windows
2014-10-08 10:29 ` Eli Zaretskii
@ 2014-10-08 12:49 ` Eli Zaretskii
2014-10-08 13:13 ` Dani Moncayo
2014-10-08 13:35 ` martin rudalics
0 siblings, 2 replies; 9+ messages in thread
From: Eli Zaretskii @ 2014-10-08 12:49 UTC (permalink / raw
To: rudalics; +Cc: 18649-done
> Date: Wed, 08 Oct 2014 13:29:52 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 18649@debbugs.gnu.org
>
> > Date: Wed, 08 Oct 2014 11:32:31 +0200
> > From: martin rudalics <rudalics@gmx.at>
> > CC: 18649@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)
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#18649: 25.0.50; Closing TTY menus on MS-Windows
2014-10-08 12:49 ` Eli Zaretskii
@ 2014-10-08 13:13 ` Dani Moncayo
2014-10-08 13:35 ` martin rudalics
1 sibling, 0 replies; 9+ messages in thread
From: Dani Moncayo @ 2014-10-08 13:13 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 18649
Wow! Great job. Thank you!
--
Dani Moncayo
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#18649: 25.0.50; Closing TTY menus on MS-Windows
2014-10-08 12:49 ` Eli Zaretskii
2014-10-08 13:13 ` Dani Moncayo
@ 2014-10-08 13:35 ` martin rudalics
2014-10-08 13:57 ` Eli Zaretskii
1 sibling, 1 reply; 9+ messages in thread
From: martin rudalics @ 2014-10-08 13:35 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 18649-done
>> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#18649: 25.0.50; Closing TTY menus on MS-Windows
2014-10-08 13:35 ` martin rudalics
@ 2014-10-08 13:57 ` Eli Zaretskii
0 siblings, 0 replies; 9+ messages in thread
From: Eli Zaretskii @ 2014-10-08 13:57 UTC (permalink / raw
To: martin rudalics; +Cc: 18649
> Date: Wed, 08 Oct 2014 15:35:31 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 18649-done@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.?
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2014-10-08 13:57 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-10-07 6:50 bug#18649: 25.0.50; Closing TTY menus on MS-Windows Dani Moncayo
2014-10-07 15:46 ` Eli Zaretskii
2014-10-07 19:58 ` Eli Zaretskii
2014-10-08 9:32 ` martin rudalics
2014-10-08 10:29 ` Eli Zaretskii
2014-10-08 12:49 ` Eli Zaretskii
2014-10-08 13:13 ` Dani Moncayo
2014-10-08 13:35 ` martin rudalics
2014-10-08 13:57 ` Eli Zaretskii
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.