emacs is right. That is the (original) control sequence for the select key. But it is most likely right via a roundabout process.
A DEC VT102 did not have an editing keypad. That arrived with newer models. Here is a DEC VT320 keyboard with editing keypad, at right of centre above the cursor keypad.
The DEC VT220 control sequences for the editing keypad, where all this originated, are these (with the ability to encode modifiers added beginning with the DEC VT420):
- find: DECFNK 1 (i.e. CSI
1 ~ or CSI 1 ; Mods ~)
- insert: DECFNK 1 (i.e. CSI
2 ~ or CSI 2 ; Mods ~)
- remove a.k.a. delete: DECFNK 3 (i.e. CSI
3 ~ or CSI 3 ; Mods ~) or DEL
- select: DECFNK 4 (i.e. CSI
4 ~ or CSI 4 ; Mods ~)
- next screen a.k.a. PgDn: DECFNK 5 (i.e. CSI
5 ~ or CSI 5 ; Mods ~)
- prev screen a.k.a. PgUp: DECFNK 6 (i.e. CSI
6 ~ or CSI 6 ; Mods ~)
The SCO XENIX Multiscreen console worked on machines with IBM Model M keyboards, and defined:
- home: CUP (i.e. CSI
H theoretically extensible to CSI 1 ; Mods H)
- end: CPL (i.e. CSI
F theoretically extensible to CSI 1 ; Mods F)
The DEC VT52x copied some things from the SCO console, including these additional control sequences. There were two possible arrangements of the editing keypad on a DEC VT52x:
- VT layout, the same as the DEC VT220/320/420:
- find insert remove
- select prev next
- PC layout, the same as the IBM Model M:
- insert home PgUp
- delete end PgDn
The functions move to a physically different arrangement of keys, under control of a firmware setting in the terminal itself. But the mappings from functions to their control sequences are invariant.
The problem is that thanks to samizdat and old wives' tales, people mixed these up in several terminal emulators. The terminal emulator that is built into the Linux kernel, for example, has a bastard admixture of the two. It uses the "PC layout", but (despite imitating SCO Multiscreen elsewhere) sends the wrong control sequences for home and end. It sends the find and select control sequences.
This error is now baked in. And it has been propagated from there.
- mintty, for example, normally sends the SCO sequences for home and end. But it has a "VT220 mode" that causes it to behave the same way as the Linux terminal emulator, which is not the behaviour of a VT220, not least because it employs the "PC" layout which the VT220 did not have.
- rxvt uses completely wrong DECFNK codes for home and end, overlapping two of the DECFNK assignments for the cursor keypad, DECFNK 7 and DECFNK 8.
This continually causes minor hiccoughs.
The most common hiccough is not using the correct terminal type. The terminfo database has entries for putty, mintty, linux et al. that define the appropriate kend/khome/kfnd/kslt capabilities with the values emitted by those types of terminal. But if one wrongly uses vt220 instead, as mintty can optionally set as the TERM environment variable, what mintty sends as home and end get understood by applications as find and select.
That's probably what is happening in your case. A minor wrinkle is that the application doing the understanding is tmux, which is recognizing the control sequence as select, per the TERM that it has inherited being set to something like vt220, and then re-encoding it and passing it on.
Further reading
