Terminfo.dev

Appearance

1) Overview / summary ​

Overall verdict: terminfo.dev is now much closer to a real documentation product than “just a matrix.” The new fundamentals section, standards narratives, richer category descriptions, and spec links materially improve the site. For the target audience—TUI developers, terminal authors, and curious systems developers—it is already unusually strong.

My short assessment:

  • Best strengths: educational value, interestingness, internal linking, and editorial ambition.
  • Biggest risks now: factual drift in static prose, a few remaining overstatements, and UX issues from hidden links / aggressive glossary auto-linking.
  • Main strategic challenge: the site has grown from data pages into a hybrid of reference + explanation + history. That’s great—but it now needs tighter editorial synchronization so prose, generated analysis, and probe data never disagree.

What seems clearly improved since the last review ​

  • VT510 “final terminal” error: appears fixed.
  • Escape-sequence overclaims: mostly fixed; the site now distinguishes escape-controlled features from behavioral properties.
  • xterm/Kitty over-crediting: partially fixed, not fully resolved. A few lines still over-assign origin/adoption, especially around OSC 8 and Kitty graphics adoption.

My overall score by dimension ​

DimensionAssessment
1. ConsistencyGood, but terminology/style drift remains
2. CorrectnessMostly strong, with several important fixes needed
3. Narrative flowStrong on Features/Fundamentals, too dense on Standards
4. Educational valueExcellent
5. InterestingnessExcellent
6. AppropriatenessGood, but a bit leaderboard-/house-project-biased
7. Typography & varietyVery good, though table-heavy and link affordance is weak
8. SEO & linkingGood, but likely missing page-level metadata and clearer link affordance
9. Missing contentNoticeable gaps for Windows/ConPTY, security, multiplexer/SSH caveats, practical code
10. Specific fixesSeveral P0/P1 items below

TOP 5 most impactful improvements ​

  1. Fix the remaining trust-damaging factual issues (P0)

    • SSH/PTY explanation in tty-architecture.md
    • $TERM claims in term-detection.md
    • Kitty graphics adoption language in standards.md
    • LF/CR nuance in control-characters.md
    • Baseline analysis mismatch in analysis.json

  2. Make links visible by default; tune glossary auto-linking

    • Right now too many links are “secret until hover.”
    • The glossary linker is helpful, but in acronym-dense prose it becomes visually noisy and sometimes distracting.

  3. Tighten the Standards page into a real scannable timeline

    • Keep the origin stories—they’re a differentiator.
    • But move more trivia into callouts/details and make the core “what it added / what survives today” easier to skim.

  4. Make static editorial counts data-driven

    • about.md is already drifting from the current dataset (probe counts, categories, standards coverage).
    • The site needs a single source of truth for counts, category lists, standards lists, and baseline summaries.

  5. Add the missing “practical developer docs”

    • Safe runtime detection recipes in Bash/Python/JS/Rust
    • tmux/SSH/remote-detection caveats
    • Windows/ConPTY
    • Terminal security topics (OSC 52, OSC 8 phishing, paste injection, escape injection)

2) Key details and findings by page ​

Page: docs/features.md — Terminal Features index ​

Strengths ​

  • This is one of the strongest pages on the site.
  • It does a good job of saying:
    • what escape sequences are,
    • what kinds of things are not explicit escape sequences,
    • how support is measured,
    • and how categories map to real app concerns.

By dimension ​

1. Consistency ​

  • Strong visual consistency with cards, taglines, and callouts.
  • Good terminology overall.
  • Minor inconsistency:

2. Correctness ​

