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

[Eli Zaretskii via Gdb-patches <gdb-patches@sourceware.org>]

> 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?