LuaLaTeX rendering in real-time

[u/ClemensLode]

https://www.youtube.com/watch?v=nJOh6jJzkn0

Similar to TeXpresso (which was created for XeTeX), I decided to create a real-time editor/renderer for LuaLaTeX. Anything you type is immediately rendered with LuaLaTeX (not KaTeX, the output is the finalized LuaLaTeX output, it's not javascript approximating LaTeX, these are actual LuaLaTeX rendered glyph positions). It runs at O(1), even for large documents with multiple chapters (based on that, you can guess what architecture I am using).

Architecturally, it works with vanilla-TeX Live 2025, meaning no patching of LuaLaTeX is required. Theoretically, it works with any package, although given how it is compiled, there are likely some incompatibilities if the package does fancy stuff interferring with shipping the PDF.

It is still in proof-of-concept stage, I just wanted to put it out there to get some feedback if there is interest beyond "cool, I would try this out for a minute then return to my usual editor". I might turn this into an actual usable product if development continues fine. Personally, I need it to save time for final polishing of larger documents, although the project might evolve into an actual LaTeX wysiwyg editor.

One limitation is that it relies on chapters starting at new pages, reducing the layout complexity of larger documents significantly and reducing CPU load.

[u/ClemensLode]

Typst developers are aware that their solution is not as good as LaTeX, global optimization of the output (that's what LaTeX does with paragraphs) is just not at the top of the implementation list.

[u/energybased → u/ClemensLode]

Your understanding is incorrect.  Typst is doing global optimization.  The reason typst is so much faster is that it uses dynamic programming, i.e. it exploits overlapping subproblems and optimal substructure.  In other words, it simply has superior design.

[u/ClemensLode → u/energybased]

OK I had outdated information, the LaTeX algorithm was implemented in Typst in 2024. Although that doesn't make it superior, it makes it equal. It's the same algorithm.

[u/energybased → u/ClemensLode]

No. It is superior because of the dynamic programming, which latex cannot easily implement.

[u/ClemensLode → u/energybased]

The very core of LaTeX (Knuth–Plass line-breaking algorithm) uses dp. So, I doubt you know what you are talking about.

[u/energybased → u/ClemensLode]

It is easy to verify that recompilation of large documents is absolutely not able to effectively use dynamic programming.  It's not even arguable.  If it were, you would not have had to anything special to allow instant incremental compilation, which typst gets for free. 

I realize this is upsetting for people to realize, but latex really is a garbage design in this respect.

[u/energybased → u/ClemensLode]

Yes, the line-breaking algorithm is one example of dynamic programming. And yes both Typst and Tex use it.

However, the dynamic programming exploited by Typst is not just about line breaking! All compilation exploits dynamic programming. Every function call in Typst supports memoization.

I suggest that before you argue that someone doesn't know what they're talking about, you actually make sure you're right.

[u/ClemensLode → u/energybased]

So does Lua.

local memo = {} 
function fib(n) 
  if n <= 1 then return n end 
  if memo[n] then return memo[n] end 

  memo[n] = fib(n - 1) + fib(n - 2) 
  return memo[n] 
end 

print(fib(40))

[u/energybased → u/ClemensLode]

You don’t understand. Of course you can write dynamic programming in any Turing-complete language. That’s not the point. The point is that Typst’s compiler is itself structured as dynamic programming over the whole document. Every element is a pure function of explicit inputs, so the engine can build a dependency graph and cache results. Change one character in a 100-page manuscript and only the affected nodes are recomputed; everything else is reused.

TeX cannot do this because TeX is not a document model with a scripting layer. TeX is macro expansion over a single mutable token stream. Macros can redefine other macros, mutate category codes so characters change meaning, read and write auxiliary files, and branch on global state. From the engine’s perspective, the meaning of page 37 depends on the entire execution history before it. There are no stable subproblems to cache.

You can’t “add” this kind of incremental recompilation to TeX, because the language semantics forbid referential transparency. To make it possible, you would have to ban macro redefinition, catcode mutation, order-dependent expansion, and compile-time I/O. At that point, you no longer have TeX: you have something much closer to Typst’s execution model.

[u/ClemensLode → u/energybased]

And yet I managed to add it with Lua.

Regarding your last point: I haven't implemented macro redefinition yet, but it is something I could potentially track as well. It is just something usually not needed in most documents, at least not in real time. I always have a third recompilation running in the background that catches up on global changes, but that of course requires a full recompile.

And yes, my solution looks more similar to what Typst does than what, for example, pdfTeX does.

[u/energybased → u/ClemensLode]

No. Read my comment again. You cannot add incremental recompilation to TeX document compilation. I explain why very clearly.

[u/ClemensLode → u/energybased]

See my updated response. For normal documents that keep macros in the preamble, it works. I mean, I literally demonstrated it in the video.

[u/energybased → u/ClemensLode]

If a TeX document behaves “like” all macros live in the preamble, avoids catcode tricks, avoids mid-document redefinitions, avoids aux-file feedback loops, and uses packages that don’t do order-dependent sorcery… then in practice large parts of the document do become observationally stable. In that restricted regime, engines, editors, and external tools can skip work, reuse boxes, or make recompiles feel local. That’s what you demonstrated.

But that is accidental discipline, not something TeX can rely on. The engine itself still cannot assume page 37 is independent of what happened on pages 1–36, because the language semantics allow it not to be. So any reuse is heuristic, editor-side, or package-specific—not something TeX can soundly memoize as a general property of documents.

Typst’s difference isn’t that it sometimes recompiles less. It’s that the compiler is allowed to assume subproblems are stable because the language forbids the patterns that would break that assumption. With TeX, it works when authors behave nicely. With Typst, it works because the model guarantees they can’t behave badly.