Mostly good, but:

  • ESC[?1049h → “screen clears” is an oversimplification. It usually means switch to alternate screen buffer (often visually perceived as a clear screen), not literally just clear-screen behavior.
  • “Top terminals” can imply “best terminals,” when some omissions are intentional tradeoffs.

3. Narrative flow ​

  • Excellent: intro → how sequences work → examples → categories → testing methodology.
  • Good beginner on-ramp.

4. Educational value ​

  • Very high.
  • The “Escape Sequences in Action” table is exactly the right kind of concrete.

5. Interestingness ​

  • Category taglines are lively without becoming gimmicky.
  • The emoji-width callout is especially good.

6. Appropriateness ​

  • Good tone.
  • Slight risk of gamification from “Top:” per category.

7. Typography & variety ​

  • Good mix: prose, table, cards, callouts.
  • Mobile table readability may be okay but still dense.

8. SEO & linking ​

  • Strong internal linking.
  • Problem: inline “hover-link” styling hides link affordance too aggressively.

9. Missing content ​

  • This page should link more explicitly to:
    • baselines
    • safe feature detection
    • how to choose a compatibility target

Page: docs/standards.md — Terminal Standards ​

Strengths ​

  • Ambitious and distinctive.
  • The opening “layers” framing is very good.
  • This page is where the site becomes more than a matrix.

Biggest issue ​

It is good content in slightly the wrong container: it’s called a timeline, but reads more like a set of mini-essays.

By dimension ​

1. Consistency ​

  • Visually consistent with Features page.
  • Terminology mostly solid.
  • Inconsistency: xterm card says 1996+, while the body says xterm began in 1984. That’s confusing.

2. Correctness ​

This page still contains the most important remaining correctness risks.

Likely / clear problems:

  • Kitty graphics adoption is overstated.
    • Your own analysis data says Ghostty lacks Kitty graphics support.
    • Yet the Kitty section implies Ghostty adopted Kitty graphics.
  • OSC 8 may still be over-credited to xterm.
    • xterm documents a lot of de facto behavior, but OSC 8’s modern spread is more VTE/iTerm2/kitty-era than “xterm invented it.”
  • VT220 → Model M explicit copying claim is too strong unless you have a source.
  • VT100 “3KB of RAM” is the kind of precise historical number that should be sourced or softened.
  • Sixel spec URL = Wikipedia is weak for a site otherwise leaning into spec authority.

3. Narrative flow ​

  • Good macro-order.
  • But the page is too dense, especially once you reach Unicode + Powerline.
  • “Origin stories” add value, but too many inline anecdotes slow down scannability.

4. Educational value ​

  • Extremely high for motivated readers.
  • Could be improved by adding a repeated structure per standard:
    1. what it introduced,
    2. what still matters today,
    3. example sequence,
    4. spec/manual link.

5. Interestingness ​

  • Probably the most interesting page on the site.
  • The Sixel printer origin, xterm maintainer fact, UTF-8 diner anecdote, and VT100 positioning all work.

6. Appropriateness ​

  • Mostly good.
  • A few lines drift into “myth-making” rather than precise documentation.
  • “Modern revolution” / “terminal that won” is fine as tagline copy, but body prose should stay a hair more neutral.

7. Typography & variety ​

  • Strong variety, but long.
  • The Unicode section is disproportionately large relative to other standards.
  • The Powerline subsection is engaging, but feels semi-adjacent rather than central to “standards.”

8. SEO & linking ​

  • Good internal anchor structure.
  • Strong topical authority potential.
  • But page would benefit from:
    • a visible timeline graphic,
    • explicit meta description,
    • clearer outbound authority links beyond Wikipedia.

9. Missing content ​

  • “What survived into today’s terminals” summary box per standard.
  • “Primary sources vs later documentation” note.
  • A distinction between:
    • formal standards
    • hardware manuals
    • implementation docs
    • de facto protocols

Page: docs/fundamentals.md — How Terminals Work ​

Verdict ​

Right depth for the audience. This section is a major upgrade.

By dimension ​

1. Consistency ​

  • Clean, simple, scannable.
  • Good card structure.

2. Correctness ​

  • Broadly strong.

3. Narrative flow ​

  • Excellent landing page.
  • The four-card reading order makes sense.

4. Educational value ​

  • Very good.
  • The six-step “keypress to pixels” pipeline is clear.

5. Interestingness ​

  • Less playful than Standards, which is appropriate.

9. Missing content ​

Biggest omission in the fundamentals suite:

  • Windows / ConPTY
  • perhaps also a short “Fonts, glyphs, and rendering” fundamentals page

Page: docs/fundamentals/control-characters.md ​

Strengths ​

  • Strong page.
  • The full C0 table is useful and rare on the web.

By dimension ​

2. Correctness ​

This page needs several important corrections/clarifications:

  • LF row is misleading

    • “In most terminals, also performs a carriage return” is not generally the right mental model.
    • On Unix, users often observe newline behavior because the TTY output layer translates LF → CRLF (ONLCR), not because the terminal itself always treats LF as CR+LF.

  • “hardware-level mapping” is too strong

    • Ctrl-key mapping is not a hardware fact; it’s a longstanding terminal/input encoding convention implemented by software stacks.

  • Ctrl+L / FF

    • “Shells often interpret it as clear screen” is imprecise.
    • More accurate: readline-enabled shells often bind Ctrl+L to clear-screen.

  • Input vs output gets blurred

    • The page mixes:
      • what happens when the terminal receives a control byte in output, and
      • what happens when the user presses Ctrl+key on input
    • That distinction should be made more explicit.

3. Narrative flow ​

  • Good overall.
  • Consider adding a short “The 6 control characters you actually care about” summary before the large table.

4. Educational value ​

  • High.
  • Could go even higher with “Try it yourself” snippets.

7. Typography & variety ​

  • The table is valuable but heavy.
  • On mobile it will be a lot to parse.

9. Missing content ​

  • Hands-on examples:
    • printf '\a'
    • printf 'abc\rX\n'
    • cat -v
    • stty -a | grep onlcr

Page: docs/fundamentals/tty-architecture.md ​

Strengths ​

By dimension ​

2. Correctness ​

One major P0 issue:

  • The SSH section says the “remote terminal emulator (well, the remote PTY + line discipline)” handles escape sequences.
  • That is wrong.
  • In an SSH session, the remote app emits bytes, which come back to the local terminal emulator, which parses and renders them.
  • The remote PTY/TTY stack handles input buffering/signals, not graphical terminal rendering.

This matters because it’s exactly the kind of conceptual model developers rely on.

3. Narrative flow ​

  • Strong.
  • One of the best fundamentals pages.

4. Educational value ​

  • High.
  • The tmux extra-PTY explanation is excellent.

9. Missing content ​

  • Windows / ConPTY caveat
  • brief note that some terminal stacks differ outside POSIX Unix

Page: docs/fundamentals/stty.md ​

Verdict ​

Strong page, mostly solid.

By dimension ​

2. Correctness ​

  • Broadly good.
  • No major factual problem stood out from the excerpt.

3. Narrative flow ​

4. Educational value ​

  • High.
  • It explains not just what raw mode is, but why apps need it.

7. Typography & variety ​

  • Good use of tables.
  • Could use one or two short runnable examples.

9. Missing content ​

  • A tiny “lab”:
    • stty -echo
    • read -r
    • stty echo
    • stty raw -echo; cat; stty sane

Page: docs/fundamentals/term-detection.md ​

Strengths ​

  • One of the most useful pages for your target audience.
  • The layered detection strategy is practical and mature.

Biggest issue ​

This page now contains one of the more serious trust issues: over-generalized $TERM claims.

By dimension ​

2. Correctness ​

Important corrections needed:

  • “Almost every modern terminal sets $TERM to xterm-256color” is too broad.
  • The examples given include Kitty, which is a notable exception (xterm-kitty), and several other modern emulators also ship terminal-specific entries depending on environment/install.
  • The tip “every terminal pretends to be xterm-256color” is false as written.

This is a credibility issue because terminal developers know these nuances.

Also:

  • $COLORTERM as “most reliable way to detect truecolor” is okay as practical advice, but should be framed as common convention, not universal truth.
  • Missing important caveat: tmux/screen/SSH can distort or mediate detection.

3. Narrative flow ​

  • Very good.
  • Good progression from weak methods to strong methods.

4. Educational value ​

  • High.
  • Could become excellent with code snippets in Bash/Python/JS.

6. Appropriateness ​

  • Good.
  • The anti-$TERM argument is persuasive, but needs more nuance to stay trustworthy.

8. SEO & linking ​

  • Excellent topic choice; likely high-value page for search.

9. Missing content ​

This page especially needs:

  • TERM_PROGRAM, VTE_VERSION, KITTY_WINDOW_ID, WT_SESSION etc. as secondary hints
  • XTGETTCAP / terminfo capability queries
  • tmux / SSH / multiplexer detection caveats
  • “use timeouts + sentinel query” code examples

Page: docs/glossary.md and glossary auto-linking ​

Glossary page itself ​

  • Good structure.
  • Needs search/filter; alphabet-only is not enough for 107 entries.

Auto-linking behavior ​

Net judgment: helpful, but currently a little too aggressive.

Helpful where ​

  • Fundamentals pages
  • Standards page
  • Any page where acronyms appear for the first time

Distracting where ​

  • Acronym-dense technical prose
  • tables
  • repetitive mentions of CSI/OSC/SGR/DECSET/etc.

Recommendation ​

Auto-link only:

  • first occurrence per page or per section,
  • not inside headings/tables/cards,
  • not when the term is already inside an obvious explanatory sentence.

Also: visually distinguish

  • real inline links
  • glossary links
  • hover-only “hidden” links

Right now those categories are too visually close.

Page: docs/about.md ​

Strengths ​

  • Good methodology framing.
  • Good articulation of why terminfo.dev differs from terminfo.

Biggest issue ​

This page is showing synchronization drift.

By dimension ​

1. Consistency ​

  • The rest of the site is increasingly data-driven.
  • This page still has static counts and lists that are already aging.

2. Correctness ​

Likely outdated/inconsistent:

  • CLI text says 100 probes, but site context says 148 features tested
  • “100+ features tested” is now underselling the site
  • Feature categories list appears outdated vs the current 14-category structure
  • Standards coverage list omits newer/current coverage structure

4. Educational value ​

  • Good.
  • Could improve with an explicit “limitations” section.

6. Appropriateness ​

  • Fine overall.
  • But because Silvery/Termless are closely related projects, a more explicit first-party disclosure would improve trust.

9. Missing content ​

Add:

  • sample size / versioning / defaults / config assumptions
  • how conflicting community submissions are reconciled
  • freshness / stale-data indicators
  • methodology limits for font-dependent and visually rendered features

Cross-cutting review by site-specific question ​

Previous review issues: truly resolved? ​

  • VT510 “final terminal” error: yes, fixed
  • escape-sequence overclaims: mostly fixed
  • xterm/Kitty over-crediting: not fully fixed
    • xterm still feels over-credited in places
    • Kitty graphics adoption is still overstated

Fundamentals section: right depth? ​

Yes. It’s probably the best new addition. It serves both:

  • beginners who need the mental model
  • experienced developers who want a clean refresher

Character set / Unicode / Powerline section: engaging? ​

Yes, very engaging. It gives the site personality. But:

  • it is a bit long for the Standards page
  • and the Powerline/Nerd Font content would be stronger either:
    • on a dedicated page, or
    • as a shorter sidebar/callout with a link onward

Also, if PUA glyphs render as blank boxes/empty cells, the section visually breaks.

Origin stories on standards page: value or clutter? ​

Value, but only if subordinated to the reference function. Current state: a little too much inline story, not quite enough skimmable structure.

Historical terminal pages: useful or niche? ​

Useful, if each page answers:

  • what this terminal introduced,
  • which sequences survived,
  • why developers still care.

If they become museum pages, they’re niche.
If they stay tied to modern behavior, they’re a major differentiator and SEO asset.

Framework pages: useful for the audience? ​

Yes, especially if the audience includes app developers deciding what they can rely on. But they should:

  • disclose first-party relationships clearly,
  • avoid marketing tone,
  • include a concrete “requires these terminal features” table.

3) Different perspectives ​

