Let's create a text editor!

This educational project hopes to grow over the next decade or so, exploring/handling one slice of functionality at a time.

Topics we'll learn more about#

Features of Vim, Emacs, VSCode, Zed, and Jupyter
VSCode internals / components / UX and UI
Trying to keep things simple while gradually taking on a mountain of complexity
Snippets, commands, keybindings
Code highlighting based on syntax and semantics
Language servers, static analysis
A deep understanding (from an IDE's POV) of Markdown, Python, and Zig
A shallow understanding of many other languages
Creating a UI/UX option that is audio-based instead of visually-based
Creating a terminal-based UI/UX
Creating a not-terminal-based UI/UX
Creating UI/UX that involves automatically collapsing/expanding or showing/hiding subsets of a file, based on cursor position and/or search queries and/or which aspect of a large class you're engaging with at the moment (if you have such subsets defined, in the spirit of AOP).
Unicode, UTF-8, extended grapheme clusters
Search, regular expressions
whisper.cpp
CRDTs
Security, privacy, sandboxing, WASM, VMs, IPC
Optimizing electron-to-photon latency, including on computers with 240 FPS displays
Hardware-based attempts to optimize electron-to-photon latency, including having an RP2040-based computer emit VGA directly to a CRT display
Performance, Tracing, E2E testing, measuring electron-to-photon latency IRL

(Note: that's literal electrons, not the "Electron" project — the core of this project will not involve any webshit)

Platforms#

($X) : Running directly on ESP32-C6 and RP2040 computers (riscv, arm32)
($XX) : via Raspbian on arm64 Raspberry Pi computers
($XXX - $X,XXX) : via GNU/Linux / BSD / Serenity / macOS / etc on any more powerful {arm64, x64} computer
Cross-platform command-line and web, via WASM with a simple JS wrapper

Core principles#

Keeping journalists alive: any network traffic or filesystem persistence MUST ONLY occur with informed consent.
Pipelining: a list of actions MUST evaluate deterministically to the same state regardless of how much time elapses between the actions or how long any async background tasks take to compute.

When a keyboard-driven tool that you use extensively supports pipelining, your mind can stream action batches via your fingers. That's a profoundly different way of living. There are levels of flow that cannot be obtained if you have to nervously check in with an unpredictable entity after each keystroke in a high-latency "wait, observe the results, think about them, adapt-the-next-action" cycle. Even if the editor has low latency, that loop is fundamentally slow at the human perception/cognition/physiology layer. I'll elaborate more on this elsewhere.

Re: VSCode#

The VSCode team has done a lot of great work and made it available as FLOSS.

And VSCode can be a great editor if you turn off a lot of features, use a network firewall, and customize your shortcuts.

Let's be thankful for them and for that, by learning more about the components and subsystems and either adapting/porting them where relevant or making design choices that do not deviate unneccessarily.

This editor will be a derived work of VSCode, but one that's written from scratch and brings in one aspect/component at a time, while preserving the core principles and optimizing performance.

To paraphrase a play...#

We seek to praise VSCode and to bury it.

The good that corporate-FLOSS-megaprojects create will live on after them;

The antiorganic/enshittification aspects can be interred with the project's bones;