txm, a terminal math renderer with three dependencies and no usage section

The manifest is one patch version ahead of the newest tag

The manifest declares version 0.1.6. The two newest published tags are 0.1.4 and 0.1.5, and the branch was last pushed on 19 August 2026, about a month after the newer of those two.

So the default branch is not any released version. It is one patch release further along than the newest tag, on a project that is under 0.2 and has shipped two releases in the visible window, both with titles that are nothing but the version number.

None of the five install paths in the readme names a version, which is the correct choice for a command that should give you the current release. It also means the readme cannot tell you which of the four codebases you end up with. The registry copy is the newest release. The git copy is the branch, which is one patch ahead. The rolling distribution package tracks the branch rather than a tag, so it is the same code as the git copy today and something else next month. And the Nix path fetches the branch, pinned only to whatever that branch's lock file says at the moment it is fetched.

Four channels, four points in a moving line, and a readme with no version column.

The manifest is otherwise well specified: the licence is a single permissive expression, the author and repository fields are filled in, and the language edition is a recent one.

A LaTeX renderer with no LaTeX dependency

There are three dependencies and they are worth naming individually, because what is missing from that list is the story.

One is a lexer generator. One is a macro crate for deriving error types. One is a table of character display widths. That is the entire dependency surface of a program whose purpose is rendering LaTeX.

There is no parser crate, no math layout library, no font metrics beyond a width table, and no terminal drawing library in the default build. So the tokenising, the grammar, the layout, and the box drawing are all in this repository. The lexer being generated rather than hand-written suggests the author drew the line at the tokeniser and wrote everything above it by hand.

The width table is the one that explains what the output can and cannot be. A terminal renderer needs to know how many cells a character occupies, and a width table gives you that for the characters a font renders at one cell or two. It does not give you glyph shapes, line metrics, or sub-cell positioning, which is why maths in a terminal looks the way it does and why a renderer of this size is a pleasant thing to have rather than a replacement for anything.

Three dependencies is a remarkable number for this category, and the readme does not mention it.

The terminal UI feature is off by default and absent from the readme

There is one optional dependency, and it is behind a feature flag with the same name. The default feature set is empty, which means a plain install gets no trace of it.

What the flag enables is a core crate from a terminal user interface framework, and the natural reading is that TXM can render into that framework's buffer instead of writing to standard output. If that is right, the engine is separated from its output medium, which is the right design for a library that will end up inside someone else's full-screen application.

None of that appears in the readme. There is no mention of the flag, no installation command that enables it, and no statement of what the feature does beyond its name. A user who wants to draw maths inside a terminal UI has to read the manifest, work out that the flag exists, and then find out from the source what the integration surface is.

The empty default is the right call for a crate with an optional integration, and the omission is the ordinary one: features added after the readme was written, documented in the manifest and left out of the prose. It is the clearest example in this repository of the manifest being the real documentation.

Six commands, five channels, three different names

The installation section has five subsections and six commands, and the same program has three different names depending on which one you use.

The first is a single command that fetches and runs the branch directly, with a requirement that the user has a package manager with flakes enabled. It is presented under a screenshots heading, as a demonstration, and it is the only place the tool is shown doing anything.

The second and third are Arch Linux, and they are not the same thing. One installs a package whose name carries a suffix meaning it tracks the repository rather than a release. The other is a manual clone of that same package's build repository followed by the packaging tool. So the two Arch options give you identical code, and it is the unreleased code.

The fourth is Gentoo, under a different package name in a different category. The fifth and sixth are the Rust package manager, once from the registry and once from the repository, which again differ by a release.

So: a rolling package name, a Gentoo name, and a crate name, for one binary. The readme does not tabulate them, does not say which is recommended, and does not say what version any of them gives you.

There is no usage section, only a command inside a screenshot heading

Read the structure of the document. It opens with a title block, then a heading for screenshots, and under that heading a single fenced command with a LaTeX expression as its one argument and a note about a requirement. Then it jumps to installation, bindings, projects using it, and the licence.