For a beginner developer ​

This site is unusually strong. The Fundamentals pages and examples are enough to create a coherent mental model. Biggest issue is visual/link clutter from too many acronyms and hidden links.

For a TUI framework/app author ​

The site is highly valuable, but now needs:

  • copy-pastable detection recipes,
  • clearer baseline-to-feature mapping,
  • tmux/SSH caveats,
  • security guidance.

For a terminal emulator author ​

The site is increasingly useful as a reference, especially with spec URLs and historical context. But precision matters more here: over-crediting, adoption overstatements, or stale counts will get noticed fast.

For an SEO/content strategist ​

You now have strong topical authority. The opportunity is to:

  • add real page descriptions/OG metadata,
  • create tighter pillar/cluster linking,
  • make history pages support task pages rather than compete with them,
  • and improve link discoverability.

4) Recent developments / current state ​

The recent changes are directionally excellent:

  • Fundamentals section: biggest quality gain
  • Historical standards/terminal pages: strong differentiation from generic compatibility tables
  • Spec URLs on 143/148 features: trust win
  • Glossary plugin: good idea, but needs tuning
  • Escape sequence displays: strong educational improvement

Current state: the site is transitioning from a probe database to a reference publication.
That is a good transition—but it requires:

  • better editorial synchronization,
  • slightly stricter source discipline,
  • and more visible practical guidance.

