The Terminal Ecosystem

What every real terminal emulator, multiplexer, and terminal library is — architecturally — and what to steal from each.

Warning: Version numbers, feature sets, and architectures move. This page describes the shape of each project and the design idea it demonstrates, not a current feature matrix. Where a capability matters to you, check the project — and better, run the probe from the differential-testing chapter.

Terminal Emulators

What to steal from each

Multiplexers

Tip: Read abduco before tmux. It is detach/attach with nothing else attached to it — a few hundred lines that make the "why a server" argument concrete without the distraction of panes, layouts, and a scripting language.

tmux vs. your implementation

Worth understanding because you made a different choice deliberately:

Neither is wrong. tmux's choice buys universality; yours buys simplicity and multi-client flexibility. Being able to state that trade-off is the point — it is a capstone write-up question.

Terminal Libraries (Reusable Cores)

The projects that already did what Section 5 asks of you.

The exercise

Pick one, clone it, and produce the mapping table onto your nine crates:

git clone https://github.com/alacritty/vte && cd vte
cargo tree --depth 1        # how many dependencies? why so few?
tokei src/                  # how many lines is a production parser?

Then ask, for each difference: what did their choice buy them? That question is worth more than another chapter of prose, and it is Lab 20's challenge 3.

Terminal Programs Worth Testing Against

Your compatibility matrix uses these. Grouped by what they stress:

# A quick torture corpus:
printf '日本語 中文 한국어\n'
printf '👨‍👩‍👧‍👦 👍🏽 🇯🇵 ❤️\n'
printf 'e\xcc\x81 a\xcc\x80 o\xcc\x88\n'
printf '┌───┬───┐\n│ a │ 日 │\n└───┴───┘\n'
man ls | head -20            # overstrike bold
git log --graph --oneline -20 --color=always

Benchmarks and Comparisons

git clone https://github.com/alacritty/vtebench && cd vtebench
cargo build --release
./target/release/vtebench -b ./benchmarks alt-screen-random-write | your-terminal

Run these against your terminal at the capstone. The numbers belong in your write-up — and a terminal that is 10× slower than Alacritty is fine and expected; one that is 1000× slower has a specific bug worth finding.

Where the Protocol Is Going

Active work, and the projects driving it:

This is the most active the terminal protocol has been since the 1990s. Several of the capstone portfolio projects are implementations of things on this list, and a good implementation plus a written report is a real contribution.

Where to Contribute

Once you finish this curriculum you have the context to be useful immediately. In rough order of approachability:

What makes you useful on day one: you can read a bug report, reproduce it with a recording, bisect to the offending byte, and name the missing capability. That workflow — from the debugger chapter — is most of what maintaining a terminal consists of.

Validation / Self-check

1. Which project split its parser into a separately published crate, and what did that buy the ecosystem?
2. What is libghostty, and which two applications consume it?
3. Why read st before reading xterm?
4. Why read abduco before reading tmux?
5. What does tmux send its clients, what do you send yours, and what does each choice cost?
6. Name three protocol proposals from the last decade and the project that drove each.
7. Map vte, alacritty_terminal, termwiz, and portable-pty onto your nine crates.
8. Which programs would you use to test scroll regions, mouse drag, and overstrike bold?
9. What does vtebench measure, and what would a 1000× slowdown against Alacritty indicate?
10. You want to contribute a parser fix upstream. Which project, and what would your PR contain?

See also: Primary Sources · The Capstone Portfolio · Interactive Compatibility