u/ClemensLode

I made a short reel showing where texlode (a real-time WYSIWYG LaTeX editor for very long documents) stands right now.

Since the TUG talk in July, I have spent most of the time optimizing CPU and RAM usage and stress-testing the engine against the documents you sent me. The Kerr paper at https://arxiv.org/abs/1711.07597 was especially useful due to the number of equations. Feel free to send my other examples you would like me to try (ideally under a free license).

Timeline:

• Oct 7-11: Try the editor yourself at the Frankfurt Book Fair, Hall 4.1, booth F97.
• Mid October: The beta starts on EU servers, I invite you to join the waiting list at texlode.com
• Mid November: If all goes well, servers in North America and Asia will follow to reduce latency.

A local version is not on the roadmap, but I am evaluating an API that would allow browser or local plugins (for example, for VS Code).

What is left to do is further tuning the server tiers.

• My LaTeX book (300 pages) loads in the free tier, barely.
• The Kerr paper (800 pages, heavy math) sits comfortably in the standard tier.
• Large proceedings (with thousands of papers) might need a larger machine.

Client-side, it will work on weaker machines as I do not off-load compilation to the client (although I am observing the WebAssembly space), so you can use it on-the-go and review/comment/edit the output in print-quality even on a mobile phone.

I also have new/corrected benchmark numbers (see https://github.com/texlode/luatex-benchmark/issues/1 ), which I will update again in October.

Limitations: texlode is heavily optimized for books, monographs, and proceedings using KOMA document classes. Support for custom papers and other document classes is in progress but will not be ready at launch. Likewise, if you develop LaTeX packages, you will run into walls: texlode is built for authors, not package developers. That being said, especially because you get real-time output, it might be interesting for the development/debugging of some packages. Let me know if you want me to try out yours. As mentioned in my TUG talk, the next step here would be to develop/adapt packages to make use of the real-time aspect for some chapter-wide optimizations of float positioning, better runt/river detection, visual two-page optimization etc.

Disclaimer: While I am evaluating adding LLM support to texlode to improve typesetting, texlode is LLM-free for now (including the docx/idml import).

Feel free to ask questions, I will try to address them over the next 2 weeks!

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)

I keep hearing the idea of IT consultants that with all the vibe-coding, a new industry opens: fixing vibe-coded codebases.

Is that just a pipe-dream or do you see real potential there? It sounds logical on paper, but how does the actual market look like? I could imagine a number of problems why that would not work:

- The creator (company) already decided not to spend money on the product and use AI instead.
- The person managing the project using claude code is likely not experienced enough to even imagine how an external expert could help (instead, they hope for a better model like Fable to fix everything).
- I have yet to see a significant uptick of successful vibe coded projects (i.e. that managed to get into production).

There are a few exceptions, like certain relatively simple apps that landed in the right market niche by accident or because the person using Claude Code has a background in marketing/product design, and those apps might need help with scaling (servers etc.), but I can imagine that market is small.

What do you think?