Re: POC: Make the TUI command window support the mouse (Re: [PATCHv3 1/2] Initial TUI mouse support)

[Hannes Domani via Gdb-patches <gdb-patches@sourceware.org>]

 Am Samstag, 12. Juni 2021, 04:41:12 MESZ hat Pedro Alves <pedro@palves.net> Folgendes geschrieben:

> On 2021-06-11 12:02 p.m., Hannes Domani wrote:
> >  Am Donnerstag, 10. Juni 2021, 20:47:01 MESZ hat Tom Tromey <tom@tromey.com> Folgendes geschrieben:
> >
> >>>>>>> "Hannes" == Hannes Domani via Gdb-patches <gdb-patches@sourceware.org> writes:
> >>
> >> Hannes> I imagine the same is true for mouse escape sequences.
> >> Hannes> So I would just disable the mouse when the command window has focus, but
> >> Hannes> what do you think?
> >>
> >> I think this is a good fallback to have, but it would be better if we
> >> could make it really work somehow.  The problem with doing this is that
> >> if the command window has focus, then things like clicking in the source
> >> to set a breakpoint will not work.
> >
> > That would probably mean that keypad also has to be enabled when the
> > command window has focus.
> > I did a short test where I tried this, but then gdb crashed somewhere in
> > readline, and I stopped there, because I didn't want to debug readline code.
>
> We disable the keypad in the command window because we want to pass all escape
> sequences to readline, unprocessed by ncurses, so that e.g., up/down navigates
> the command history, left/right moves the cursor position, etc., just like if
> you weren't in the TUI.
>
> I first thought of fixing this by enabling the keypad, and then where we handle
> KEY_UP, etc., special case the command window, and call readline functions that do
> what you'd expect.  But the thing is that ends up being a poor readline emulation,
> and I didn't like where this was going.  Especially when I realized that for example,
> when you're in the middle for a reverse-search (c-r), KEY_UP does something different.
> Etc.
>
> I had a different idea to make this all work.  Warning, this is either a brilliant hack,
> or a really nasty hack, depending on perspective.  :-)
>
> The idea is to keep the keypad disabled in the command window.  However,
> we need to enable the keypad for ncurses to process mouse escape sequences.
> This is a conflict.  So here's the main trick behind the idea.  It breaks the conflict.
> Create a separate ncurses screen/terminal, with newterm, which reads from a pipe instead
> of from stdin.  Then, flush data from stdin into this pipe, BUT, make sure to never flush
> a non-mouse escape sequence into the pipe.  It's like the pipe is stdin, but with any
> non-mouse escape sequence filtered out.  This way, ncurses only either sees mouse
> escape sequences or normal ASCII keys.  In order to do this, we need to use
> a separate thread to flush stdin to the pipe.
>
> I gave this a try the other weekend, and ran into issues.  Today/tonight I gave it
> another go, and got it working.  It is a bit rough around the edges, but
> seems to work nicely.

If this works on Linux, then that's great, but Windows doesn't send mouse
escape sequences.

On the other hand, if keypad was enabled, couldn't we just forward readline
the escape sequences for the arrow keys instead?


Hannes