LaTeX3 Automatic Labels for Fun and No Profit(commutative.xyz) |
LaTeX3 Automatic Labels for Fun and No Profit(commutative.xyz) |
Well here's the process I went through in the last few years:
I found out about LuaTeX, saw it was supposed to replace pdfTeX and thought the future of TeX was bright.
Then I saw the continued efforts in LaTeX3 and thought that was weird and wasteful: code now looks even worse with all \ExplSyntaxOn ... \ExplSyntaxOff sections and the new command syntax like \exp_args:Ne. If you're going to have a mix of two languages anyway, it makes much more sense for the second language to be a a minimal but real programming language like Lua.
Then the LuaTeX devs moved their efforts to LuaMetaTeX and I found myself scratching my head.
Then I spent some time with typst. Now I don't care what happens in TeX land... The experience with typst is incomparably better, and the pace of development is high in both the core language and the ecosystem. Features that took a decade to be fleshed out in LaTeX are sprouting like mushrooms in typst. It's not a fair fight.
The author is a PhD student that has been using LaTeX heavily for 10 years. But what should a new student use, and why? When the only reason to choose LaTeX is old colleagues and gatekeeping publishers, I know it's a matter of time.
Sadly its more than that. Will we be able to compile a typst file made today in 10 years? I have to do that regularly with latex. Will everybody one collaborates with also use typst? Very unlikely. A new PhD student may find it beneficial to write papers with someone who only uses latex. then why bother with typst? (and I really want typst to win)
Yes! typst is actually better than LaTeX in this regard:
LaTeX: contrary to how it sells itself, it's not good at compiling old files. The TeX core is fine but the packaging story is awful. Once I found a beamer presentation about LaTeX itself, including of course some slides about the amazing backward compatibility. Well, the slides failed to compile in multiple places due to the fancy packages used by the author, which had made breaking changes between whatever they were using and my own TeX Live installation. And using an older version of TeX Live is not trivial. Another example: a few weeks ago a colleague found himself unable to compile a document that worked before the system (Linux distribution) update. It took us two hours to figure out that one of the LaTeX packages had made a change which made it incompatible with another package unless you switch the order of \usepackage. Fun!
typst: it's a single binary, statically linked. That's it! If you care about this, you can literally commit this one file (30MB or so) in your repository and it will run flawlessly in 10 years. The packaging system is very recent and still a preview, but it's already better than LaTeX since packages are imported by specific versions. And if you're worried that the typst package server will go down it's easy to mirror it locally.
> Will everybody one collaborates with also use typst? Very unlikely. A new PhD student may find it beneficial to write papers with someone who only uses latex.
That's the reason I mention. If it's the only reason left for learning LaTeX, good luck LaTeX. Very soon it will be "Will everybody one collaborates with also use LaTeX? Very unlikely".
This makes sense: They're essentially “done” with LuaTeX; it works fine and is distributed with TeX Live; it's up to others to use it. Many people are in environments (submission to journals that insist on pdfTeX etc) where they cannot use LuaTeX; the LuaTeX developers cannot change that. (It has minor differences from TeX/pdfTeX but they don't seem keen to fix it.) Meanwhile for those who are willing to use a new system, they might as well simplify (remove the backward-compatibility requirements) and make a better typesetting system more suited to the needs of ConTeXt.
In other words, users can be divided into:
- those who insist/need to use pdfTeX + LaTeX
- those who are willing to try something different, for which there's ConTeXt (with lmtx) or (further afield) Typst, etc.
and if you ask why, 2 packages: psfrag and pstricks.
From what I have seen, it's Overleaf.
Do newer students know or care what flavour of Tex Overleaf uses in the background? Not as far as I have seen.
(If you support both LaTeX and Typst, and improve the Overleaf experience somewhat -- which is definitely possible -- I can't imagine you wouldn't steal some market share from Overleaf.)
* Where LaTeX evidently favours doing whatever it takes to achieve a desired result (exhibit 1 being the article we are discussing), Rust itself and the culture that begot it are clearly on the side of decreeing a Right Way from high above and treating the possibility of deviating from it as a bug. In the light of the discussion in Footnote 7, I could for example imagine a Rust-minded typesetting system designer decreeing that unnumbered "displaystyle" math will not be supported.
* Cultural acceptance of mandatory automatic updates means that backwards compatibility may actually be considered an anti-goal.
* Cultural acceptance of ideology/politics in software engineering brings the danger of invasive conditions. What if, by way of an aggressively interpreted CoC, {receiving funding from military/police-aligned agencies, working with Russian collaborators, working with Iranian collaborators} becomes grounds for being excluded from issue discussions or package repositories? (I do take note that Typst does not currently show signs of doing anything like this, but the tone of the wider Rust community does have to be taken into account.)
Of course all these concerns are speculative, but scientific papers can be a nightmare scenario of maintenance (half a year's worth of work, one-digit number of people in the world qualified to write, two-digit number of people who will bother to read). Under those constraints, some measure of paranoia feels appropriate.
For example, over the last couple of years I've been re-implementing some of Knuth's typesetting work in Rust. Contrary to your claim, my project is obsessed with backwards compatibility and making sure the output is identical to Knuth's. Last weekend I even discovered a ~30-year old bug in one of Knuth's programs [1] as part of an extensive fuzzing effort. (Of course, I re-implemented Knuth's bug in my Rust code [2].)
[1] https://tug.org/pipermail/tex-k/2024-March/004031.html [2] https://github.com/jamespfennell/texcraft/commit/e89b7461780...
And it's also laughable to claim that any research paper written in LaTeX is "maintained". It's a one-off job. Nobody is reusing their previous papers as submodules in new ones.
I sometimes use Typst as an intermediate renderer with Pandoc, but for my highest quality work I insist on features like protrusion. I was using LibreOffice just yesterday and actually had to check multiple times whether there was a space at the beginning of the line because the lack of protrusion support meant unsightly visual gaps.
LuaTeX is stupid but it still has features needed which none of the other markup languages posses.
So I would not recommend a new PhD student (actually undergrad student) to learn Typst just yet.
The ecosystem for the kind of things you mention is expanding rapidly, have a look at these:
https://typst.app/universe/package/fletcher
https://typst.app/universe/package/quill
https://github.com/fenjalien/cirCeTZ
These are based on CeTZ: https://github.com/johannes-wolf/cetz , a kind of TikZ for typst. I don't see anything for Young Tableaux but it should be easy to do based on that.
I generally find PDFs to be a very agreeable way to read the sort of content LaTeX is typically used to write. And in writing it myself I don't need to think about what weird layout issues someone else might encounter when viewing my content. There are certainly accessibility issues with PDFs, but also ways to mitigate that[0].
Pandoc[0] can convert Typst to LaTeX.
IMO If you are able to write in Typst, write in Typst, it's so much better and readable. Your final LaTeX3 macro are hard to read and difficult to parse with the eyes... Also Typst is easier to learn.
[0] -- https://pandoc.org/try/
Pandoc can "convert" html to things too, but you wouldn't use it as a web browser.
Autoref itself seems a fine way of messing up your references and making your source code less readable. The beauty of naming is that you have the context at hand. Moving around blocks of text, or adding and removing text, happens throughout the process. With autoref, you now have to remember to _sometimes_ update the refs or get subtly different references. I wouldn't trust myself to get that right.
[1]: https://talk.commonmark.org/t/cross-references-and-citations...
[2]: https://gitlab.com/DaveJarvis/KeenWrite/-/blob/main/docs/ref...
And I certainly don't believe that LaTeX DSL was the most suitable solution for solving typesetting problems.
Many things people think of as LaTeX are actually just TeX.
The problem with LaTeX was always the lack of underlying proper programming language and data model. The syntax always has been excellent.
LaTeX is powerful and I use it every day, but let's not pretend it's got qualities it doesn't.
Real LaTeX users don't use LaTeX to write documents.
whatever -> pandoc -> LaTeX -> perfect document
^
|
LaTeX template ----+Really? That's a bold claim. Got any source or stats for that?
I assure you I am a real LaTeX user and I use LaTeX to write documents. I see everyone around me doing the same.
The equation subset is the best part of LaTeX syntax and so many people learn it. It's very compact compared to alternatives.
Weird conclusion, because LaTeX has mostly replaced TeX.
There is a nice symmetry here:
C -> C++ -> Rust ~ Typst <- LaTeX <- TeX
I am not sure of what happened, and it must have been unpleasant, but someone going up on your website hierarchy, they reach https://commutative.xyz/~miguelmurca/, they click the only link, and you personally list your profiles there, including email, github and insta. It is OK if someone contacts you for whatever reason on addresses and profiles that you explicitly shared.
> If you email me anywhere else, I will not respond. I also cannot force you to follow basic etiquette if you do write, but it would be appreciated.
This is rude, it looks bad in the article, and you are the one who doesn't follow basic netiquette.
I'm sorry if you felt that addendum was aggressive. However, I still feel like I'm justified in making it absolutely clear how (and if) I want to be contacted. I am in a complicated position where I'm speaking to a niche -- not an imaginary niche, by any means -- but actually addressing every reader. In the face of this, my option was to clearly state my boundaries, regardless.
I list an email address at the end of every article, for the purposes of discussing the content of the article. I add a "+ext" to every email I list (including the one on my personal home page). I had people ignore the email I stated in the article, find a different email, strip it of the + tags, and email me there in a foreign language and opening with "I assume you speak X" (presumably because of my name?).
I disagree with you that it's fair game to do the above. OSINT is, well, legal, and I'm not trying to hide my identity, clearly. But I would still be upset if, for example, someone wrote to my university email (which is not hard to find out, by your own procedure) regarding this post.
Nonetheless, again, it is not my goal to sound rude, but simply to set boundaries and expectations. I will remove the second sentence towards this goal, but stand by its objective meaning, and will keep the rest as is.
Cheers
If you wish to contact me by email, by all means do so to miguelmurca+autoref [æt] cumperativa.xyz - I may not be able to respond. If I don't please don't try to find other emails to send to me, as I'll not respond to those, either, and just delete them. This post is in English. If you wish to write me, please do so in English. Other languages will be deleted.
(The key is assholes won't read it anyway, so there's no reason to snark them, just delete.)
> I list an email address at the end of every article, for the purposes of discussing the content of the article.
I am maybe blind, or because of adblockers, or because of cloudflare, but they don't show up for me, in edge, and in firefox.
You definitely should make it easy for the people to contact you in your preferred way. Put it under the articles, under the blog home page https://commutative.xyz/~miguelmurca/blog/ , and maybe under your HN about section.
My previous message was under the impression that you don't put a contact info in this blog, and I tried to demonstrate that getting messages at your other contact is your fault, not the public's fault or "HN reader"'s fault. (I wonder if
But, 1. famously, HN can be quite predictable in some of their responses (by what I expect is, essentially, a meme effect), and 2. I’ve had some unexpected experiences resulting from previously reaching FP in HN.
> I will remove the second sentence towards this goal
Your critic decided their negative emotions about a miniscule matter are more important than the actual contents of your post and worthy of derailing the conversation. And then they called you rude.
There is really no need to cater to such people. It obviously has zilch to do with you in actuality.
I've never had a problem recompiling documents. Yeah, you might have a problem if you're using LaTeX for a fringe use but most people don't.
yes and no, that bit me last week, some packages decided to become incompatible. but in my case 99% of old files compile fine today.
I'm not disputing that Rust has its advantages; the issues I talk above are mostly problems with the community than the language per se. (On the other hand, we are yet to see how the "import antigravity" attitude will play out once the bits had enough time to rot - it does matter whether your ten-liner test program is only using libc because it was too much work to get a nice pretty-printing library, or whether you imported a pretty-printing library because you could, resulting in 2GB of transitive dependencies of which some have 10 users and 0 active maintainers. And then there's the supply chain security issues)
> maintenance
Surely depends on how fast-moving your field is - I have reused diagram code from late-'90s category theory papers, and recompiled more from source just to get the benefits of the pdflatex pipeline over the latex-dvips-ps2pdf one (selectable text, proper font rendering, hyperref). Repositories like arXiv also may need the ability to recompile old submissions automatically.
LaTeX output seems not to be on the roadmap [2], which I can respect. The amount of weirdness you would have to workaround to get good Typst to LaTeX translation sounds like a pain. I guess the hope is that the publishing industry starts adopting Typst...
[1] https://typst.app/ [2] https://github.com/typst/typst/issues/149
what was being discussed is using Pandoc to convert from Typst to LaTeX, which it can't really do because its internal document representations are not as expressive as either Typst or LaTeX.
https://github.com/typst/typst/blob/10a3fbd174fc1a3f95937c91...
It's basically a kludge; there's a lot more work needed to actually implement even overhang properly.
Because it has different meaning in different context. It's a nice shorthand for subscript in math mode and you still need it as an underscore when you write code or normal text.
> Why can't macros have numbers in their names?
I give you that. That's due to underlying lack of proper programming language.
> Why does a simple thing like bolding text require a \textbf?
What else do you want there? The markdowns * has famously bitten me multiple times when it interfered with my multiplication in math (math + mathjax). Or when the bold needs to cover a full paragraph. I don't have a better suggestion. I'll be happy to hear another one.
That being said, though, for any major project, it's hard to overstate the long-term effect of community pressure. I maintain a moderately-sized project using Gtk for its GUI, and am personally deeply opposed to the RHEL blob (which Gtk/Gnome belongs to)'s culture of "windowsification"/switching away from simple composable interfaces to overengineered proprietary ones. Yet, recently contributors successfully browbeat me into switching the config system from a legible textual one to gsettings (basically Gtk's implementation of the Win32 registry, with all this implies) - it was just too much pressure over what seemed like an ultimately minor thing, and I didn't want to alienate people who I depend on for a lot of work that being well-embedded in the wider community conveys competitive advantage in, such as getting packages into distro repositories. I'm left wondering what principles/preferences I would not compromise on, if the resident Gnome wizards were to all disagree. If your project grew so large that you couldn't do without the help of random Rust community members, and the majority of them got very insistent that you should not reproduce Knuth's idiosyncrasies, can you say with confidence that you would resist?
I was initially suprised to see that the typst devs chose to go with their own syntax, but I'm now very happy they did.
$
cal(C)(M) = cal(E)_T^t (theta, cal(S)_t)^2 + C_t M_t^(-2/d)
+ cal(E)_T^"PDE" (theta_t, cal(S)_"int")^2 + C_"PDE" M_"int"^(-2/(d+1)) \
+ C_1T^(1/2) [cal(E)_T^"div" (theta, cal(S)_"int") + C_"div" M_"int"^(-1/(d+1))
+ (1+nu)(cal(E)_T^s (theta, cal(S)_s) + C_s M_s^(-1/d))]
$
$
norm((u_0)_j-hat(u)_j (t=0))_(L^2 TT^d) &<= norm(u_j - hat(u)_j)_(L^2 delta Omega) \
&<= sqrt(2 max {2h_Omega,d+1} / rho_Omega) norm(u_j - hat(u)_j)_(H^1 (Omega)) \
&<= sqrt(2 max {2h_Omega,d+1} / rho_Omega) C_(1,k,d+1,u_1) lambda_1 (N) N^(-k+1)
$For me, they need to promise full backwards compatibility.
"Yeah just use ancient binaries" is not a viable strategy for future-proofing.
It's a lot easier to move fast and break things when you don't care about stability.
$ ldd bin/typst
statically linkedHere's the real output.
$ ldd result/bin/typst
linux-vdso.so.1 (0x00007ffd2c4e5000)
libgcc_s.so.1 => /nix/store/28d6zz06v3mpwdbi72fdw64qmmq8rhfm-gcc-13.2.0-lib/lib/libgcc_s.so.1 (0x00007f4fe68b9000)
libm.so.6 => /nix/store/7x591g0d1kydp4dci0jvksi0qbn013v3-glibc-2.38-27/lib/libm.so.6 (0x00007f4fe67d9000)
libc.so.6 => /nix/store/7x591g0d1kydp4dci0jvksi0qbn013v3-glibc-2.38-27/lib/libc.so.6 (0x00007f4fe4619000)
/nix/store/7x591g0d1kydp4dci0jvksi0qbn013v3-glibc-2.38-27/lib/ld-linux-x86-64.so.2 => /nix/store/7v29y7b3b38x2hpgld698fw6k5mffam8-glibc-2.38-44/lib64/ld-linux-x86-64.so.2 (0x00007f4fe68e1000)
You faked your console output.
The "will it work in 10 years?" just swayed _immensely_ in Typst's favor.
But it's true that when I tried ldd on a trivial static binary (compiling "int main() { return 0; }" with "gcc -static a.c") I got a different message: "not a dynamic executable". I don't know why you'd get sometimes one message sometimes the other...
And obviously you can also link statically against musl on glibc systems. It's just another library.
And even your linked binary will probably work in 10 years, these libraries are not likely to break. See for example https://superuser.com/questions/1450027/how-exactly-a-system...
I couldn't say the same thing about the LaTeX binaries:
$ ldd /usr/bin/pdflatex
linux-vdso.so.1 (0x00007ffe347f7000)
libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007e699d5bf000)
libz.so.1 => /usr/lib/x86_64-linux-gnu/libz.so.1 (0x00007e699d5a3000)
libkpathsea.so.6 => /usr/lib/x86_64-linux-gnu/libkpathsea.so.6 (0x00007e699d587000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007e699ce00000)
libm.so.6 => /usr/lib/x86_64-linux-gnu/libm.so.6 (0x00007e699d4a0000)
libgcc_s.so.1 => /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007e699d47e000)
libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007e699ca00000)
/lib64/ld-linux-x86-64.so.2 (0x00007e699d624000)
$ ldd /usr/bin/lualatex
linux-vdso.so.1 (0x00007ffe4f8d6000)
libtexlua53.so.5 => /usr/lib/x86_64-linux-gnu/libtexlua53.so.5 (0x00007eccb87c1000)
libzzip-0.so.13 => /usr/lib/x86_64-linux-gnu/libzzip-0.so.13 (0x00007eccb9392000)
libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007eccb8786000)
libharfbuzz.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x00007eccb86b7000)
libz.so.1 => /usr/lib/x86_64-linux-gnu/libz.so.1 (0x00007eccb9376000)
libkpathsea.so.6 => /usr/lib/x86_64-linux-gnu/libkpathsea.so.6 (0x00007eccb8699000)
libm.so.6 => /usr/lib/x86_64-linux-gnu/libm.so.6 (0x00007eccb85b2000)
libgcc_s.so.1 => /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007eccb8592000)
libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007eccb8200000)
libglib-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007eccb8458000)
libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007eccb8138000)
libgraphite2.so.3 => /usr/lib/x86_64-linux-gnu/libgraphite2.so.3 (0x00007eccb842f000)
/lib64/ld-linux-x86-64.so.2 (0x00007eccb93c5000)
libpcre.so.3 => /usr/lib/x86_64-linux-gnu/libpcre.so.3 (0x00007eccb80c2000)
libbrotlidec.so.1 => /usr/lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x00007eccb80b4000)
libbrotlicommon.so.1 => /usr/lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x00007eccb8091000)
PS: you could edit your previous comment and/or apologize for accusing me twice of forgery.
Just to now push it a little. I wonder if I can make the `1/(d+1)` in the superscript be not a real fraction but inline fraction.
\begin{align}
\begin{split}
\mathcal{C}(M) = &\: \Et^t(\theta,\S_t)^2
+ C_t M_t^{-\frac{2}{d}}
+ \Et^\pde(\theta,\S_\inte)^2 +C_\pde
M_\mathrm{int}^{-\frac{2}{d+1}}\\&+ C_1{T}^{\frac{1}{2}}
\bigg[\Et^\divv(\theta,\S_\inte) +C_\divv
M_\mathrm{int}^{-\frac{1}{d+1}}+(1+\nu)
big( \Et^s(\theta,\S_s) + C_s M_s^{-\frac{1}{d}}\big)\bigg],\\
\end{split}
\end{align}
\begin{align}
\begin{split}
\norm{(u_0)_j-\hu_j(t=0)}_{L^2(\mathbb{T}^d)} &\leq
\norm{u_j-\hu_j}_{L^2(\partial \Omega)} \\&\leq
\sqrt{\frac{2\max\left\{2h_\Omega,d+1\right\}}
{\rho_\Omega}}\norm{u_j-\hu_j}_{H^1(\Omega)}\\
&\leq \sqrt{\frac{2\max\left\{2h_\Omega,d+1\right\}}
{\rho_\Omega}}C_{1,k,d+1, u_1} \lambda_{1}(N)N^{-k+1},
\end{split}
\end{align}