Parse xterm-keys for motion directly

[jeapostrophe]

Ideally, something better should be done (re #2554) but this is a decent
intermediate step for some useful keys.

Note: NCurses supports parsing these keys when shifted (KEY_SR,
_SLEFT, S_RIGHT, etc), but it does not do the same thing for the other
modifiers.

[jeapostrophe]

I am particularly interested in Alt+Arrows, because I am building something that matches my muscle memory from other editors.

[Screwtapello]

The "proper" way to handle these keys (according to user_caps(5)) is:

• start with the list of modifiable keys: kDC, kDN, kEND, kHOM, kLFT, kNXT, kPRV, kRIT, kUP
• and the list of modifier codes: 2 for Shift, 3 for Alt, 4 for Shift+Alt, 5 for Control, etc.
• for each possible combination:
  • concatenate the key and the modifier to produce a potential property name like kLFT4
  • call tigetstr(property_name) to obtain the byte-string that the terminal will send to signify that key and modifier (on my terminal, kLFT4 is ^[[1;4D)
  • call key_defined(byte_string) to return the dynamically-allocated key-code ncurses uses to signify that key
  • add the resulting key-code to some dynamically-allocated equivalent of the switch statement at line 584 of ncurses_ui.cc

Compared to this patch, such an algorithm would work for all modifiable keys, not just the arrow keys, Home, and End. Also, it would work for any terminal in the terminfo database, not just ones that exactly copy xterm's encoding.

On the other hand, such an algorithm would be a much more invasive change, and nobody's actually done the work to implement it, while this patch is already here and ready.

[lenormf]

Check if the functor (from above) has a valid target, instead of checking for the NULL value (in C++, you should rather use std::nullptr, but it won't matter with a functor).

[jeapostrophe]

I've switched to nullptr. I didn't embed this check into the switch, because we don't want the break on the inner one, we want it on the outer one.

[mawww]

nullptr is a built in, so no need for std:: in front. but you are correct, we use nullptr in Kakoune codebase.

[jeapostrophe]

@lenormf I've updated based on your feedback.

@Screwtapello Good to know. An efficient way to implement the dynamic switch would be a trie from key sequences to key encodings and have the reading code explore that trie and have a default case of letting the bytes through. This is essentially just a tokenization/scanner (lex) problem, so there's lots of efficient techniques to do it well if you know the mapping between strings and values you want. The problem is that doing it smart would be out-of-scope for Kakoune and you don't want to depend on other libraries. Just using std::map as a trie is likely to be much less efficient, but doable.

[jeapostrophe]

Updated again re: @lenormf

[jeapostrophe]

@mawww Anything else you'd like changed before merging?

[jeapostrophe]

I added my copyright waiver.

[mawww]

Hi, I tried to test that PR locally, and I could not get it to work proprerly, what settings do you put xterm in ? I see that putting it in 8-bit mode generates those keys, except that the CSI sequence is sent as 8-bits as well, which is not parsed correctly. I have local changes to handle all that, but I was wondering what settings you were using.

[jeapostrophe]

I don't use xterm. I am using iterm2/tmux and kitty on OS X. kitty has default settings. iterm2 has the "xterm defaults" and tmux has the xterm keys on.

[Screwtapello]

If I start a genuine xterm and run:

tput smxk; cat

...and then press Ctrl+Up, I see the output:

^[[1;5A

...which would be parsed as <c-up> by this code. smkx enables application keypad mode, which Kakoune does in ncurses_ui.cc line 507. The only configuration option I've messed with is metaSendsEscape: true, but that shouldn't be relevant to here since I'm not pressing Meta.

[mawww]

It seems here ncurses parses some keys, such as , for which I get immediatly '553' out of wgetch. I assume this is an internal value ncurses uses, and it seems disabling the 'keypad' call fixes, however I then get ^]OA for up, which seems to be "Single Shift Select G3 Character set" then the code for up (A)...

[Screwtapello]

The keypad() call determines whether ncurses interprets the key encodings defined in terminfo, or passes them through to the application. It seems like mawww's terminal emulator properly generates the special key encodings for modified cursor keys, and his terminfo database describes those encodings, so ncurses recognises them and wgetch() returns a dynamically-allocated key number, as described in my comment above.

jeapostrophe's situation is that while their terminal sends those encodings, their terminfo database doesn't describe them, so ncurses doesn't recognise them and passes them straight through to the application uninterpreted.

[mawww]

I merged this and used it as a base to refactor key parsing slightly, I am still unsure what direction we should take from here, at lease this adds more support for key combinations while preserving what we had, I am tempted to evolve that in the direction Screwtape described, but maybe we can hope for a common, forward compatible key encoding scheme that we can implement (maybe the one Leonerd suggested, or the kitty one...)