Re: [PATCH v2] Make the TUI command window support the mouse

Eli Zaretskii via Gdb-patches
2021-06-13T10:35:48Z

> From: Pedro Alves <pedro@palves.net>
> Date: Sun, 13 Jun 2021 03:46:13 +0100
> Cc: Joel Brobecker <brobecker@adacore.com>
>
> On 2021-06-12 7:08 p.m., Pedro Alves wrote:
> > On 2021-06-12 1:32 p.m., Hannes Domani wrote:
>
> >> On the other hand, if keypad was enabled, couldn't we just forward readline
> >> the escape sequences for the arrow keys instead?
> >
> > Yeah, to be honest I think that is likely a better approach and worth it of a
> > try -- my only concern is whether the escape sequences are standard enough
> > across terminals? Maybe it's all covered by ANSI and it's all we need to care
> > about? I thought of the other approach because that let's us not care about
> > specific sequences, other than the mouse sequence, which seemed pretty much
> > standard from looking around. Also, it was run to write. :-)
> >
>
> Alright, I gave that approach a go. Below's a patch implementing that. It
> works quite nicely here. I tried it on konsole, xterm and rxvt. Among those,
> rxvt uses different escape sequences for ctrl-up/ctrl-down/ctrl-left/ctrl-right,
> but it doesn't really matter -- I found that readline binds actions to
> different variants of escape sequences, so if we pick sequences readline always binds,
> it should always work. See readline.c:bind_arrow_keys_internal.
> Despite that, for the standard ncurses keys below KEY_MAX, it's easier
> to use the corresponding lowercase key_foo variable, which I believe is
> filled in from termcap so should also always work, as readline also
> binds the key sequences termcap returns.

Maybe I'm missing something, but what about MS-Windows, where the
cursor motion keys don't (AFAIK) generate escape sequences?