5) Specific fixes — exact text → suggested revision ​

P0 (must fix soon) ​

PageCurrent textSuggested revision
fundamentals/tty-architecture.md“This is why terminal escape sequences work over SSH — they're just bytes flowing through the tunnel. The remote terminal emulator (well, the remote PTY + line discipline) handles them exactly as a local session would.”“This is why terminal escape sequences work over SSH — they're just bytes flowing through the tunnel. The remote application emits escape sequences, but your local terminal emulator is the component that parses and renders them. The remote PTY and line discipline handle input buffering, echo, and signals.”
fundamentals/term-detection.md“The problem is that almost every modern terminal sets $TERM to xterm-256color, regardless of what it actually is. Ghostty, Kitty, iTerm2, Alacritty, WezTerm — they all default to xterm-256color.”“The problem is that $TERM is only a rough compatibility label. Many terminals still use xterm-256color, while others ship terminal-specific entries such as xterm-kitty, alacritty, wezterm, or terminal-specific values when those entries are available. In all cases, $TERM usually tells you how the terminal wants to be treated, not its full modern feature set.”
fundamentals/term-detection.md“::: tip The $TERM lie — every terminal pretends to be xterm-256color”“::: tip $TERM is a compatibility hint, not a capability oracle”
standards.md“Kitty also defined extended underline styles… These extensions have been adopted by Ghostty, WezTerm, foot, and other modern terminals...”“Kitty also defined extended underline styles… The Kitty keyboard protocol has been adopted by several modern terminals, including Ghostty, WezTerm, and foot. Adoption of Kitty graphics is narrower and should be described separately.”
content/analysis.json (baseline/modern)“Most commonly missing: Clipboard access (OSC 52), Foreground color query (OSC 10), Background color query (OSC 11).”If those are not actually Modern-baseline features, regenerate from the correct baseline set. If they are, update content/baselines.json so the prose matches. The baseline description and baseline analysis must come from the same source of truth.

