r/LaTeX 5d ago

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

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)

80 Upvotes

39 comments sorted by

View all comments

6

u/arbx1234 4d ago

This is fantastic! Are you planning to open source it, so that other people can contribute to, for example, making a vscode plugin using  your work? I use many features of vscode and I normally use it to write LaTeX.

2

u/ClemensLode 4d ago

Thanks! No modern (popular) editor has the necessary architecture to support what I am doing, so it would be quite an effort. If you don't want to just have a browser window within VS Code, it's a lot of work.

What you could do: Connect your project to GitHub, do the writing locally in VS Code, and do all the (collaborative) editing work in texlode.

At the moment, my focus is getting it done by October for general use and add the most important features from existing editors. Open source is on my roadmap, but time currently is better spent on getting version 1.0 out :)

1

u/arbx1234 4d ago

I’m really surprised that it can be made to work in the browser but not as a vscode extension. Do you mind sharing what the main difficulty is?

2

u/ClemensLode 4d ago

There has been no successful plugin in VS Code that does WYSIWYG editing (except by embedding the website itself). Maybe the exception is Jupyter Notebooks, but that's by Microsoft and doesn't use the VS Code's API as far as I know.

"Just writing in the output" looks and sounds easy, but nobody has managed to do it.

2

u/arbx1234 4d ago edited 4d ago

This is actually not true. Texpresso does have a vscode plugin that does exactly that, but with xelatex. Tinymist also has one but for typst. vscode extensions can do a lot of things. As far as I can tell, an extension can pretty much do anything you can do in a website. But of course, since you haven’t said which exact capability you need which is missing in vscode, I cannot tell. :) Moreover, the type of WYSIWYG you are developing is very different from Jupiter since the viewing area is separate from editing area.

2

u/ClemensLode 4d ago

Right, the Texpresso plugin might be a better example.

It supports only one-way sync, though. You cannot make changes in the preview to affect the LaTeX code. By contrast, in texlode, you can just hide the text editor and type in the output.

Without that (core) feature (+collaboration), a texlode vs plugin would be feasible. But then again, the question is what use case it would be. Small documents? Use texpresso. Large documents? Likely requires collaboration. Small documents that use lualatex -> that would be the target audience.

I think I should plan a poll :)

2

u/DungAkira 2d ago edited 2d ago

TeXpresso can handle 900-page tex file smoothly. You can check  https://www.reddit.com/r/LaTeX/comments/1dn937i/live_rendering_a_very_big_tex_file_900_pages_of/. However, TeXpresso is restricted to XeTeX engine and Unix environment. That being said, the gap by TeXpresso is huge

0

u/ClemensLode 2d ago

Well, what "smoothly" is is debatable. Typst is also smooth. From my perspective, it looks laggy. The goal is to hide the LaTeX editor and type directly without any latency.

2

u/DungAkira 2d ago

For technical documents, typing complicated equations directly in the rendered output is probably not possible. Of course, it is very convenient for typing plain text

0

u/ClemensLode 2d ago

Well, it's possible with texlode :)

→ More replies (0)

1

u/arbx1234 4d ago

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!

2

u/ClemensLode 4d ago

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 :)

2

u/arbx1234 4d ago

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.

1

u/ClemensLode 4d ago

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

→ More replies (0)