TeXpresso: live LaTeX rendering built on a patched XeTeX, MuPDF and an SDL viewer

The problem is the rebuild, not the typesetting

TeXpresso provides a live rendering experience when editing LaTeX documents in a supported editor: change something in the .tex file and the render window updates almost immediately with the change, and write something invalid and you get an error message immediately.

The README is explicit about why that matters. It can radically improve the LaTeX editing experience compared to the usual rebuild-and-wait-for-viewer-to-update experience, especially for large documents.

That framing is the right one. The expensive part of writing LaTeX in a conventional setup is not the typesetting itself, it is the loop: save, run the toolchain, wait for the PDF, find the viewer, check the page. For a short document the loop is short. For a long one, or a thesis, or a paper with many figures and bibliography, the loop is where the time goes, and most of it is spent compiling pages that did not change.

There is a second half to the feature, which is error reporting. The immediacy of the error message matters as much as the immediacy of the render, because in a conventional loop a LaTeX error often means reading a log file and finding the line. TeXpresso pushes the errors into the editor, and in the Emacs mode there is a dedicated command that opens a small window listing the warnings and errors on the current page.

The repository is careful to say that this is an early development phase, with changes and bug fixes happening frequently, and it points at CHANGELOG.md as the place to see them.

Four parts, and the engine is a patched XeTeX

The design section lists the parts of the system, and reading them explains the shape of the project.

First, a TeX engine that renders LaTeX documents into PDF. The project uses a custom version of the XeTeX engine, modified to interact with the TeXpresso driver. That is the deep part of the work: rather than watching the filesystem and re-running a stock engine, the engine itself is taught to cooperate with the driver, which is what makes incremental rendering possible rather than merely fast.

Second, a PDF renderer that renders PDF documents into images, using MuPDF. Third, a viewer that shows the rendered images and allows simple user commands, built with libSDL. And fourth, the driver program, which is where the live magic lives and whose sources are in this repository.

So the pipeline is: the driver asks the modified engine to typeset a portion of the document, the engine emits a PDF, MuPDF rasterises that PDF into images, and the viewer displays the images. The viewer never sees the PDF, which is why the viewer controls are the ones you would expect from an image viewer: panning, zooming, page fitting, cropping, dark mode.

The repository layout matches: src/ holds the sources, with subdirectories for common, frontend and dvi visible in the Makefile, and the mupdf-config.sh script at the root handles the MuPDF build configuration.

The cost of this design is that it is not a small program. It is a C project with a patched TeX engine, a PDF library and an SDL viewer, and the build has to produce both the driver and a texpresso-xetex helper, which the Emacs mode documentation says must sit in the same directory as the driver.

The driver holds the incremental state, which is what makes rollback possible

The driver is described as doing five things: talking to the editor to be notified of changes to the LaTeX document, maintaining an incremental view of the document and of the rendering process, talking to the LaTeX engine to re-render the modified portions of the document, and synchronising with the viewer.

The parenthetical list in that sentence is the interesting part: incrementality, rollback, and error recovery. Those are not features of a text editor plugin, they are features of the render pipeline, and they only make sense because the driver knows what the document looked like before the edit.

That knowledge is also what makes the error path work. When you type something invalid, the driver can re-render only the affected portion, notice that the engine failed, report the error into the editor, and keep the last good state on screen rather than blanking the window. The README's claim that you get an error message immediately implies the alternative, which is a viewer that stops updating or a log file to read.

The communication is bidirectional. The driver sends information between the editor and the renderer in both directions, and in particular it is possible to ask the editor to jump to a specific place in the LaTeX document by clicking on the viewer window, or conversely to refresh the viewer window to display the document at the editor position. The screencasts in the README name these two directions as synchronization from document to editor (SyncTeX backward) and from editor to document (SyncTeX forward).

The repository documents both sides of that conversation in EDITOR-PROTOCOL.md and SERVER-PROTOCOL.md, which is the right way to publish a protocol that third party editors are expected to implement.

Each editor gets its own mode, and the Neovim one lives elsewhere

Editor support is where the project is least uniform, and the README describes three different arrangements.

Emacs is the one in this repository. The source is in emacs/texpresso.el, loaded in Emacs with M-X load-file, and the file is also compatible with require. You start it with M-x texpresso, and the prompt lets you select the master or root TeX file. The mode then tries to start the texpresso command, and if that is not possible it opens the customise prompt for texpresso-binary so you can point it at the binary in your build directory. The README also notes that texpresso needs the texpresso-xetex helper, and that when copying them the two must end up in the same directory.

