Always set standard(really?) CSI keybindings

[tompng]

This is work in progress / in survey.

In ansi.rb, cuu', 'cud', 'cuf', 'cub' are registered to keybinding with replacing hack. cud=\E[%p1%dB is replaced to cud=\E[B.
I think this is doing wrong. Other escape sequence for keyboard input have prefix k. Maybe these non-k-prefix sequences are only for printing, not for keyboard input.
However, there is no "\E[B" in output of infocmp command. This is weird. Maybe it is not written in terminfo because "\E[B" is standard, no need to write because every terminal emulator have it. (really?)

I found the following sentence in wikipedia https://en.wikipedia.org/wiki/ANSI_escape_code#CSIsection.

A subset of arrangements was declared "private" so that terminal manufacturers could insert their own sequences without conflicting with the standard.

If only "private" is written in terminfo, Reline should always set "standard" CSI keybindings.

TODO

• Does standard CSI really exist?
• Where can we find standard CSI list for keyboard inputs? (not for writing to STDOUT)

[sshock]

@tompng Thanks for adding this PR. I like it a lot if we are set on not wanting to enter application mode.

I'll see if I can help find some answers to your questions.

[sshock]

In ansi.rb, cuu', 'cud', 'cuf', 'cub' are registered to keybinding with replacing hack. cud=\E[%p1%dB is replaced to cud=\E[B.
I think this is doing wrong. Other escape sequence for keyboard input have prefix k. Maybe these non-k-prefix sequences are only for printing, not for keyboard input.

Agreed. Based on my research these are for output not input, and have to do with moving the cursor. Also, some manual testing confirm it, e.g., telling it to move the cursor down 3:

sshock@sshock:~/git/reline_sshock$ echo -e "Hello\E[3Byou"
Hello


     you

However, there is no "\E[B" in output of infocmp command. This is weird. Maybe it is not written in terminfo because "\E[B" is standard, no need to write because every terminal emulator have it. (really?)

I thought this was weird as well when I first encountered it. But I think the answer is not that "\E[B" is standard, but rather that terminfo can only return one escape sequence for a given capability, or in other words, tigetstr only has one return value, so for example, tigetstr("kcud1") for the down-arrow key can't return both "\E[B" and "\EOB".

For better or worse, based on what I have read and seen so far, when the escape sequence for a given capability is different in normal mode vs application mode, terminfo always returns the application mode escape sequence. I suppose this is because it was primarily designed to be used by applications.

I found the following sentence in wikipedia https://en.wikipedia.org/wiki/ANSI_escape_code#CSIsection.

A subset of arrangements was declared "private" so that terminal manufacturers could insert their own sequences without conflicting with the standard.
If only "private" is written in terminfo, Reline should always set "standard" CSI keybindings.

I don't think it's that these "standard" ones are left out of terminfo. In fact, several of them are present in my terminfo for xterm:

cuf1=\E[C
cuu1=\E[A
ed=\E[J
el=\E[K

Keep in mind that, as I believe you alluded to below, most or all of the sequences listed here on wikipedia are for output (e.g., move cursor), not for input (keys). So we shouldn't be referencing this list when setting up key bindings, although what you've entered in the code are indeed the correct sequences for the arrow keys and Home and End keys, at least for xterm (and probably many other terminals).

Does standard CSI really exist?

I believe so, but perhaps only for the output sequences, not input sequences.

For example, in the ECMA-48 standard we can find this:

8.3.19 CUD - CURSOR DOWN
Notation: (Pn)
Representation: CSI Pn 04/02
Parameter default value: Pn = 1
CUD causes the active presentation position to be moved downwards in the presentation component by n
line positions if the character path is horizontal, or by n character positions if the character path is
vertical, where n equals the value of Pn

The only thing I don't understand is why it shows the representation as "CSI Pn 04/02" instead of "CSI Pn B", but I think it's referencing the ascii value 0x42, perhaps by indicating row 4 column 2 in an ASCII table.

Where can we find standard CSI list for keyboard inputs? (not for writing to STDOUT)

I found the CSI escapes for cursor keys and Home and End keys for xterm here:

• https://www.xfree86.org/current/ctlseqs.html#PC-Style%20Function%20Keys

I found the CSI escapes for cursor keys for vt220 here:

• https://vt100.net/docs/vt220-rm/chapter3.html#T3-2

I don't think these escape sequences are standard across all terminals, but probably are for VT-based terminals.

[sshock]

I do see the cursor keys at least in Table 3-6 of the vt100 manual:

• https://vt100.net/docs/vt100-ug/chapter3.html#T3-6
• https://geoffg.net/Downloads/Terminal/VT100_User_Guide.pdf (pg 120)

So I think the cursor keys are pretty standard across all ANSI-based terminals.

However, the Home and End keys are not as standard. For example, with the "linux" console terminal they are "\E[1~" and "\E[4~" (I believe in both normal and application mode), and in rxvt-based terminals they are "\E[7~" and "\E[8~".

Note that these are all covered by the comprehensive list.

So to ensure good support for Home and End, I think we need to either go ahead and always apply the comprehensive list (#433), or we need to enter application mode (#521). Luckily, since other terminals like rxvt and linux console appear to have only one escape sequence for Home and End, they should be handled fine already with our CAPNAME_KEY_BINDINGS, so proceeding with this PR, which fixes Home and End on xterm, should get us to a pretty good place.

[tompng]

After more investigation, I've opened an improved version of similar approach #569 that considers modifier keys.