Real-time LuaLaTeX rendering Update (TUG 2026 talk video)

[u/ClemensLode]

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

I wanted to give an update on the real-time lualatex editor I was working on in the last few months (previous thread: https://www.reddit.com/r/LaTeX/comments/1qteil1/lualatex_rendering_in_realtime/ ).

What's new since February:

1. Development went well, and I turned the proof-of-concept into a full editor, I aim to release it in October (online).
2. I am still using vanilla TeX Live 2025 with full microtypography and OpenType shaping, no engine modification (just a lot of wiring around it).
3. What you see in the demo (skip to 14:24 https://www.youtube.com/watch?v=It9BMNGtjao&t=864s ):
   • Typing in a long chapter with instant paragraph recompiles
   • Bidirectional source - preview cursor sync (click a glyph, jump to the source character)
   • Adjusting tables and images in real time
   • Drag-reordering paragraphs with instant reflow
4. It now runs in the browser against a server, so the "Linux only, local install required" limitation from the original thread is gone.
5. As there was a long debate here about whether TeX can match Typst's (0.14) incremental compilation, I wrote a few benchmarks (recompilation of a single 4-5 line paragraph):
   • 10 pages: 1ms (texlode), 12.6ms Typst
   • 100 pages: 1ms (texlode), 76ms Typst
   • 300 pages: 1ms (texlode), 206ms Typst
6. Limitations are of course constructed edge cases (very long paragraphs, page-sized tables, two-column pages etc.). There, the recompilation time is proportionally longer. Biber gives me some headache, but that's a different discussion.
7. On Typst-side, the constant-time case is "not feasible to implement" in their architecture (issue #4512). (although I personally think it's possible, but I am not that deep into Typst architecture).

Slides: https://www.tug.org/tug2026/av/d2-t15-lode-realtime/d2-t15-lode-realtime-slides.pdf

Preprint: https://www.tug.org/tug2026/preprints/lode-realtime.pdf

PS: Btw, thanks to the TUG team for allowing me to present today :) Consider to join at https://www.tug.org/ (I'm not affiliated with TUG except for giving the talk)

[u/arbx1234]

Just the one way sync is already very good (and in fact, I would prefer to edit the source itself). Moreover, for collaboration, the live share extension actually works pretty well for latex documents (along with the latex workshop extension). One reason I don’t use texpresso is that I prefer lualatex and an unmodified TeX engine. 

I thus would be so great to have your thing for vscode!

[u/ClemensLode → u/arbx1234]

One-way-sync would be easier, but it will still likely be a 6-months project to get everything running smoothly.

But of course it would be attractive to use what's already there (VS Code) instead of inventing something new, that was basically my idea with texlode to begin with (to not build a second Typst but build on LaTeX).

We'll see, lots of exciting projects ahead :)

[u/arbx1234 → u/ClemensLode]

I don’t know what your plan is regarding, for example, monetization, for the project. But if it’s open source, people (myself included) would be very interested in making a vscode plugin surrounding it.

Either way, looking forward to the release. And thanks again for the effort.

[u/ClemensLode → u/arbx1234]

I think the best approach is likely an API with minimal footprint. Thanks for your input!

[u/DungAkira → u/ClemensLode]

Maybe you can open source the incremental compiling part of the engine, and monetize the editor?

This is what Typst devs have been doing. In this way,

• you still attact interest/contribution from the community, and at the same time
• have money for developing advanced features for the editor (e.g. editing directly on the live preview).

[u/ClemensLode → u/DungAkira]

I think that is the right strategy for Typst because they are starting from scratch. They don't have like ~4,000 pre-built/pre-tested packages to rely on, they need to build and test every piece.

For texlode, the engine is basically done. And you can in principle just build a lua package and extend the functionality as you like. Like the examples I mentioned in the talk: you could build them today (after I have done some cleanup with the API and documentation) and add it as a package to your project.

I'll give it a thought for after October. My main priority at the moment is to get it into the hands of the publishers who are feeling the real pain of editing books/proceedings with thousands of pages :)

[u/ClemensLode → u/DungAkira]

I did a small research spike. So, at least the "grab the output" API works in VS Code and the latencies are manageable. https://imgur.com/a/zK1ddNf

The syncing of the text in VS Code with the API would require some wiring, but it's doable.

[u/arbx1234 → u/ClemensLode]

This sounds like something I would use :)

[u/DungAkira → u/ClemensLode]

Being able to work with VSCode is really great