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.
574ea6a191