November 2026

For LaTeX fragments to feel like an ambient part of the Org buffer, there are a few crucial things we need to get right. One of the most important is making sure that they never interrupt your interaction with the buffer.

It is not at all pleasant for Emacs to freeze when opening a buffer, or with a package like org-fragtog, while typing. To prevent this from happening we’ve split the rendering pipeline up and execute every stage of it asynchronously, with bookkeeping to make sure we put the right overlay images in the right place, even when the buffer’s changed during fragment generation.

Karthik and I have done an extensive amount of profiling and tuning to minimise pauses during the pipeline to make sure you never feel Emacs hitch during preview generation.

Now, while it’s nice for fragment previews to no longer hold up interacting with your Org buffer, it’s also nice to see them quickly. We now go to great lengths to minimise the time it takes to see previews placed in the buffer. Details aside, a moderately mathematical document holding 660 fragments that used to take two and a half minutes to load now takes two seconds. In fact, the difference is even more pronounced as we order fragment generation based on the current buffer position, so you see nearby fragments stream in first.

This new pipeline is built using org-async, a small declarative process-chaining library introduced as part of the patch set.

We also make use of org-persist to cache fragments, which means that this ∼70× performance improvement is the worst case. The fragments in a re-opened buffer should appear near-instantly (see org-latex-preview-cache and adjust org-latex-preview-persist-expiry to change how long old previews are kept for).

A particular pet peeve of mine has been that previewed fragments never quite looked at home in the Org buffer. The sizing was always a bit off, the positioning not quite right. We now collect the sizing information needed to harmonise the size of fragments’ images with the buffer’s text, producing perfect baseline alignment and matched sizing (depending on your LaTeX/Emacs font pairing, a minor correction may be needed; see org-latex-preview-appearance-options).

If you’re wondering how much work this took to calibrate, just know that there’s an unexplained 1.659393% correction factor needed to align the calculated and observed sizing.

These fragments also follow the text scale and the current theme’s foreground colour, helping them feel like part of the buffer’s text.

As part of the reworked preview engine, we wanted to subsume the functionality of org-fragtog, a package for intelligently toggling previews as you move into and out of them. This is provided with a new minor mode, org-latex-preview-mode.

Thanks to the speed of the new pipeline, we realised that we could not just re-render an edited fragment rapidly, but re-render it during editing. When org-latex-preview-mode-display-live is non-nil, the preview mode also shows live-updating previews.

This can be particularly helpful for catching mistakes early, since we now also indicate errors by applying the error face and putting the compilation log for the fragment in a tooltip.

Previously, every numbered equation was compiled in isolation, and so rendered as (1). With the work we’ve done on tracking fragments across the buffer, I couldn’t resist the temptation to make equation numbering actually correspond to equation order.

The improvements in preview generation speed and sizing have been carried through to the export backends. In particular, html and odt (via a new ox-mathml library) exports get the same numbered, aligned, and coloured images.

While I said earlier that I didn’t want to make any compromises in the preview experience, unfortunately it hasn’t been possible to enable that experience in all configurations. In particular:

• Live previews need \\(...\\) / \\[...\\], since $ is ambiguous while typing
• XeLaTeX and LuaLaTeX can’t use precompiled preambles, so they’re noticeably slower than pdfLaTeX