The mode is more than a launcher. M-x texpresso-display-output opens a small window listing the TeX warnings and errors on the current page, and M-x texpresso-next-page and M-x texpresso-previous-page move between pages without leaving Emacs.

Neovim support is in a separate repository, texpresso.vim, and it is not yet compatible with vanilla Vim, with patches welcome. The VS Code mode is being developed in texpresso-vscode by DominikPeters, who is credited in the README along with the marketplace listing.

So the pattern is that the protocol is in the main repository and the bindings are not, which is a sensible division for something that is still early. The cost is that each editor's mode is developed on its own cadence, and the Emacs mode, being the only one in-tree, is the one most likely to reflect the current protocol.

Tectonic by default, TeX Live as the fallback

The build output in the Makefile explains how the project finds a TeX distribution, and it is worth reading because the choice of default has consequences.

The message printed by a successful build says that TeXpresso detects package providers, TeXlive or Tectonic, by looking in PATH: it defaults to Tectonic if the tectonic command is available, and it falls back to TeXlive if the kpsewhich command is available. A provider can be selected manually by passing the -texlive or -tectonic flags.

The same message warns that when using tectonic, the first time launch needs to download many files and can be slow, and it points at a make fill-tectonic-cache target to speed the process up. The reason is visible in the two example invocations that follow, which run a test document through the driver directly:

	@echo "# TeXpresso detects package providers (TeXlive or Tectonic) by looking in PATH:"
	@echo "# - it defaults to Tectonic if the 'tectonic' command is available"
	@echo "# - it falls back to TeXlive if the 'kpsewhich' command is available"

For a user, the practical difference is that a Tectonic based setup downloads its packages on demand and needs a warm cache, while a TeX Live setup uses an already installed distribution with everything on disk. On a machine with a full TeX Live installation, the fallback path is the faster one, and the -texlive flag makes that explicit.

The macOS packaging has its own target, make macos-app, which additionally produces build/TeXpresso.app, a bundle whose dock icon renders at the correct HIG size. You launch it with open build/TeXpresso.app --args /abs/path.tex, or point your editor at build/TeXpresso.app/Contents/MacOS/texpresso. The plain build/texpresso binary falls back to the default macOS binary icon.

The project has been tested on Linux and macOS and should work with both AMD64 and Apple Silicon architectures, with dependency and build instructions in INSTALL.md.

The viewer is a page viewer, and the README admits the gap

The viewer controls are listed in full, which is unusual and useful, because they tell you exactly what the viewer is.

The keyboard set covers page changes with the arrow keys, movement within a page, hjkl panning with shift for faster movement, space and b for next and previous page like less, p to fit to page, w to fit to width, c to toggle crop borders, q to quit, i to invert for dark mode and capital I to toggle theming, t to toggle stay-on-top so TeXpresso stays above the editor window, capital B to toggle window borders, plus and minus to zoom, F5, f and F11 to toggle fullscreen presentation and ESC to exit full screen. The mouse set is click to select text in the window, control+click to pan, the wheel to scroll and control+wheel to zoom.

One line is a TODO rather than a feature: click selects text in the window, with a note that moving the Emacs buffer with SyncTeX is still to do. That is the missing half of the bidirectional story, and it explains why the Emacs mode has texpresso-display-output rather than a general text selection bridge.

The absence of any PDF text selection, search or copy is the real constraint. What you get is a rasterised image of the page, which is enough to look at the typeset output and to click through to the source, and is not enough to read a PDF.

The project is MIT licensed, with the LICENSE file at the root of the repository, there are no GitHub releases, and the last push to the repository was on 2026-08-11 with the repository not archived.

Editorial conclusion

TeXpresso fits a LaTeX author who edits large documents and is slowed down by the rebuild and wait cycle, and who is comfortable building a C project with a patched TeX engine. It does not fit a Windows user, since the project has been tested on Linux and macOS, and it does not fit a workflow that needs the full PDF toolchain, because the viewer is a rasterised image view rather than a PDF reader. Before adopting it, read CHANGELOG.md, since the project states that changes and bug fixes are happening frequently.

Frequently asked questions

Official sources

1. Issues
2. let-def/texpresso on GitHub
3. License: MIT
4. README