3

I'm using gnome-terminal as my terminal emulator, which sets TERM=xterm-256color. The key sequences sent when pressing the function keys F1, F2, … are as printed by

$ infocmp -L1 | grep _f | sort -V
key_f1=\EOP,
key_f2=\EOQ,
key_f3=\EOR,
key_f4=\EOS,
# gap 4
key_f5=\E[15~,
# gap 5
key_f6=\E[17~,
key_f7=\E[18~,
key_f8=\E[19~,   # no gap 4 here
key_f9=\E[20~,
key_f10=\E[21~,
# gap 5
key_f11=\E[23~,
key_f12=\E[24~,
# gap 4
key_f13=\E[1;2P,
key_f14=\E[1;2Q,
key_f15=\E[1;2R, # no gap 5 here
key_f16=\E[1;2S,
# gap 4
key_f17=\E[15;2~,
# gap 5 
key_f18=\E[17;2~,
…

I wonder why there are gaps (marked with # gap …) in the key sequences. The "missing" key sequences (for instance \E[16~) are not used otherwise, as indicated by infocmp -L1 | grep -F '\E[16~').

Modern keyboards group function keys into groups of four keys each, so a gap between these groups is understandable. Some historic keyboards grouped some of their function keys into groups of five keys each, so a gap between those groups is understandable too. However, the gaps are sometimes (but not always) between groups of 4 and sometimes (but not always) between groups of 5 keys, which causes some of the function keys to build groups of just 1 or 2 keys – I haven't heard of any keyboard with such a layout.

What is the reason for these key sequences? Compatibility between keyboard layouts (with groups of 4 or 5 function keys each) seems unlikely, as gaps from the one layout would break the other layout and vice versa.

2

1 Answer 1

1

gnome-terminal copies the most commonly-used keyboard configuration of xterm.

In turn, xterm uses key assignments to match DEC VT220, e.g., its LK201 keyboard. Those account for most of the gaps. The different encoding used in F1-F4 and F13-F16 are not from the VT220. F1-F5 on a VT220 are local function keys by default (normally do not send anything to the host).

Rather, the F1-F4 codes are the top row of the VT100 numeric keypad which did not fit into the X keyboard configuration because NumLock was reserved. F13-F16 adapt that workaround to xterm's modified function keys (e.g., where the shift modifier causes xterm to send the ;2 part of the key sequence).

Some of the VT220 keys have other names (e.g., F16 is the Help key), but xterm has no use for those names (because they are application-specific). If it did use those names in the terminal description, there would be more gaps in the listing. But the VT220-specific gaps relate to the groups of function-keys on the DEC hardware terminal.

$ infocmp -L1 | grep _f | sort -V
key_f1=\EOP,
key_f2=\EOQ,
key_f3=\EOR,
key_f4=\EOS,
# gap 4
key_f5=\E[15~,
# gap 5
key_f6=\E[17~,
key_f7=\E[18~,
key_f8=\E[19~,   # no gap 4 here
key_f9=\E[20~,
key_f10=\E[21~,
# gap 5
key_f11=\E[23~,
key_f12=\E[24~,
# gap 4
key_f13=\E[1;2P,
key_f14=\E[1;2Q,
key_f15=\E[1;2R, # no gap 5 here
key_f16=\E[1;2S,
# gap 4
key_f17=\E[15;2~,
# gap 5 
key_f18=\E[17;2~,
…

The xterm-r6 terminal description does not have these changes for F1-F4 (and F13-F16), but shows the expected gaps:

> infocmp -L1 xterm-r6 | grep key_f | sort -V
        key_f1=\E[11~,
        key_f2=\E[12~,
        key_f3=\E[13~,
        key_f4=\E[14~,
        key_f5=\E[15~,
...
        key_f6=\E[17~,
        key_f7=\E[18~,
        key_f8=\E[19~,
        key_f9=\E[20~,
        key_f10=\E[21~,
        key_f11=\E[23~,
        key_f12=\E[24~,
        key_f13=\E[25~,
        key_f14=\E[26~,
...
        key_f15=\E[28~,
        key_f16=\E[29~,
...
        key_f17=\E[31~,
        key_f18=\E[32~,
        key_f19=\E[33~,
        key_f20=\E[34~,
        key_find=\E[1~,

(gnome-terminal isn't actually a VT220 emulator because it lacks almost all of the character-set features, but rather an xterm-imitator).

You must log in to answer this question.

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