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
4 files changed
