LaTeX3: Programming in LaTeX with Ease (2020)
alanshawn.com
alanshawn.com
If you're interested in this (and already know LaTeX), consider reading the full expl3 design document:
https://texdoc.org/serve/expl3/0
I don't know if LaTeX is what I'll be writing in the future (at least, hopefully not in its current incarnation). I'm keeping my eyes open for a language with a similar design philosophy, but, frankly, it's a monumental effort to write anything similar, let alone build the community around it (packages, but also journal styles, etc.).
what helped you get over this curve?
Just creating many small proof of concept thingies, and slowly building them out. I did this until I was comfortable enough. After 40 hours of learning it, I was about 90% as fast as typing in MS Word. There was one difference though, LaTeX made me way more structured because I commented at every paragraph what the intention of that paragraph was. So my writing became way more focused.
I learned a lot when bending it. And then I again learned a lot when I began to have collaborators whose LaTeX I could look at. And one more time when I began to put together LaTeX for publishing.
It was painful for about a week, uncomfortable for about a month, fine for about a year, great for the next five, and as fluid as speaking afterward. I'd call that the typical low-level tool learning trajectory.
A good answer I didn't thought at the time but that will aplly equally here: curiosity powering the will to read more documentation.
~~~
The first stage was to learn from the LaTeX Tutorial website, which includes a detailed tutorial with no paywall [1]. I paid the closest attention to tutorials 00 to 05 for the core functionality, then skimmed the rest of the tutorial, as I would only rarely use the remaining features. (For tables, even after gaining a general familiarity with how the tabular environment work, I still found it faster to use the Tables Generator website [2], which was also recommended by my instructor.)
I then gained practice using TeXstudio as the software to convert LaTeX code into PDFs (as I preferred an offline program), though my professor and most of my fellow students used Overleaf as an online editor. However, I found that I spent a lot of time transcribing handwritten problem sets into LaTeX documents on TeXstudio and Overleaf, and searched for a faster and more pleasant method (in particular, I found that there was a significant delay in my experience when compiling LaTeX code to a PDF with TeXstudio and Overleaf).
~~~
Speed and ease-of-use were therefore my sources of my motivation for learning how to use Vim with LaTeX, though you should have enough knowledge for effectively writing LaTeX documents with just the information from the LaTeX tutorial website. I was also motivated due to my curiosity about Vim in general, from past discussions on the text editor in an xkcd comic and various forum discussions.
To begin the learning process for Vim, I completed the default-installed tutorial “vimtutor” (also motivated because I was curious about Vim in general, from past discussions on the text editor in an xkcd comic and various forum discussions) over a weekend day. Crucially, I followed most of the advice from a Hacker Noon article [3] about more efficient ways to scroll up and down. I then edited the .vimrc config file to allow for using the cursor for highlighting text to keep things simple, using most of the default configurations for Neovim.
Then, I roughly followed E.J. Mastnak's guide at [4] to get set up, over the course of another weekend day. After some troubleshooting with the configuration, I finally got the setup to work, and I’ve happily been using Vim with LaTeX since then. Since the process reduced the friction to compile LaTeX code to a PDF, I compiled my document more often, so I could catch errors early and often (I rarely spend time troubleshooting and debugging LaTeX code now, since I now fix errors shortly very after they appear, as I compile the document every few lines of code or so).
The main major drawback of using Vim and LaTeX was that I followed the advice to enable autocompletion with snippets (e.g. typing “AA” automatically types in “\forall”) via the the UltiSnips software, which would make substitutions without an audible notification (in contrast to other software that I use to make snippets outside of Vim, that would make an audible ping before a substitution). That led to some significant typos in an early assignment I submitted, and I since learned from my mistake to be far more careful when using Vim with LaTeX for enabling snippets. However, snippets also functioned as a nice learning tool, as I would learn through practice what some basic commands would be, through the auto-substitution (for example, I’ve now easily remembered through exposure that <= is written as `\leq`) in LaTeX.
~~~
To conclude, you can use free tutorials to learn the basics of LaTeX, and use Overleaf and TeXstudio to practice. For additional speed and pleasantness, you can spend a couple focused weekend days (or possibly more) to learn how to use Vim with LaTeX following another free guide. Then, you can reinforce your learning through regular practice (in my experience, my regular practice was necessary due to requirements of a math course—if your work or education similarly requires LaTeX, a real-life necessity is a great motivator for practicing document production with LaTeX).
[1] https://latex-tutorial.com/tutorials/
[2] https://www.tablesgenerator.com
[3] https://hackernoon.com/learning-vim-what-i-wish-i-knew-b5dca...
[4] https://www.ejmastnak.com/tutorials/vim-latex/intro/
[5] https://github.com/gillescastel/latex-snippets/blob/master/t...
The only issue is the ecosystem for specialized fields with their own typesetting requirements.
But I’m all for anything that is easier to debug than Latex.
That said I feel it will never truly compete with LaTeX in terms of adoption. LaTex is like SQL — it’s long in the tooth and has some minor design issues but represents something very fundamental that defies reinvention.
\section{Introduction}{
.
.
.
}[section[Introduction][...]]
For example, how I'm supposed to use a markdown language that doesn't have a tikz-like library? Sure you can still write commutative diagram but that's not all tikz does.
I noticed it has a scripting language built in, but how might one use already made scripts in another language? For example, if I already have a make_plot.py script, can I just call it instead of rewriting everything in this new scripting language? It seems that this functionality would be absolutely crucial for adoption, but there's nothing but complaining and disagreement on the issue raised on this in the GitHub.
Do you use it on a daily basis? Any problems I should be aware of? I see quite a few open issues - do they actually matter?
Though I don't have firsthand experience in formatting documents to meet publication standards, the flexibility it offers seems promising for such applications.
My sincere hope is that it garners the recognition it truly deserves, and that significant publications in the future will embrace it, rolling out official templates directly in typst.
The font subsetting seems to be suboptimal. I had small documents that were a megabyte when they should have been a few kilobytes. This however can be fixed with PDF tools.
Specifically, TeX still works well today because of deliberate choices to not break things. He is well aware of modern techniques for many of the things that people complain about. He likes that he can still build every one of his documents today, with no concerns over things having "moved on to better ways."
Markdown was created in 2004. From the creator:
> ... the single biggest source of inspiration for Markdown’s syntax is the format of plain text email.
Email goes back to 1965, though I suspect Markdown's influence stems from the more widely adopted email usage of the 1990s. I'm not sure if I'd call Markdown "modern". Quite popular though!
> Part of LaTeX's success was the absolutely beautiful documents it can make with nothing but a personal computer.
I'd say that was TeX's success, with LaTeX bolted on later to greatly improve TeX's extensibility. Keep in mind, there are a number of TeX-centric implementations beyond LaTeX. For example, my fork of NTS, called KeenType, is a pure Java version of TeX that can typeset beautifully and has at its core Knuth's original TeX files. I specifically avoided integrating LaTeX.
https://github.com/DaveJarvis/KeenType/tree/main/tex/src/mai...
My Markdown text editor, KeenWrite, uses KeenType to preview math in documents.
https://github.com/DaveJarvis/KeenWrite/blob/main/docs/scree...
When exporting to PDF, KeenWrite uses ConTeXt to typeset the final document. ConTeXt being another TeX-based system. This is the reason why KeenWrite only uses TeX: to give users the ability to choose what TeX flavour to use for typesetting the PDF.
In almost 4 decades of typesetting, I've had a chapter come out exactly right, requiring no adjustment exactly _once_ (fastest 40 minutes of my life) --- the usual approach is after:
- importing the text and all the images, paging everything with the defaults
one has to:
- check the last page --- is it reasonably full? is the page which it is ending on acceptable --- would it be better to gain or lose a page?
- from the beginning, check each image/table --- where do they fall relative to the first reference? What needs to move to what page? Make gross adjustments to make that happen where possible (resizing images/tables/tweaking placement, if the book design allows, change image/table type/appearance to adjust things
- see where one falls at the end of the chapter --- last page full enough? Would it be desirable to gain/lose a page?
- go back to the beginning, begin fine tuning each page/spread --- are there any paragraphs which don't look nice? (setting too tight/loose, rivers, stacks, &c., adjust as needed), do the bottom lines line up? adjust paragraph specs/image size to make them line up (keeping in mind if one wants to gain/lose a page) --- do this for each page/spread
- check the last page --- repeat any of the above adjustments as necessary --- sometimes, while one might want to gain a page, a tighter setting losing a page looks sufficiently better that it's worth un-doing all the tweaking an re-setting thus
I hate this language with a passion. The design choices may have made sense in the 80s when 128 kB of RAM was considered high-end, "tooling" was an unknown term, and modern parser design an academic matter. If I have to read "Runaway argument" and sift through a hundred lines of log to find an error again I will have a stroke.
LaTeX3? I have great admiration for the work they've done. But they have made at least two mistakes.
1. The fundamental mistake of insisting on backwards compatibility. Latex is choke-full of historical cruft. How many times have I read things to the effect of:
"Oh, you want an inline list? And you're using the inline-list package?! You poor fool! You should be using inllst3 with the xtabl option. Holy shit, you're using hyperref too?? (Spoiler alert: everyone uses fucking hyperref.) You cretin. Well, you should load these three other packages in this specific order. Then paste these esoteric commands:
\makeatletter\def\tbl@lst#1{\hy@tbl\vphantom{#2}#1\strut\lbl@lst##&!@\makeatother
No, I'm not going to explain what the commands do. Figure it out. Documentation? In the texbook. It's not online, you expect Knuth to work for free? Go buy it on amazon, you freeloader."
Don't get me started on how to get arXiv to accept your biblatex files.
Throw all this into the trash and start anew. There's no other good way forward.
2. The superficial on creating a theoretically beautiful and consistent syntax that is designed for computers, not for humans.
Seriously, go to the authors' website, the "LaTeX3 examples" page https://www.alanshawn.com/tech/2020/05/25/latex-3.html#examp.... Here's how you multiply a length by a float and store it somewhere.
\cs_generate_variant:Nn \fp_set:Nn {Nx}
% #1: input name
% #2: output name
% #3: factor
\cs_set:Npn \__multiply_length:NNn #1#2#3 {
\fp_set:Nx \l_tmpa_fp {\dim_to_fp:n {#1}}
\fp_set:Nx \l_tmpb_fp {\l_tmpa_fp * #3}
\dim_set:Nx \l_tmpa_dim {\fp_to_dim:n {\l_tmpb_fp}}
\dim_set_eq:NN #2 \l_tmpa_dim
}
I've started writing stuff with msword and I honestly like it better. Even UTN28 kind of makes sense. Yes, I'm expecting a fight after writing this.
LaTeX does not feel like a programming language. It is first and foremost designed as a macro language, which is nice for writing text, not that much for implementing algorithms.
I quite like what lualatex is doing, including a lua interpreter to add some simple code to your document, and make writing packages easier. I admit I haven't used yet, being afraid of compatibility issues. I know a friend also uses a package to interoperate with python.
This doesn't completely solve my main gripes with LaTeX though, including the slow compilation speed (while 95% could be cached), and the bad error messages, as well as the brittleness of the programming part (I ended up typesetting my manuscript in 9pt because I forgot a comma after the previous documentclass argument).
And the adoption is slow, packages stick to the most compatible baseline.
Maybe the future really is to restrict LaTeX use to minor parts of the text, like Markdown (pandoc?). But there's still some value in having a plugin system that doesn't require additional dependencies.
OTOH, I’m of sure to what extent this slow compilation is actually just a symptom of something bad in the language. I’ve included a bunch of packages in my file, which probably slow down compilation, due to the fact that they have to deal with ancient cruft.
At this point I will try anything else.
TeXmacs is another option. No idea if it's any good - I always ignored it based on the name because it sounds like some kind of Emacs based Latex editor but it's actually nothing to do with Emacs and not based on Latex. Terrible name. Might be good though.
The reason I say this is because every document I produce in the TeX family needs to be tweaked slightly depending on the text and data I compile with it, or else it either won't compile or something will get visually screwed up. At least with strong typing I can get useful error messages and better control of the behavior throughout the whole document.
- tags/formatting large --> small, document --> paragraph --> character-level
- content which is tagged
I find that if one just finds all the "right" packages and uses appropriate markup it mostly "just works", if one then adds a pair of packages:
- one which defines all the additional markup beyond the initial author markup as empty commands
- a second which redefines all those commands to achieve the formatting
Oh, right, you want to be able to comment on it in a nice way, and not everyone in the group is super familiar with git, so you can just use a self hosted overleaf for the comments. Oh, that's actually for latex, so just use markdown->latex->pdf, and now everyone can comment easily.
Oh shoot, nevermind, the latex comments aren't the original source, so the comments won't sync right. Easy, just make a custom script to make the comments as part of a git commit to the repo with the markdown, in a format that can re-apply the comments when they're pulled and synced with the latex. Sure, that will work :/.
You want easy version control of image placement too? No problem, markdown can work with css as well, so just add that into your markdown file wherever needed.
This is so much easier, right?
Right?
https://dave.autonoma.ca/blog/2019/05/22/typesetting-markdow...
Later, I wrote KeenWrite, which is both a GUI and command-line application for converting Markdown documents to PDF. KeenWrite separates the content layer from the presentation layer and uses ConTeXt to do so. I've tried to keep my software backwards compatible with pandoc.
Nowadays, I rather use a WYSIWYG editor, even if it takes a bit longer to type equations (when needed).
Give TeXmacs a try. You don't need to suffer between Word and LaTeX :)
Trust me, writing code is not the issue with latex. I've written C++ code for embedded MCUs. I've taught python to undergrads. The pain does not even compare.
Don't let the name fool you. TeXmacs won't make you write (La)TeX. You'll get tables that work, images that work, hyperlinks that work, running headers that work, math that works, kerning that words, hyphenation and justification that work. (From math forward are major failure points in Word)
This is a moot point if most people are reluctant to pick up latex and those who do are greeted by often unreadable, esoteric code that produces error messages such as "badness". This is the problem with latex and its derivatives, not their output.
Basically you get all the advantages of Word, all the advantages of (La)TeX, and none of the disadvantages of either.
The sad part of Word is that even professionals mess it up constantly, because you have many ways to reach the same goal, and that every addition affects the whole document, or in some fortunate cases only the part till the next page break. But silent breakage is the worst, as is quite clear from any kind of programming background. Imo, Word just doesn’t scale due to this.
You're still using (mostly the same) plain old LaTeX 2e with pdftex, xetex, and luatex (pdflatex, xelatex, and lualatex). Those are just 3 different engines for Knuth's original tex. As far as I know, some parts of all 3 are written in WEB (which is a language that persists mostly because Knuth's TeX is written in it).