orbiton

What it is

orbiton (binary: o) is “configuration-free, to help users stay focused.” It opens, you edit, there’s almost no chrome and no config file (one exception: an O_THEME env var). Its defining trait is a deliberate VT100 limitation: it is “limited by VT100, is small and self-contained,” targeting basic terminals and embedded devices — the README explicitly names Raspberry Pi as a use case and lists st, urxvt, xterm, zutty, etc. as supported terminals. It restricts itself to the 16-color palette so it renders correctly on minimal hardware.

Notable features, mostly bound to single Ctrl keys:

• Portal cut/paste across files — Ctrl+r twice opens/closes a “portal”; while a portal is open, Ctrl+v copies lines across files (or within one). A persistent cross-buffer clipboard tunnel.
• Rainbow parentheses, markdown table editor overlay (Ctrl+t on a table), jump-to-line with numeric/percentage/fraction/letter targets (Ctrl+l), an experimental spellchecker, a Ctrl+g status-bar toggle (word count / distraction-free), and status messages (build result, debug state) rather than a persistent status UI.
• LSP tab-completion and a tiny gdb/dlv debug frontend for many languages.
• A built-in mini-game easter egg: the Konami code (or a feedgame symlink) launches “a silly little game about feeding creatures with pellets before they are eaten,” reachable from the Ctrl+o menu.
• Read-only files render all text in red as an at-a-glance state signal.

Deckline relevance

orbiton is the batch entry that thinks like KN-86 hardware: it assumes a constrained terminal and a small, self-contained binary on modest silicon, and it designs within those limits rather than fighting them.

• VT100 / minimal-terminal constraint = KN-86’s constraint, by choice. Most editors assume a capable modern terminal; orbiton assumes the opposite and explicitly targets Raspberry-Pi-class hardware. That’s KN-86’s exact target (Pi Zero 2 W, per Canonical Hardware Specification) and exact posture — design for the floor, not the ceiling. orbiton is the cleanest external precedent for “small self-contained binary, limited rendering, runs on a Pi” as a design goal rather than a compromise.
• Single-binary, config-free. orbiton ships one ~1.5 MB binary and refuses a config file to keep the user focused. KN-86’s nOSh runtime is similarly a small self-contained binary, and the device is deliberately not a configurable IDE — orbiton’s “no config, stay focused” thesis aligns with KN-86 being an appliance, not a workstation. (Cross-read maki.md on the battery/footprint side of the same minimalism.)
• Portal cut/paste as a cross-surface clipboard primitive. orbiton’s “portal” — a persistent tunnel that lets you copy from one buffer and paste into another some steps later — is a genuinely novel interaction worth lifting. KN-86’s cartridge-swap workflow is exactly the situation a portal solves: copy a seed / handle / fragment in one surface, swap surfaces (or carts), paste it where it’s needed. A persistent “portal” clipboard that survives surface and cartridge switches maps cleanly onto Universal Deck State (the cross-cartridge state layer) and the seed-capture flow on the CIPHER-LINE (per Canonical Hardware Specification, TERM does seed capture when seed display is active). orbiton names and demonstrates the primitive.
• State-by-rendering signals. Read-only-file = all-text-red, build-status as a transient status message rather than persistent chrome. KN-86 wants the same economy of signals — a surface’s mode/state communicated by a single legible treatment, not a busy status panel.

Single-color adaptation

orbiton uses its 16-color budget for several state signals that all need a monochrome re-encoding — making it a good worked exercise in the single-color reframing KN-86 lives by:

• Read-only = all red → monochrome KN-86 re-encodes as a status-row label ([RO]) plus optionally a dim/stippled rendering of the whole buffer, or a distinct border treatment. State communicated by label + treatment, not hue.
• Rainbow parentheses → the most color-dependent feature, and the canonical single-color challenge. KN-86’s re-encodings: match-on-cursor inversion (highlight only the paren pair the cursor is on, by inversion), or depth-by-glyph (alternate bracket glyphs by nesting depth using CP437/Unicode variants), or a depth digit in the gutter. orbiton is the reference for why you want bracket-depth cues in a Lisp editor; KN-86 must deliver them without color — directly relevant to the REPL and nEmacs, which edit parenthesis-heavy Lisp (software/runtime/repl.md, ADR-0008).
• Themes (O_THEME, base16) → KN-86’s single amber theme is fixed by hardware, but orbiton’s theme mechanism (named themes, env-var selection) is the same pattern as the planned aesthetic-mode roster (cross-link os-models.md, 4trk.md) — KN-86 varies treatment (scanlines, warmth, glyph weight) within one color rather than swapping palettes.

LISP / extension angle

orbiton has no plugin language, but two of its features are direct inputs to KN-86’s Lisp surfaces and its easter-egg gameplay:

• Rainbow parens + bracket matching is a Lisp-editor concern first and foremost. orbiton implements it because it edits paren-heavy code; KN-86’s whole authoring paradigm is Lisp (Fe VM, ADR-0001), so the REPL and nEmacs need depth/match cues even more — and must render them monochrome (see adaptation above). orbiton is the citation for “a Lisp editing surface needs paren-depth feedback”; the single-color constraint just changes the encoding, not the requirement.
• Built-in mini-game easter egg → KN-86’s Legacy Terminal mode. orbiton hides a small feeding game behind the Konami code. KN-86 already has the matching mechanic: the Legacy Terminal mode, a hidden mode-swap reached by the SYS+INFO×4 easter egg (ADR-0021), with bundled retro titles. orbiton is external precedent that a serious tool shipping a hidden game is charming, not unprofessional — useful support for the ADR-0021 direction, and a reference for the trigger-gesture-as-easter-egg pattern (Konami code ↔ SYS+INFO×4). The feedgame symlink alternative is a nice touch: a second, “official” entry point alongside the secret one.

Notes

• Batch 8. Lead reference for hardware-constraint-first design, the portal clipboard primitive, and the easter-egg-game pattern.
• Cross-link ADR-0021-legacy-terminal-mode.md — orbiton’s hidden mini-game is the strongest external precedent for the SYS+INFO×4 Legacy Terminal easter egg; cite it in support.
• The portal clipboard is the most liftable single feature in the batch — a cross-surface/cross-cartridge persistent clipboard that rides on Universal Deck State. Worth a dedicated parking-lot note.
• Cross-link maki.md (small footprint / focus) and nino.md (Pi-class minimal C editor) — orbiton is the Go member of the constrained-hardware-editor cluster.
• Cross-link os-models.md / 4trk.md for the theme-mechanism → aesthetic-mode read-across.

Image

TODO (human): Pull a screenshot from the orbiton README — ideally one showing rainbow parens / a theme, and if available a frame of the feeding mini-game. Drop at inspiration/screenshots/orbiton.png.