Whether arrow keys reach a program on Plan 9 — and in what form — depends entirely on the terminal. This came out of getting xsofy running on 9front (via let-go's Plan 9 input work, nooga/let-go#461). Movement already works everywhere through hjkl + numpad; this issue is specifically about the arrow keys, which behave differently in each environment.
Arrow keys by terminal
| Terminal |
Arrow keys |
Renders ANSI? |
| alacritty9 (agent9) |
arrive as ANSI ESC[A/[B/[C/[D — xsofy's existing bindings already handle them |
yes |
rio native window (rc, vtwin) |
rio intercepts them for scrollback (Kup/Kdown are its view/scroll keys); they never reach the program, even in raw mode. Letters (hjkl) do reach |
no |
| bare console (no rio) |
reach the program as Plan 9 key runes (see below), delivered by the kernel keyboard driver |
no |
The upshot: alacritty9 is where you actually play (it renders xsofy's ANSI and its arrows already work). rio windows can't render the game's output at all, and additionally swallow the arrow keys. The bare console delivers arrow runes to the program but also can't render ANSI.
Correction to the original framing
An earlier version of this issue said rio "sends" these runes. That's wrong: in a rio window rio eats the arrow keys for scrollback, so a program never sees them. The runes only reach a program on the bare console, and it's the kernel keyboard driver delivering them — not rio.
The bare-console runes
From /sys/include/keyboard.h:
| Arrow |
Name |
Codepoint |
| Up |
Kup |
U+F00E |
| Down |
Kdown (= Kview) |
U+F800 |
| Left |
Kleft |
U+F011 |
| Right |
Kright |
U+F012 |
Proposed change (low priority)
Binding these four runes in base-key-bindings movement :keys in xsofy/input.lg makes the arrow keys move the player on the bare console. Additive — ANSI terminals and vi-keys are untouched. A branch is ready.
But its value is narrow: the bare console is the only place it helps, and the bare console can't render xsofy's ANSI anyway, so it's a poor play environment. In alacritty9 — the real target — arrows already work via ESC[A, and hjkl/numpad work everywhere. So this is a completeness nicety for the bare console, not a blocker for Plan 9 playability.
Keeping the issue as documentation of the arrow-input landscape; happy to land the runes if we want the bare console fully covered.
Whether arrow keys reach a program on Plan 9 — and in what form — depends entirely on the terminal. This came out of getting xsofy running on 9front (via let-go's Plan 9 input work, nooga/let-go#461). Movement already works everywhere through hjkl + numpad; this issue is specifically about the arrow keys, which behave differently in each environment.
Arrow keys by terminal
ESC[A/[B/[C/[D— xsofy's existing bindings already handle themrc,vtwin)Kup/Kdownare its view/scroll keys); they never reach the program, even in raw mode. Letters (hjkl) do reachThe upshot: alacritty9 is where you actually play (it renders xsofy's ANSI and its arrows already work). rio windows can't render the game's output at all, and additionally swallow the arrow keys. The bare console delivers arrow runes to the program but also can't render ANSI.
Correction to the original framing
An earlier version of this issue said rio "sends" these runes. That's wrong: in a rio window rio eats the arrow keys for scrollback, so a program never sees them. The runes only reach a program on the bare console, and it's the kernel keyboard driver delivering them — not rio.
The bare-console runes
From
/sys/include/keyboard.h:KupKdown(=Kview)KleftKrightProposed change (low priority)
Binding these four runes in
base-key-bindingsmovement:keysinxsofy/input.lgmakes the arrow keys move the player on the bare console. Additive — ANSI terminals and vi-keys are untouched. A branch is ready.But its value is narrow: the bare console is the only place it helps, and the bare console can't render xsofy's ANSI anyway, so it's a poor play environment. In alacritty9 — the real target — arrows already work via
ESC[A, and hjkl/numpad work everywhere. So this is a completeness nicety for the bare console, not a blocker for Plan 9 playability.Keeping the issue as documentation of the arrow-input landscape; happy to land the runes if we want the bare console fully covered.