nino

What it is

nino is the author’s personal editor, “Inspired by kilo and snaptoken’s Build Your Own Text Editor tutorial” — i.e. it descends directly from antirez’s kilo, the ~1000-line C editor that’s the canonical “smallest real text editor” reference. nino takes that core and adds the features kilo deliberately omits, while staying pure C with no dependencies:

• Multiple editor tabs, split screen (Ctrl+\, focus L/R with Ctrl+Alt+←/→), and an integrated file explorer (Ctrl+e focus, Ctrl+b toggle).
• Basic UTF-8 support, automatic indentation and bracket completion, multiple undo/redo, search with smart case sensitivity, mouse support, and cut/copy/paste of selections.
• Familiar Ctrl-key bindings throughout (Ctrl+S save, Ctrl+O open, Ctrl+P prompt, Ctrl+G go-to-line, Ctrl+F find), plus Alt-modified line operations (move/copy line up/down).

The source is a set of small, single-responsibility C modules — and that is the part most worth studying:

editor.c   row.c      select.c     highlight.c
action.c   input.c    output.c     terminal.c
file_io.c  prompt.c   unicode.c    config.c
os_unix.c / os_win32.c   (platform abstraction)
json.h                   (config parsing)

Deckline relevance

nino is the architectural reference for a tiny editor core in plain C — which is exactly the language and posture of KN-86’s nOSh runtime (C11, no malloc, module pattern). Of the batch, it’s the closest match to how KN-86 itself is built.

• kilo lineage as a buildable spec for a KN-86 in-runtime editor. KN-86 needs in-runtime text editing surfaces — the REPL input line (software/runtime/repl.md) and the nEmacs structural editor (ADR-0008). kilo/nino is the smallest credible reference implementation to study for the core of those: a gap-buffer-ish row model (row.c), an action/undo log (action.c), a render pass (output.c), and a raw-terminal input layer (input.c / terminal.c). nino shows the minimum module decomposition that still supports undo, UTF-8, and selection — a sane target inventory for KN-86’s text-edit core.
• Clean module separation matches the nOSh house style. nino’s editor / row / action / select / highlight / output / input / terminal / file_io split is almost exactly the decomposition the nOSh runtime already uses (display / oled / font / input / cartridge / nosh per the emulator architecture). Citing nino is citing “this is how a small C terminal editor is supposed to be factored,” and it lines up with KN-86’s existing factoring.
• Platform abstraction via os_*.c. nino isolates OS specifics behind os_unix.c / os_win32.c with a shared header. KN-86 has the same shape of problem — desktop emulator (SDL3/macOS/Linux) vs. device (Pi) — and the same answer (a thin platform seam, common core above it). nino is a clean, tiny example of that seam.
• Split screen in a constrained grid. nino does real split panes inside a single terminal. KN-86’s surfaces are single today, but the REPL (edit line + evaluation output) and nEmacs (tree + buffer) both want two regions at once; nino’s split implementation is a small reference for partitioning a fixed grid without a layout engine.

Single-color adaptation

nino, like kilo, is structurally near-monochrome already:

• The file explorer, tab strip, and split divider are box-art + text — directory tree connectors, a │ split rule, a [name] tab label. All port to amber-on-black untouched; the active tab and focused split become inversion rather than a color.
• nino’s syntax highlighting is the only real color use, and in monochrome it reduces to the same token-class-by-glyph-treatment problem every code surface on KN-86 faces (comments dim/sparse, strings bracketed, keywords inverted or heavier). nino’s highlight.c is a compact reference for which token classes a minimal highlighter even bothers to distinguish — a useful scoping input for whatever the REPL/nEmacs highlighter does.
• Selection renders as an inverted span (black-on-amber) — exactly the KN-86 idiom, no color needed.

LISP / extension angle

nino has no scripting or plugin layer — its config is static (docs/configs.md, parsed via a bundled json.h), and the project is explicitly a monolithic core with no runtime extensibility. That absence is itself the useful note:

• nino marks the floor of the editor spectrum in this batch: a small, fast, dependency-free C core with no extension surface, versus micro.md’s full Lua plugin host at the ceiling and microsoft-edit.md’s “immediate-mode now, C-ABI plugins later” middle. KN-86 sits deliberately between nino’s core and micro’s reach: nino-style hand-factored C runtime (the nOSh core, no scripting in the runtime itself), with the extensibility pushed entirely into the cartridge KEC Lisp layer (ADR-0001 / ADR-0005) rather than the C core. nino is the reference for “what the C core should look like when all the extensibility lives one layer up.”
• Concretely: nino is the model for the non-scriptable parts of KN-86 — the runtime’s own text-edit primitives, the row/undo/render machinery — which should stay pure C and never grow a plugin hook. The Lisp comes from carts calling NoshAPI, not from the editor core being scriptable.

Notes

• Batch 8. Lead reference for the minimal-C-editor-core architecture (kilo lineage).
• The kilo/nino source is the recommended starting read for anyone implementing the REPL input line or nEmacs core in the nOSh runtime — smallest credible reference for row model + undo log + raw-terminal IO in C.
• Cross-link microsoft-edit.md and maki.md — the other minimal-stack, no-TUI-framework editors in the batch (Rust own-framebuffer, C# raw-console). nino is the pure-C member of that trio.
• Cross-link micro.md as the opposite end of the same spectrum (heavy extensibility), to frame where KN-86’s core/Lisp boundary sits.
• Cross-link software/runtime/repl.md and ADR-0008 (nEmacs) — the KN-86 surfaces whose C core most resembles a kilo/nino editor.

Image

TODO (human): Pull a screenshot from the nino README showing the file explorer + tabs + a split. Drop at inspiration/screenshots/nino.png.