What Text Editors Solve

A text editor stores a string and lets the user efficiently:

• Read it (display).
• Modify it (insert, delete, replace).
• Navigate it (cursor, search).
• Undo/redo changes.
• Save / load.

The interesting part: the data structure.

Naive: store as str. Insert at middle = O(N) copy. For 1 GB log files, every keystroke is a second.

Real editors use:

• Gap buffer: array with movable hole. Used by Emacs.
• Piece table: append-only buffer + edit log. Used by VS Code, Notepad++.
• Rope: tree of strings. Balanced; per-op log time. Used by Xi, jed.
• Line array + per-line gap: hybrid. Used by classic editors.

Why?

• Real users expect smooth editing of files of ANY size.
• Word docs, source code, log files, books all in one editor.
• ~1ms response for any keystroke.

Real editors:

• Vim (1991, Bram Moolenaar): modal. Fast for power users.
• Emacs (1976+, RMS): Lisp-extensible. Customizable.
• VS Code (2015, Microsoft): Electron + TypeScript. Massive ecosystem.
• Sublime Text (2008): C++. Very fast.
• Helix (2021): Rust, modal, modern.
• Neovim: Vim fork with better extensibility.
• Zed (2023): Rust, GPU-rendered, multiplayer.

We'll build:

• Buffer (rope).
• Cursor + selection.
• Insert/delete operations.
• Undo/redo.
• Line-aware operations.
• Render to terminal.

By the end: a working tiny editor. Not vim, but the same skeleton.

Reference: Crafting Interpreters for some text-handling, "Building a Text Editor" series by Salvatore Sanfilippo (kilo editor — ~1000 LOC of C).