Writing my own text editor, and daily-driving it

Original Article ↗ Hacker News Discussion ↗

Personal Text Editors & Motivation

  • Many commenters also use self-written or heavily modified editors, often just for themselves.
  • Motivations: precise control over workflow, low tolerance for “BS” in tools, joy of working inside something personally crafted.
  • Some describe long-term dogfooding (close to 20 years) as a major productivity win and a source of daily satisfaction.

Modularity and Editor Architecture

  • Desire for composable editors built from separate executables (search, input mapping, rendering, etc.), akin to how LSPs are decoupled.
  • Acme is cited as a model: simple core, strong integration with CLI tools and a plumbing system.
  • Neovim’s UI separation is noted, but some feel mainstream editors still lack true modularity.

Data Structures & Large Files

  • Rope-based text buffers (e.g., ropey, crop) are recommended for scalability.
  • Counterpoint: on modern hardware, even large monolithic buffers can be fast enough; biggest bottleneck can be mapping between byte positions and screen coordinates.
  • Some care about handling huge logs or single-line files; others ask whether people truly “edit” such logs or just pare them down.

Performance, Electron, and Old vs New

  • Strong nostalgia for 90s-era native editors on modest hardware, perceived as dramatically faster than modern Electron-based tools.
  • VS Code is seen as powerful but heavy; typing latency and startup time are recurring complaints, especially on slower disks or large projects.
  • Others report no noticeable latency in VS Code, suggesting this may be machine- and sensitivity-dependent.

Editor Recommendations (Kate, Zed, Others)

  • Kate receives repeated praise: native, snappy, feature-rich (plugins, SQL integration, markdown workflows), and reliable for large files.
  • Zed is praised as a fast GUI editor, especially for Rust/C/C++; criticism centers on it installing dependencies (e.g., Node.js) without explicit consent.
  • Other tools mentioned: vim/vi for remote servers, micro for terminal, Mousepad/Featherpad for lightweight notes, Howl (mourned), Helix, kakoune, Flow Control.

Building Editors: Lessons & Tools

  • Writing an editor is described as fun, educational, and initially painful: constant bug-fixing when dogfooding.
  • Common strategy: offload features to LSP, tree-sitter, fzf, and keep core small and hackable.
  • Cursor behavior and selection semantics (e.g., Ctrl+Shift+Arrow, leap-key search, multi-cursor) are surprisingly complex and time-consuming to implement.

GUI/Text Libraries & Components

  • Several ask for reusable text-editing engines suitable for custom GUIs, including web/WASM.
  • Scintilla is highlighted as a cross-platform editor engine usable with different front-ends (GUI or TUI), not just a “widget.”
  • Other components mentioned: stb_textedit (studied but considered awkward), raylib (good for rendering but not editing), SDL/SDL_ttf for cross-platform drawing.
  • Modern terminal emulators are said to be surprisingly capable (mouse, clipboard, styling, notifications), enabling rich TUIs; others still prefer a “pure” engine divorced from terminal escape codes.

Miscellaneous

  • The author’s editor repository is shared: https://git.jsbarretto.com/zesterer/zte.
  • Some UX quirks and minor bugs are reported (e.g., Safari theming issues, Kate’s per-tab search state).
  • Consensus: there’s value in both venerable editors (vi/emacs) and new, personal ones; diversity of tools matches diverse workflows.