That command is the whole documented interface:

nix run github:thatmagicalcat/txm -- "E = mc^2"

There is no usage section. The one invocation in the file is presented as a screenshot caption, which is why the entire documented interface of the program is a positional argument containing a LaTeX string.

What a reader cannot learn from the readme: whether there are flags, whether output can be selected, whether it reads a file or standard input, whether it has an interactive mode, what it does with a syntax error, what it exits with, or whether it wraps or paginates long output. The error dependency in the manifest says errors are typed, so there is a defined failure mode, and the readme does not say what it looks like.

For a program whose whole value is turning a string into readable output, that is the largest gap, and it is a consequence of the readme being written as a distribution page rather than as a manual.

The one listed integration is a sentence with no object

The section listing projects that use the tool contains one entry. It is a link to a Neovim plugin, described as providing LaTeX preview inside the editor, and then the sentence stops mid-clause after the word using.

There is no object to that using. Whatever the plugin does with TXM beyond previewing LaTeX is not stated, and the sentence as published does not parse. The readme was not truncated by anything visible; the section simply ends there, followed by the licence heading.

That is a small defect on its own. What it tells you is that the section was started once, was never finished, and has not been revisited. The tree still holds a screenshots directory, so the images exist; the list was just not maintained alongside them.

For a project whose main integration story is being embedded in an editor, having the one listed integration describe itself as a truncated fragment is an unfortunate place to stop. The bindings section has the same problem in a milder form: two bullets, two directory links, and no further word about either.

Two language bindings and no library target to build them from

The tree contains directories for C and C++ bindings and for Python bindings, and the readme links to both. That is the entire treatment: two bullets under a heading, with no build command, no package name, no version, no statement of which release of the engine they bind, and no example of calling it.

The manifest does not help. It declares a package, a version, three dependencies, one optional dependency, and a feature. There is no library section, no instruction telling the compiler what kind of library to emit, and no list of member packages. So the two binding directories cannot be built from the manifest in the repository root, which means they contain their own manifests, and the readme does not say so.

That is the shape of the problem for anyone wanting to call TXM from Python or C: find the directory, find the second manifest inside it, work out which engine version it targets, and build it. Every one of those steps is discoverable and none is written down.

The bindings are also the feature that rots first in a project with no development section, no test instructions, and a manifest that has already moved past the newest release.

The licence is dual and the readme presents it as a list

The manifest expresses the licence as a choice: this software is available under the MIT licence or the Apache one, at your option. Both licence files are in the repository root, which is the standard arrangement for a Rust project with that choice.

The readme's licence section lists the two files as two separate items, one after the other, with no statement that they are alternatives. A reader skimming it can reasonably conclude the project is dual licensed in the sense of owing both, which is the opposite of what the manifest says and is a materially different thing for anyone packaging it.

That is the last section of a ninety-word readme, and it is the one place where the prose is less precise than the metadata. The manifest, the author field, the repository field, and the readme field are all filled in correctly, which is more than most projects manage, and the licence expression is the one line in the whole file that would have benefited from a sentence of explanation.

Everything else the readme does not cover, it leaves to the repository. There is a tests directory, a directory of contributed material, a lock file for the Rust build and another for the Nix build, and none of them is mentioned.

Editorial conclusion

Use txm if you want LaTeX output in a terminal and you are willing to read the source, because that is where the behaviour is documented. Four things to know. That there is no usage section, so the entire documented interface is one positional argument containing a LaTeX string, and everything else is in the code. That the version you get depends on the channel: the registry copy, the git copy, the rolling distribution package, and the floating branch on the Nix path are four different codebases at four different points. That the bindings for C and Python exist in the tree with no build instructions and no library target in the manifest, so they are separate crates you have to find. And that the optional terminal UI feature is off by default and appears nowhere in the readme.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. thatmagicalcat/txm on GitHub