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

[Pedro Alves <pedro@palves.net>]

On 2021-06-13 11:35 a.m., Eli Zaretskii wrote:
>> 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?

AFAICT, readline processes the escape sequences we're passing it anyhow,
since it unconditionally registers/binds them.  It seems to be working for
Hannes.

Pedro Alves