Microsoft Edit

What it is

edit (binary: edit, or msedit) is Microsoft’s small terminal editor that “pays homage to the classic MS-DOS Editor, but with a modern interface and input controls similar to VS Code.” Its stated goal: “an accessible editor that even users largely unfamiliar with terminals can easily use.” The hero shot is the About dialog floating over a classic dropdown-menu-bar UI — the MS-DOS Editor silhouette, modernized.

What makes it interesting beyond the aesthetic is what’s under it. Edit does not use ratatui, crossterm, or any third-party terminal crate. It implements its own stack in-tree:

• crates/edit/src/framebuffer.rs — “A shoddy framebuffer for terminal applications” (its own words): a cell grid it diffs and renders.
• crates/edit/src/vt.rs — direct VT escape-sequence emission (input parsing + output).
• crates/edit/src/tui.rs — an immediate-mode UI framework, explicitly modeled on Dear ImGui.
• crates/edit/src/bin/edit/draw_menubar.rs, draw_statusbar.rs, draw_editor.rs, draw_filepicker.rs — the menu bar, status bar, editor pane, and file picker are each a discrete draw routine over that framebuffer.
• oklab.rs / cell.rs — color and cell model.

Deckline relevance

This is the entry in the batch whose internal architecture most closely mirrors KN-86’s own, and whose menu/dialog UI is the cleanest retro-but-approachable reference.

• Custom framebuffer + VT renderer, no terminal-framework dependency. KN-86 is the terminal — it renders to an SDL3 framebuffer on the emulator and directly to the panel on the Pi (see opentui.md for why deferring to a host terminal isn’t an option for KN-86). Edit independently arrived at the same conclusion for a different reason (binary size, control) and built framebuffer.rs + vt.rs + a cell model. It’s a worked, shipping example of exactly KN-86’s render-stack shape: own the cell grid, diff it, emit. Validation that the nOSh runtime’s direct-framebuffer approach is the right call, not an exotic one.
• Dropdown menu bar + modal dialogs as the approachable surface. Edit’s whole UX thesis is that a 1980s-style menu bar (File/Edit/View, openable with the keyboard) plus modal dialogs (About, Find/Replace, file picker) is more approachable to non-terminal users than a vim/emacs modal model. For KN-86 this is directly relevant to the SYS surface and to the Legacy Terminal mode (ADR-0021): a discoverable menu-bar + dialog idiom is the right register for the device’s more “OS-shell” surfaces, as opposed to the Lisp-primitive register of the cartridge gameplay. The draw_menubar.rs / draw_filepicker.rs separation is a clean model for KN-86’s firmware-owned UI chrome.
• Approachable control scheme over retro purity. Edit keeps the retro look but uses VS Code-style Ctrl-key shortcuts and menu navigation rather than authentic-but-hostile DOS keystrokes. KN-86’s tension is identical — the fiction wants period authenticity, the operator wants to not be lost. Edit’s answer (retro skin, modern muscle memory) is a defensible position to cite when KN-86 makes the same call on its shell surfaces.

Single-color adaptation

Edit is a full-color app, but the structural parts port cleanly:

• The menu bar and dialog frames are pure box-art + text — CP437 borders, reverse-video for the active menu item, a drop-shadow row. None of that needs color; it’s exactly the amber-on-black box-drawing idiom KN-86 already uses. The active-menu-item highlight becomes inversion (black-on-amber) — the same focus idiom KN-86 uses everywhere.
• Edit’s modal dialogs dim/overlay the background (a classic DOS-dialog move). Monochrome KN-86 can’t dim by desaturation, but it can dim by stippling the background (replace background cells with a sparse ░/· field) or by drawing the dialog in inverted video over a thinned backdrop — recovering the “this dialog is modal, the stuff behind it is inactive” read without a second color.
• The menu-bar accelerator convention (one highlighted letter per menu: File, Edit) survives monochrome via inversion or bracketing of the accelerator glyph.

LISP / extension angle

Edit ships no plugin system today — but tui.rs’s own design notes make the most useful extension-architecture argument in the whole batch:

“the primary reason for [immediate mode] is that the lack of callbacks means we can use this design across a plain C ABI, which we’ll need once plugins come into play. GTK’s g_signal_connect shows that the alternative can be rather cumbersome.”

That is a direct, independent endorsement of KN-86’s exact bet:

• Immediate-mode UI + a plain C ABI is the plugin-friendly combination. KN-86’s NoshAPI is a C ABI (ADR-0005); cart Lisp drives the runtime by calling primitives each frame rather than registering long-lived callbacks the runtime holds across the FFI boundary. Edit chose immediate mode specifically to keep its future plugin ABI callback-free. This is strong external corroboration that KN-86’s “cart Lisp redraws by calling NoshAPI primitives, runtime holds no Lisp callbacks across the boundary” model is the right design for an extensible C-ABI’d terminal app — not just an expedient one. (Contrast with micro.md, whose Lua plugins do register retained callbacks the host invokes — micro can afford it because the boundary is in-process Go↔Lua, not a C ABI meant for arbitrary languages.)
• Settle-loop reconciliation. Edit’s immediate-mode core redraws and re-runs the frame until needs_settling() is false (a click in one frame may change state requiring another). KN-86’s event-driven redraw (idle until input, then redraw; ADR-cited 20 fps animation cap) is a coarser version of the same idea — Edit’s settle loop is a reference for how a cart Lisp handler that mutates state mid-frame should trigger a clean re-render rather than a stale one.

Notes

• Batch 8. Lead reference for the menu-bar/dialog cluster and the from-scratch framebuffer-TUI architecture.
• The tui.rs “why immediate mode → because plain C ABI for plugins” rationale is the single most quotable architecture note in the batch for justifying NoshAPI’s design (ADR-0005). Worth surfacing into the NoshAPI design rationale directly.
• Cross-link ADR-0021-legacy-terminal-mode.md — Legacy Terminal mode is the KN-86 surface that most wants a discoverable DOS-style menu/dialog idiom; Edit is the reference UI for it.
• Cross-link micro.md (retained-callback Lua plugins) and opentui.md (framework that defers to a host terminal) — the three together triangulate KN-86’s render-stack + extension-ABI position.
• Cross-link os-models.md for the broader retro-OS-chrome aesthetic lineage.

Image

TODO (human): Use the repo’s assets/edit_hero_image.png (menu bar + About dialog over the editor). Drop at inspiration/screenshots/microsoft-edit.png. The menu bar and the modal dialog are the two elements this entry is about.