LaTeX code is not edited directly by LyX, though: you need to import and export it.
Sadly it never took off. These days I would choose Jypter notebooks or markdown files with embedded LaTeX math, which also gives you instant previews.
LyX uses .lyx files but is able to import and output .tex files - and the fact that you remember it as "just LaTeX" means the integration is good enough.
From their Features Poll[0] page:
"By a general consensus of the developers, using LaTeX as a native format of LyX is no option. Query the lyx-devel archieves for details."
On the "final" step looking for produced pdf issues I have to recompile sometimes, mostly on tables/TiKz stuff, but the little build time does not disturb me... The only a bit annoying part is the "like-a-lisp" default interaction mode in case of error finding it essentially useless since I have to correct the sources anyway.
But for publishing (especially book/e-book publishing, which always requires a lot of fiddling to get perfect!), it's really, really useful. My current workflow is TeXStudio with a lot of F5ing, which works pretty well...but that final run-through would be so much faster if I could see changes as they're made.
I've used this config when writing papers, etc, and it works flawlessly.
As for diffs (what has changed), it is also possible to color code the changes too.
I can't recall how I configured viscose, but it was a fairly standard approach.
In particular, things like ToC generation, figure and formula numbering and back- and forward-referencing?
I was always intrigued by creating a TeX-like typesetting language that has similar properties, but I was always put off by having to reimplement the gist of the typesetting engine (entire box model and font support, especially math typesetting).
It'd also be nice to support more advanced data structures other than 255 registers to allow moving away from external file use in all the multi-pass processing features.
While I was heavily involved with typesetting in TeX, I mostly had my own PlainTeX macros for all of the above stuff (including syntax highlighted code listings with cross-page continuation logic), but that was 25 years ago when Unicode support was mostly very rudimentary: I don't have a need for a typesetting engine of the sort today, though I would love to switch my blog into a more semantic language with nice support for maths and programming that would allow instant print previews (and printouts) with TeX like formatting quality.
I would also love it if you open source your stuff, but I understand that you are likely trying to build a business around this too.
Multi-pass: We also do multiple passes, but thanks to comemo we can reuse most of the stuff from previous passes. The change tracking detects if a dependency on some other part of the document requires updating. This doesn't require file writing and reading; Typst has a built-in user-facing interface for these kinds of tasks.
Data structures: Typst has typical data types you'd expect from a modern programming language and also typical imperative control flow like if, for, and while. What's a bit non-standard is that Typst enforces that all user-defined functions are pure (else we'd break incremental).
Open Source: We do plan to open source the Typst compiler and CLI! Just not the collaborative web app.
1) Store all actions by a user as as an array of add/remove commands (where a change is remove+add).
2) Whenever you need to re-render take the cached version from the last render and perform the new add/remove commands that happened since the last render.
3) Cache the result for the next render and repeat.
That seems like a great approach for a simple transformation pipeline. For a full compiler it seems harder to pull off. That's the great thing about memorization: It more or less let's you write the compiler like you would have done without it.
TiddlyWiki[1] with KaTeX plugin[2] does that. Or any project that uses KaTeX for that matter.
Next?
The app allows you to see what you're writing as soon as you click preview (no auto-reloads because I probably won't be able to handle the traffic) and the API lets me generate a PDF as soon as I push my resume to GitHub:
curl --fail --show-error -X 'POST' 'https://latexresume.com/api/v1/resume' -F 'file=@resume.tex' --output resume.pdf
