0

Currently I need to code via ssh on a remote machine. I run this from a Cygwin mintty and use tmux to keep emacs running even when I disconnect. Everything is fine, tmux reports TERM=screen, however the <end> key is not working. Emacs reports it as <select>. In the shell inside of tmux, when I do a simple cat, the key gets reported as ^[[4~. The target machine is Ubuntu 16.04.6 LTS. The end key works as expected in zsh, so I figure it must have to do with emacs.

When I run emacs in tmux locally in Cygwin, everything works fine. So I figure it's something to do with the target system. I don't want to rebind <select> since this seems awkward. Is it a bug in Emacs? The version is GNU Emacs 26.3.

I can work around this by using C-a and C-e, but would prefer a correct solution to this.

2 Answers 2

1

It's partly application, partly configuration. Depending on whether the terminal description is designed to imitate a VT220 or PC-whatever, the editing-keypad can have different names assigned to the keys. At the same time, a curses application will see only the first, so duplicates are flagged (tic warnings) and generally removed.

Emacs isn't a curses application, but it's using the terminal description provided by ncurses. So your terminal description will show one or another of end/select. You can change the terminal description...

Further reading: Why doesn't my keypad work?

(There is a longer comment about this in xterm's terminfo file).

2
  • Oh, I see. So select is on the same spot / the same keycode as end on PC keyboards. Indeed mintty emulates xterm mostly. So somewhere down the pipe of nested terminal descriptors (xterm->screen) the end becomes a select key. Well, maybe I'll just add a key binding for select. That way emacs will work both normally with end as well as select.
    – Arne
    Jan 6, 2020 at 12:37
  • yes, that should work well enough. Jan 6, 2020 at 22:56
1

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.

This is a DEC VT320 keyboard

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .