[Toybox] [PATCH] scan_key: support more terminals.

[Rob Landley]

On 4/11/19 10:55 AM, enh wrote:
> On Sat, Mar 23, 2019 at 4:11 PM Rob Landley <rob at landley.net> wrote:
>>
>> On 3/23/19 2:44 PM, enh via Toybox wrote:
>>> Although we can get away with ignoring termcap/terminfo on the output
>>> side by restricting ourselves to generally-supported escape sequences,
>>
>> There's documentation on this, by the way:
>>
>> http://man7.org/linux/man-pages/man4/console_codes.4.html
> 
> well, personally i always use
> 
>   https://invisible-island.net/xterm/ctlseqs/ctlseqs.html
> 
> i'm not sure i've ever done anything more than hit ctrl-alt-del at an
> actual linux console :-)

You probably mean VGA and framebuffer consoles. (Serial consoles are also Linux
consoles.)

I've had Linux desktop systems since 1998 (It's what I left OS/2 for) and
XFree86 always, always, always sucked. (x.org has sucked noticeably less.)

>> I have a note on my todo list to look at this one especially:
>>
>>       ESC [ ? 1 h
>>               DECCKM (default off): When set, the cursor keys send an ESC O
>>               prefix, rather than ESC [.
>>
>>   $ echo -e '\e[?1h'
>>   $ sleep 10
>>   ^[OA^[OA^[OA^C
>>
>> I probably want to add '\e[?1l' to my setup code...
> 
> there's no one true place for this at the moment though, right? the
> *cleanup* has been factored out, but the setup not.

Not yet. I made an attempt to factor it out once but it's one of the things that
go buried and abandoned due to swap thrashing and the project moving out from
under it...

>> I've pondered doing something like that and waited for a user to show up. :)
> 
> so what i'm actually doing here is i had a day off and needed a hex
> editor for the thing i was dicking about with, and made some changes
> to hexedit to make it a bit more usable. one of those things was to
> make home/end and ctrl-home/ctrl-end more like other editors. i split
> off this patch to tty.c because there are so many ways of doing this i
> thought we'd deal with one bikeshed at a time. but the downside is
> that it robs the patch of some of its motivation. i am actually trying
> to use the ctrl-home/ctrl-end sequences.
...> i don't think this is as hard as you think: the modifiers are the same
> for any key, so as long as you can test with _some_ key, you know the
> modifiers are the same for the rest.
> 
> you also don't need _no_ window manager. you can use a window manager
> that doesn't touch the keys:
> https://github.com/software-jessies-org/jessies/tree/master/lwm and
> then -- if you need it -- use a separate program to run commands in
> response to interesting keystrokes:
> https://github.com/software-jessies-org/jessies/tree/master/x11-extras
> 
> (disclaimer: there are at least two forks of lwm because i haven't
> touched it in 20+ years.)

Ok, you have existing domain expertise here that I don't have, to the point I
just want to delegate this and try to undestand what you did after the fact.

I applied your patch. Go ahead and send me patches to lib/tty.c and commands
that use it until you reach a good stopping point, and I'll try to figure out
what it all means then. :)

>> And yes I asked Rich Felker, who wrote a terminal program of his own long ago
>> (http://git.musl-libc.org/cgit/uuterm/) if he had useful resources, and he
>> didn't. :(
> 
> if you want to know the legit escape sequences, see ctlseqs. yes, it's
> hideously complicated, but it accurately describes reality :-(

At least it's good there _is_ one.

> if you want to know about the underlying keystrokes coming from X11 or
> whatever, for the Java terminal we wrote
> (https://github.com/software-jessies-org/jessies/wiki/Terminator)
> there's actually a thing in the Help > Debugging Tools menu that lets
> you see the keycodes its getting (which are X11-style). you probably
> have xev(1) installed too.

I still dunno why that isn't installed by default. (I can understand not having
the icon on the desktop, but even windows has it on the _system_. For android
that would be in the "search apps" thingy...)

> (there's also vttest, but that's mainly useful if you're trying to
> emulate a terminal.)
> 
>> There's a lot of complexity in this that the current parser is unaware of, and I
>> would love to improve it it, but I'd probaby want to _start_ with not having
>> esc[ repeated at the start of most sequences that could _also_ produce escO
>> under the right circumstances. (Except above, collision between function key and
>> position report, it _is_ meaninful in some circumstances! Grrr...)
> 
> if you want to do a perfect job, i think you really have to parse the
> input. and that's hairy enough that i'm not sure you actually want to
> do that. (i don't think even vim gets it 100% right all the time,
> though it's been a while since i've had to hammer Esc to unconfuse
> it.) iirc i had a hack in some tty-based code i wrote which would (a)
> pull aside any terminal size reports but also (b) make the assumption
> that any key sequence comes in a burst, so if you see ^[ then a bunch
> of stuff and then a pause, that was a key sequence even if you didn't
> understand it (likewise another ^[ means "start again, even if you
> didn't understand what's in your buffer").

I have a black belt in terrible solutions to impossible problems, meaning I
usually start with a disgusting solution and refine it, so I have a _lot_ of
experience in cleanup.

Although really, the _hard_ part is getting test data covering all the edge
cases it has to get right.

(I'd have promoted tar already except making proper test cases is fiddly and
tedious and I'm trying to do full coverage for it, but I should probably just
promote it and move on for now. I already have a whole "test suite can of worms"
in the pre-1.0 todo list. (Read the spec. Read the code. Read the help text.
Write a test case for every single distinguishing characteristic, triggering
every error path so that if any code is removed there's a test somewhere that
would notice (unless it's just a performance issue). It's the coding equivalent
of cleaning your room.)

> given that some terminals let you choose the set of sequences to send
> _regardless_ of what sequences its seen that would control this, i
> think the "perfect" reader has to accept all the possible input
> sequences if it's never to be confused.

Accept all the input sequences, produce "cursor up key".

>>> To reduce the number of #defines, I've also switched from KEY_F1,
>>> KEY_F2, and so on to KEY_FN+1, KEY_FN+2, and so on. This isn't obviously
>>> necessary, and easily undone if we'd rather have move #defines in return
>>> for slightly more natural naming.
>>
>> I'd like to work out what the design should _be_. And it's stayed on the todo
>> list this long because that's nontrivial.
> 
> luckily i suspect in 2019 we mainly want function keys just so we can
> throw them away and get on to the next meaningful keypress! but i can
> easily put this back to one constant per key if you prefer.

Unfortunately a command line utility doesn't get to _see_ the function keys, so
yeah probably.

>>> To enable all this, I've inverted scan_key and scan_key_getsize so that
>>> scan_key_getsize is now the underlying function, and we don't waste all
>>> the top bits encoding width and height between scan_key and
>>> scan_key_getsize.
>>
>> As long as we don't _send_ the probe when we don't mean to, life is good.
>>
>>> Tested by pressing Home and End in hexedit in all of the terminals
>>> available to me.
>>
>> For regression testing, can I get a list of what those terminals _are_?
> 
> Terminator, xterm, gnome-terminal, xcfe-terminal, rxvt, and a special
> guest appearance from macOS Terminal. (i didn't test iTerm2 or PuTTY
> which are the big names missing, because i don't have a Mac or Windows
> box i can install stuff on.)
> 
> i've just realized that to some extent i probably care about the
> Windows "cmd" stuff too, given that i have users who'll be arriving
> via adb.exe run on Windows! i've yet to hear any complaints for them,
> so i'll quietly re-insert my head into the sand... (but add that to
> the list of reasons why i think the dream of "one true sequence per
> key" is futile...)

And adb on MacOS.

Seriously, getting android self-hosting so you can write android code on an
android tablet with keyboard cover and one of those new 1tb sd cards, would be
_awesome_.

Rob