4 ms·

"[I]t already broke backwards compatibility several times". There's your answer. I've got three decades worth of style files, personal macros, and workflow inv

"[I]t already broke backwards compatibility several times". There's your answer. I've got three decades worth of style files, personal macros, and workflow invested in the way I use LaTeX, numbering in the thousands of lines. In some communities, especially academia and most especially amongst mathematicians and engineers, that is a typical investment. Nothing that might require me to start overhauling that is going to get a moment's consideration until LaTeX stops working for me, and even then I'm probably going to try and maintain a bespoke TeX distro before I'd try to replace it. New and casual users of LaTeX should probably consider these alternatives (I've even considered moving over to LuaTeX because it would allow more automation, but I'd need a pretty longish period of reimplementation that I don't see becoming available soon.) But anyone who wants to move that community of long-time users, organizations and publications is going to need to address the problem of a significant user base that have been using effectively the same software for literally (and according to my students, unbelievably) decades. There's an analogous situation (or a continuation of this same situation, given the overlap in user base) for those who've invested decades in building a personal set of Emacs configuration files. Again, I've got thousands of lines of *.el files (many of them devoted to my idiosyncratic use of LaTeX) in my Emacs configuration. Of projects looking to replace the aged Elisp engine and create a modern implementation aren't going to get much consideration if it would mean replacing that (literally decades of) work in a different language. That's why I continue to be interested in Guile Emacs---less because of Guile (although I have no issues replacing Elisp with a modern Scheme), but because they've always made it clear that an ability to re-use Elisp configuration files was a primary design goal.

