The problem
glow is good, and it is the reader most people reach for. But it renders a document as a stream of text with hash marks turned into colours, and it has no contents pane: in a long README or an architecture document you cannot see where you are or jump to where you want to be. I wanted a reader that treated a markdown file as a document with structure, kept glow’s flags and keys so muscle memory carried over, and did it in a cell grid.
The design
A page, not a stream. The renderer lays out a centred reading column on a painted page: headings are typography rather than markers, code blocks are sealed cards, tables get box drawing, GFM callouts get an icon and a hue. Math delimiters are stripped so $E = mc^2$ reads as notation rather than punctuation, because there is no glyph budget for typesetting TeX in a terminal.
The HTML in a README is content too. A centred <h1> becomes a heading in the contents pane, a badge image becomes the link it advertises, a <details> block opens with its <summary> as the title, and an HTML <ul> or <table> is drawn by the same emitter its markdown spelling is. The tags never reach the page.
A contents pane that tracks the scroll. The pane follows the section on screen and folds sections in place. This is the feature glow has no equivalent of and the reason the project exists.
Themes are data. Ten palettes ship as TOML, so a new theme needs no Rust and no recompile. The theme picker previews against the document behind it.
Reads what you point it at. A file, a directory (with a streaming file browser and fuzzy filter), standard input, a URL, or github.com/owner/repo. It reloads when you save, and e opens your editor at the line on screen.
What I would walk through in an interview
- Laying out proportional typography ideas in a fixed cell grid: what a centred column, a margin, and a sealed card mean when the unit is one character cell.
- Why the README screenshot is generated by a script from the renderer’s own output, and what that buys when a rendering change lands.
- The 897 tests: what a rendering test looks like when the output is a grid of styled cells, and how the emitter for markdown and for HTML is held to the same result.
- Packaging one binary for crates.io, Homebrew, Scoop, and nixpkgs, and why the AUR package exists in the repository but not on the AUR.
What is next
The nixpkgs submission is in review. The roadmap before 1.0 is in the repository; the largest item is a wider set of HTML the emitter understands, driven by the READMEs people actually point the reader at.