P1 (important) ​

PageCurrent textSuggested revision
fundamentals/control-characters.md“LF — move cursor down one line. In most terminals, also performs a carriage return (newline behavior).”“LF — move cursor down one line. Whether it also returns to column 1 depends on the path: in many Unix TTY configurations, the line discipline translates output LF to CRLF (onlcr), while a raw terminal emulator may treat LF as vertical movement only.”
fundamentals/control-characters.md“This is a hardware-level mapping — it happens in the terminal emulator before the byte reaches any software.”“This is the traditional terminal input encoding convention: the OS input stack and terminal emulator map key events to control bytes before the application reads them.”
fundamentals/control-characters.md“FF — treated as LF by most terminals. Shells often interpret it as "clear screen."”“FF — treated as LF by most terminals. In practice, readline-enabled shells often bind Ctrl+L to clear-screen, but that is a shell/readline behavior, not a universal meaning of the FF byte.”
standards.mdxterm card year: “1996+”Either change to “1984+” or explicitly label it “1996+ maintenance era” to match the body text.
standards.md“The VT220's keyboard layout (LK201) was so influential that IBM's Model M design team explicitly copied its inverted-T arrow cluster...”Unless sourced, soften to: “The VT220's LK201 popularized the inverted-T arrow cluster and editing-key arrangement that later became common on PC keyboards.”
standards.md“The DEC VT100 ran on an Intel 8080 CPU with 3KB of RAM...”If you have a source, keep it and cite it. Otherwise: “The DEC VT100 ran on an Intel 8080-family CPU with very limited memory by modern standards...”
about.mdnpx terminfo.dev probe # Run 100 probes against your terminalnpx terminfo.dev probe # Run the current probe suite against your terminal (or inject the count dynamically)
about.md“45+ new features… from 62 to 100+ features tested”Keep as historical changelog if you want, but add a current summary above it with live counts so the page doesn’t feel stale.

