Every once in a while I get the urge to go backwards.

Not in a regression-therapy way, more like touching base with the roots of the tools we take for granted. I have spent most of my career in modern Unix environments where you can fire up Vim, Neovim, or VS Code without thinking. But the earliest systems I ever brushed up against did not have any of those comforts. On CP/M and early Unix, spinning disks were slow, RAM was scarce, terminals were primitive, and your editor was basically a line-oriented conversation with the machine.

That is where tiny-ed comes from.

I wanted a little taste of that world again. A minimalist ed-style editor, something that could plausibly run on CP/M or an early microcomputer. Not a full port, not a museum-grade re-creation, just a compact C program that behaves like ed in spirit: no curses, no screen refresh, no real-time editing, no windows. Just you, the file, and a prompt.

A tiny editor you can actually hold in your head.

Why build something like this?

Honestly?
Because I missed the feeling of working inside those constraints.

Early computing was not elegant so much as resourceful. You did not build big architectures, you built little tools and stitched them together. You memorized a tiny command set and nudged text around like a sculptor rather than an IDE-driven typist.

So tiny-ed started as an experiment in:

  • Minimalism: how small can an editor be and still be useful?
  • Approachability: can the whole codebase fit in a few screens?
  • Portability: could this realistically be adapted to CP/M?
  • Mental nostalgia: does typing 1,5p feel like 1981 again?

Spoiler: yes, it does.

What tiny-ed actually does

This is not a joke project. The editor is completely functional, including:

  • loading a file into a simple in-memory buffer
  • classic line-number movement
  • print (p), append (a), insert (i), delete (d)
  • write (w) and quit (q)
  • range operations like 1,10p or .,$d
  • error handling and simple prompts
  • no screen control, full TTY friendliness

In other words, it is an ed-lite written with clarity in mind.

The whole thing lives in a single C file, easy to read and hack on.
It compiles cleanly with:

cc -Wall -o tiny-ed tiny-ed.c

And because it avoids POSIX complexity, it should be very portable. Dropping this onto a CP/M-style C compiler (or cross-compiling for Z80) would not be out of the question.

Working like it is 1979

There is something refreshing about opening a file and seeing nothing. No syntax highlighting. No mouse. No colors. No status bar. Just a prompt. You do not edit the screen, you edit the buffer.

It forces you into a different headspace:

  • You think in chunks instead of keystrokes
  • You edit by intent instead of twitching around a cursor
  • You type fewer commands but make bigger structural decisions
  • You slow down

It is the opposite of a modern code editor, and that is the charm.

What I learned building it

tiny-ed reminded me that:

  • Text editing is surprisingly simple at its core
  • C is still a great language for small, sharp tools
  • UX is not always about speed, sometimes constraints are comfortable
  • Sometimes it is okay to build something just because you felt like it

This was not a high-ROI, high-traffic, SEO-optimized project.
It was an indulgence, a tiny homage to the tools that shaped early computing, built for the fun of it.

What is next?

Maybe:

  • a CP/M-targeted build
  • a diskless mode
  • macro support
  • loading and saving through pipes
  • a "visual" mode that is still TTY-safe
  • or maybe nothing at all

This might stay exactly what it is: a tiny line editor that brought me joy to write.

And honestly, that is enough.