dkna 6y ago
> (I've even considered moving over to LuaTeX because it would allow more automation, but I'd need a pretty longish period of reimplementation that I don't see becoming available soon.) Good thing you didn't bother, because it's absolutely not worth it. I chose LuaTeX initially precisely because it seemed more convenient to write commands in Lua than in plain LaTeX, but it turned into a total nightmare. Issues crop up as soon as you try to do something with text that embeds LaTeX macros, and the errors you get are even more byzantine than the ones you'd get by writing "normal" LaTeX code. IMHO the very idea of embedding an external language into LaTeX is pointless, for the simple reason that LaTeX isn't markup, but code, and that it's pretty much impossible to parse it into a representation that makes sense and could be manipulated like, say, the HTML DOM. The only sane way to automate things is to write your documents in some language or markup that can be compiled to LaTeX, or to use a template engine.
- svat 6y ago
  > Good thing you didn't bother, because it's absolutely not worth it. The biggest thing LuaTeX gives you is variou hooks and access to various data structures used internally by the typesetting engine, so that you can work with them directly instead of having to do everything in a roundabout way through macro expansion. If all you need is text expansion then sure, just use TeX/LaTeX macros. (You mentioned "try to do something with text that embeds LaTeX macros"; I think working at the text level like that is a sign that your problem, or at least your solution, may not be a good fit for what LuaTeX gives.) Here are a couple of my answers where LuaTeX was valuable; you can find hundreds more (IMO) by others: - https://tex.stackexchange.com/a/379802 https://tex.stackexchange.com/a/379802 Avoid getting short words at line edges: Note that the macro-level solution runs into issues with \ref etc (just as you said about text that embed LaTeX macros), but the LuaTeX solution works perfectly in all cases - https://tex.stackexchange.com/a/401315 https://tex.stackexchange.com/a/401315 Letter-spacing - https://tex.stackexchange.com/a/403353 https://tex.stackexchange.com/a/403353 Typesetting on a poster with some image cut out - https://tex.stackexchange.com/a/416772 https://tex.stackexchange.com/a/416772 Doing text replacements based on TeX macro state (maybe this could be done without LuaTeX?) - https://tex.stackexchange.com/a/414013 https://tex.stackexchange.com/a/414013 Inserting random kerning I do completely agree with your recommendation of generating TeX/LaTeX if possible (and keeping the macros/LaTeX to a minimum).
Tor3 6y ago
That's exactly it - backwards compatibility. Back at the end of the eighties I was desperately trying to find a way to update documents on-site when I visited customers (and I would sometimes stay for weeks or months), where I couldn't use the word processing system we used at home. I needed something I could run locally, on the laptop (yes we had them) as well as on the target systems (servers). Tried a lot of stuff.. eventually found LaTeX, wrote software to convert our old documents to LaTeX, and a document class which created the same layout as the original (most LaTeX converters "hardcode" the layout [or at least used to, back then] - won't do, as my company changes the "template" now and then). Everything finally ok. I and colleagues could write documents on-site. A guy from another company had the same problem so I wrote a document class for his company's layout as well. So, I have these documents from way back, in LaTeX, and occasionally we have to produce them again. Sometimes we re-create them with a newer document class. Other times we extract chapters to be included in newer documents. If LaTeX had broken backwards compatibility it would be disastrous. I won't touch any replacement which doesn't guarantee backwards compatibility. However old the documents are.

dkna 6y ago

> (I've even considered moving over to LuaTeX because it would allow more automation, but I'd need a pretty longish period of reimplementation that I don't see becoming available soon.) Good thing you didn't bother, because it's absolutely not worth it. I chose LuaTeX initially precisely because it seemed more convenient to write commands in Lua than in plain LaTeX, but it turned into a total nightmare. Issues crop up as soon as you try to do something with text that embeds LaTeX macros, and the errors you get are even more byzantine than the ones you'd get by writing "normal" LaTeX code. IMHO the very idea of embedding an external language into LaTeX is pointless, for the simple reason that LaTeX isn't markup, but code, and that it's pretty much impossible to parse it into a representation that makes sense and could be manipulated like, say, the HTML DOM. The only sane way to automate things is to write your documents in some language or markup that can be compiled to LaTeX, or to use a template engine.

svat 6y ago
> Good thing you didn't bother, because it's absolutely not worth it. The biggest thing LuaTeX gives you is variou hooks and access to various data structures used internally by the typesetting engine, so that you can work with them directly instead of having to do everything in a roundabout way through macro expansion. If all you need is text expansion then sure, just use TeX/LaTeX macros. (You mentioned "try to do something with text that embeds LaTeX macros"; I think working at the text level like that is a sign that your problem, or at least your solution, may not be a good fit for what LuaTeX gives.) Here are a couple of my answers where LuaTeX was valuable; you can find hundreds more (IMO) by others: - https://tex.stackexchange.com/a/379802 https://tex.stackexchange.com/a/379802 Avoid getting short words at line edges: Note that the macro-level solution runs into issues with \ref etc (just as you said about text that embed LaTeX macros), but the LuaTeX solution works perfectly in all cases - https://tex.stackexchange.com/a/401315 https://tex.stackexchange.com/a/401315 Letter-spacing - https://tex.stackexchange.com/a/403353 https://tex.stackexchange.com/a/403353 Typesetting on a poster with some image cut out - https://tex.stackexchange.com/a/416772 https://tex.stackexchange.com/a/416772 Doing text replacements based on TeX macro state (maybe this could be done without LuaTeX?) - https://tex.stackexchange.com/a/414013 https://tex.stackexchange.com/a/414013 Inserting random kerning I do completely agree with your recommendation of generating TeX/LaTeX if possible (and keeping the macros/LaTeX to a minimum).

Tor3 6y ago

That's exactly it - backwards compatibility. Back at the end of the eighties I was desperately trying to find a way to update documents on-site when I visited customers (and I would sometimes stay for weeks or months), where I couldn't use the word processing system we used at home. I needed something I could run locally, on the laptop (yes we had them) as well as on the target systems (servers). Tried a lot of stuff.. eventually found LaTeX, wrote software to convert our old documents to LaTeX, and a document class which created the same layout as the original (most LaTeX converters "hardcode" the layout [or at least used to, back then] - won't do, as my company changes the "template" now and then). Everything finally ok. I and colleagues could write documents on-site. A guy from another company had the same problem so I wrote a document class for his company's layout as well. So, I have these documents from way back, in LaTeX, and occasionally we have to produce them again. Sometimes we re-create them with a newer document class. Other times we extract chapters to be included in newer documents. If LaTeX had broken backwards compatibility it would be disastrous. I won't touch any replacement which doesn't guarantee backwards compatibility. However old the documents are.