P2 (polish) ​

AreaCurrent patternSuggested revision
Inline links site-wide.hover-link makes links look like plain text until hoverGive inline links a subtle default underline or color shift. Keep hover enhancement, but don’t hide affordance entirely.
Glossary auto-linkingauto-link many repeated acronyms everywhereLink first occurrence per page/section only; suppress in tables/headings/cards.
Standards page structurelong essay blocksAdd a repeated “Why it matters today” summary box for each standard.
Glossary pagealphabet-only navigationAdd client-side search/filter.
Powerline tablePUA glyphs may render blankAdd screenshots, fallback SVGs, or explicit codepoint labels with a font note.

6) Missing content developers will expect ​

These are the most conspicuous gaps:

  1. Windows / ConPTY

    • If you’re documenting terminal architecture in 2026, this omission is noticeable.

  2. tmux / screen / SSH caveats

    • Especially for feature detection and protocol pass-through.

  3. Security

    • OSC 52 clipboard
    • OSC 8 phishing/spoofing
    • bracketed paste / paste injection
    • terminal escape injection / log viewer hazards

  4. Practical detection recipes

    • Bash, Python, JS/Node, Rust examples for:
      • truecolor
      • bracketed paste
      • DECRPM
      • DA1 sentinel strategy
      • XTVERSION
      • timeout handling

  5. Fonts/rendering

    • glyph fallback
    • ambiguous width
    • Nerd Fonts / PUA
    • ligatures vs terminal cells
    • why “supported” still may render badly with a given font

  6. Versioning / confidence / methodology limits

    • default config vs user config
    • sample freshness
    • single submission vs multiple submissions
    • visual-vs-parser caveats

7) Sources and references ​

Primary standards / manuals ​

Terminal / Unix behavior ​

  • POSIX termios / terminal interface
    termios(3), tcgetattr(3), cfmakeraw(3), stty(1p)
  • Linux PTY overview
    pty(7)

Unicode ​

Color / detection conventions ​

Site materials reviewed ​

  • docs/features.md
  • docs/standards.md
  • docs/fundamentals*.md
  • docs/glossary.md
  • docs/about.md
  • content/baselines.json
  • content/frameworks.json
  • content/glossary.json
  • content/analysis.json
  • content/categories.json
  • content/standards.json

If you want, I can turn this into a maintainer action list next—e.g. a GitHub-style checklist with:

  • P0/P1/P2
  • file paths
  • exact line-level edits
  • and “quick win vs structural change” labels.

Powered by Termless
Playwright for Terminals