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