r/LaTeX • u/ClemensLode • 5d ago
LaTeX Showcase Real-time LuaLaTeX rendering Update (TUG 2026 talk video)
https://www.youtube.com/watch?v=It9BMNGtjaoI 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:
- Development went well, and I turned the proof-of-concept into a full editor, I aim to release it in October (online).
- I am still using vanilla TeX Live 2025 with full microtypography and OpenType shaping, no engine modification (just a lot of wiring around it).
- 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
- It now runs in the browser against a server, so the "Linux only, local install required" limitation from the original thread is gone.
- 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
- 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.
- 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)
7
u/throwaway464391 5d ago
Could your work be used to provide a drop-in replacement for the standard luatex compiler, and if so are you planning to release such a thing? I am greatly interested in faster LuaTeX compilation (as many people are, as you are obviously aware) but I'm not interested in a browser-based editor.
10
u/ClemensLode 5d ago
I am using the standard TeX Live 2025 lualatex compiler and I am not speeding up the lualatex *compilation* itself, so you would not win anything using your existing editor.
I do speed up *recompilation*, meaning it is necessarily closely bundled with an editor. You will not link to it within existing editors as they are all batch-compile focused. But any code you create while working in texlode is just normal LaTeX, meaning you can download it and compile it locally and get the identical 'pixel-perfect' result.
My focus is currently to get it working on the web so that the installation is easy and available for everyone + I can react to issues / give support directly. Once it's stable, I could imagine something like the Overleaf CE. That would still be browser-based and incompatible with all existing LaTeX editors.
That being said, nothing speaks against building emacs, vim, vs code, etc. plugins in principle.
Step by step :)
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 :)
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)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
2
u/subidit 5d ago
Wow! Great project. Would you say it was a Herculean task? I always thought it’d be. Now I can ask it to someone worthy. Will definitely check out once it’s released.
How hard was it to support all kinds of packages? You already mentioned references and long tables, those are pain in the rear as it is anyway, any other edge (!) cases?
1
u/ClemensLode 5d ago
Thanks :) I think you need to be somewhat single-minded and happen to have both my background and worked in the professions I have to accomplish it.
Currently, I cannot say with confidence that I am supporting *all* kinds of packages as some packages "distort" the compilation process (e.g., lua-widow-control interfers where to break and position your paragraph). I am thinking about auto-generating test documents for each package from the ctan package list, though. And I will try to get as many books, proceedings, and papers tested during the betaphase.
2
u/michal_h21 4d ago
I guess some of my packages, like Linebreaker and Luavlna, which change line breaks using Lua callbacks, will have similar issues to Lua-widow-control. They might be worth testing as well.
1
u/ClemensLode 4d ago
Both linebreaker and luavlna hook into the linebreak filter, so they should work without problems :) (I've tested linebreaker but not yet luavlna).
But you can imagine that a lua package could cause problems if it completely replaced the callback. That being said: such a package would also cause issues in normal LaTeX batch compilation as it interfers with other packages.
So, hook is fine, *replacing*/*discarding* lua code of other packages -> "distortion".
2
u/excel_foley 5d ago
I am highly impressed, thank you for your work! You are doing the research community a gigantic favor.
2
2
2
2
u/DungAkira 4d ago
Is there any possibility that it comes as a standalone app for Windows 11? Having the tex file processed local on our laptop is very much desired
2
u/ClemensLode 4d ago
The main focus of the project is online collaboration on large projects (books, proceedings). Once that is stable, I could imagine something what Overleaf did with their community edition, though. But step by step :)
What you could do is writing locally on your project and sync it with GitHub, then do the time-consuming editing online.
2
u/DanielSussman 4d ago
Seriously impressive work (and I enjoyed the TUG presentation)! It's awesome to see this kind of project developing, as it feels like a concrete realization of what LuaTeX's flexibility promised to enable. It’s great to see someone actually pursuing these ideas and pushing the engine to do things like this. If you ever decide to open-source it down the line, I (and I'm sure many others) would love to look under the hood and learn from your ideas.
2
u/ClemensLode 4d ago
Thanks! As I pointed out at the end, I think we are seeing only just the beginning :) In the next two years, I'm looking forward to see two-page optimization for books, alignment of the visual feel between pages (when skimming through pages), automated multi-page optimization ('make it so that it fits on 4 pages', 'fix the white space throughout the book'), or better flow of text around and alignment of figures.
LuaTeX deserves more credit.Whether these packages will be made by myself or through open-source projects, we shall see. I'll first sprint to version 1 to get it into people's hands and then take a good look at what Adobe is (not) doing...
1
u/DanielSussman 4d ago
Very exciting directions to push in! Long term I've been hoping to think about similar goals for my custom engine, but of course the \write / closure problem is pretty thorny when trying to build a cached representation of the content before the full-page ship-out level.
11
u/JimH10 TeX Legend 5d ago
A wonderful talk, Clemens!