fix(keycodes): recognize <Find>, <Select> #28431

PuTTY sets TERM=xterm, but sends ESC[1~ and ESC[4~ for Home/End keys,
which does not match what the 'xterm' terminfo has for khome/kend, so
libtermkeys instead reports them as the original DEC VT220 names.

The VT220 came with a DEC LK201 keyboard which had the following keys in
the area above arrow keys (where PCs now have Ins/Del/Home/End/etc):

  ┌────────┬────────┬────────┐
  │ Find   │ Insert │ Re-    │
  │        │ Here   │ move   │
  ├────────┼────────┼────────┤
  │ Select │ Prev   │ Next   │
  │        │ Screen │ Screen │
  └────────┴────────┴────────┘

These would send ESC[x~ sequences in the expected order:

  ┌────────┬────────┬────────┐
  │ ESC[1~ │ ESC[2~ │ ESC[3~ │
  ├────────┼────────┼────────┤
  │ ESC[4~ │ ESC[5~ │ ESC[6~ │
  └────────┴────────┴────────┘

Modern terminals continue to use the same sequences for Ins/Del as well
as PageUp/PageDn. But the VT220 keyboard apparently had no Home/End, and
PuTTY apparently chose to re-purpose the Find/Select key sequences for
Home/End (even though it claims to emulate Xterm and this doesn't match
what actual Xterm does).

So when Home/End are used in Neovim through PuTTY with TERM=xterm (the
default setting), libtermkey finds no match for the received sequences
in the terminfo database and defaults to reporting them as <Find> and
<Select> respectively.

PuTTY is not unique here -- tmux *also* sends ESC[1~ and ESC[4~ after
its internal translation -- but the difference is that 'tmux' terminfo
correctly maps them to Home/End so Neovim recognizes them as such, while
PuTTY defaults to using 'xterm' which uses a different mapping.

This initial patch only allows Neovim to recognize <Find> and <Select>
key codes as themselves, so that the user could manually map them e.g.
using ":imap <Find> <Home>".

Alternatives:

  - Using TERM=putty(-256color) would of course be the most correct
    solution, but in practice it leads to other minor issues, e.g. the
    need to have different PuTTY config profiles for older or non-Linux
    systems that lack that terminfo, or tmux's insistence on rendering
    italics as reverse.

  - Using Neovim through tmux avoids the problem (as tmux recognizes
    ESC[1~ on input), but is something that needs to be manually run
    every time.

The keycodes.h constants are slightly misnamed because K_SELECT was
already taken for a different purpose.

0 files changed, 0 insertions, 0 deletions