Pedro Alves 82a5082ed3 Make the TUI command window support the mouse ... Currently, when the focus is on the command window, we disable the keypad. This means that when the command window has the focus, keys such as up/down/home/end etc. are not processed by curses, and their escape sequences go straight to readline. A side effect of disabling keypad mode is that wgetch no longer processes mouse escape sequences, with the end result being the mouse doesn't work, and worse, the raw mouse escape sequences are printed on the terminal. This commit makes the TUI command window support the mouse as well, by always enabling the keypad, and then to avoid losing support for up/down browsing the command history, home/end/left/right moving the cursor position, etc., we forward those keys as raw escape sequences to readline. Note we don't make an effort to pass down to readline all keys returned by curses, only the common ones that readline understands by default. Given users can specify their own readline bindings (inputrc file, bind utility), this approach is good in practice, though not 100% transparent or perfect. Note that the patch makes it so that CTLC-L is always passed to readline even if the command window does not have the focus. It was simpler to implement that way, and it just seems correct to me. I don't know of a reason we shouldn't do that. The patch improves the TUI behavior in a related way. Now we can pass special keys to readline irrespective of which window has the focus. First, we try to dispatch the key to a window, via tui_displatch_ctrl_char. If the key is dispatched, then we don't pass it to readline. E.g., pressing "up" when you have the source window in focus results in scrolling the source window, and nothing else. If however, you press ctrl-del instead, that results in killing the next word in the command window, no matter which window has has focus. Before, it would only work if you had the command window in focus. Similarly, ctrl-left/ctrl-right to move between words, etc. Similarly, the previous spot where we handled mouse events was incorrect. It was never reached if the window with focus can't scroll, which is the case for the command window. Mouse scrolling affects the window under the mouse cursor, not the window in focus. We now always try to dispatch mouse events. One last bit in the patch -- now if we don't recognize the non-8-bit curses key, then we don't pass it down to readline at all. Before that would result in bogus characters in the input line. gdb/ChangeLog: yyyy-mm-dd Pedro Alves <pedro@palves.net> * tui/tui-io.c (tui_dispatch_mouse_event): New, factored out from ... (tui_dispatch_ctrl_char): ... this. Move CTRL-L handling to tui_getc_1. (cur_seq, start_sequence): New. (tui_getc_1): Pass key escape sequences for curses control keys to readline. Handle mouse and ctrl-l here. (tui_resize_all): Disable/reenable the keypad if the command window has the focus too. * tui/tui-win.c (tui_set_focus_command): Don't change keypad setting. * tui/tui.c (tui_rl_other_window): Don't change keypad setting. Change-Id: Ie0a7d849943cfb47f4a6589e1c73341563740fa9		2021-06-17 11:57:56 +01:00
..
ChangeLog-1998-2003
tui-command.c
tui-command.h
tui-data.c
tui-data.h
tui-disasm.c
tui-disasm.h
tui-file.c
tui-file.h
tui-hooks.c
tui-hooks.h
tui-interp.c
tui-io.c
tui-io.h
tui-layout.c
tui-layout.h
tui-location.c
tui-location.h
tui-out.c
tui-out.h
tui-regs.c
tui-regs.h
tui-source.c
tui-source.h
tui-stack.c
tui-stack.h
tui-win.c
tui-win.h
tui-wingeneral.c
tui-wingeneral.h
tui-winsource.c
tui-winsource.h
tui.c
tui.h