201–210 of 243 posts
Earlier quoted context omitted.
I really wish typst had a good way to emit html. Id love to use it for blogging & technical writing and documentation.
(Typst dev here.) That's one of the next big things we plan to work on once Typst 0.12 has shipped. :)
Earlier quoted context omitted.
Typst authors being germans, one can hardly accuse them in the "everyone uses English" attitude. Typst `dif` math operator (as in dx/dt) produces upright 'd', quite unexpected to ones used to slanted 'd' tradition.
> Typst authors being germans, one can hardly accuse them in the "everyone uses English" attitude. On the other hand, one can easily understand why, bein German, they assume Figure, Equation, etc. will always be capitalized. > Typst `dif` math operator (as in dx/dt) produces upright 'd', quite unexpected to ones used to slanted 'd' tradition. I would indeed expect an upright 'd'. It's an operator, not a variable. I d…
That's strange. I've never seen a math article in English with upright 'd' differential, only have seen it in German and Spanich articles. It's also math italic in TeX (you can check Knuth's TeXbook).
Earlier quoted context omitted.
The current actively-developed VSCode extension is Tinymist. Its workflow is great and addresses all your issues (to the extent they are even relevant to Typst): > Well, the feature you mentioned of clicking the PDF and redirecting to the source. Tinymist does this. Click on text and it redirects the document buffer to the corresponding source text. > Preview in the same buffer (window) as the code Tinymist previews…
It seems good, and there's an emacs version, altough simpler than auctex. Not having the preview in the code buffer, isn't a dealbreaker, especially when typst is so fast, but it's still a useful feature. The part of the packages I wasn't talking about a tex feature but an emacs one. When you import a package, it'll usually add environments or macros (in typst i believe they are called commands). Emacs would recogniz…
What features do you want from cetz that you think are missing?
(And yeah making something with it is a good idea. You’ll get much more of a sense of it by playing around with it.)
Earlier quoted context omitted.
Yeah I think its fair to say latex has a much more mature ecosystem. And we should expect nothing less from something made in 1985. Its almost 40 years old. But typst is catching up as fast as it can. I find it very usable already.
Yeah, my guess is that it'll fall on either side of the same go/c vs c++/rust "simple rules with more implicit rules in your head" vs "complex tool with less in your head" divide in people's opinion.
I think it’s more like latex is like c++ and typst is like zig. C++ & latex have been worked on for decades, and has all this design baggage it carries around. An ugly macro system, weird “compile it 3 times” things. But it also has decades of work filling out the 3rd party package ecosystem and decades of stackoverflow questions and answers.
Zig & typst are rewrites from scratch with new ideas. The core is better designed, since they have been able to learn from what came before and have a do over. But they’re missing the decades of incremental work fixing bugs and filling out the ecosystem. So, yeah, I’m sure the eMacs plugin is worse for typst and latex. It’s all just … newer.
Earlier quoted context omitted.
There are 3 syntactic modes in typst: markup, code and math. In markup, everything is literal, unless you put a `#` sigil like `#expr` in which case `expr` is parsed in code mode. In code mode everything is an identifier, as usual in programming. In math its a bit of an ugly tradeoff but its ok: single-letter things are parsed as literals but multi-letter tokens are parsed as identifiers. Finally, in code you can enc…
> In markup, everything is literal, unless you put a `#` sigil Unless it's a "=", then it begins a new section. And unless it's a "-" or a "+" or a "/", then it's a list item. And unless it's a "<", then it defines a label, or a "@", then it's a reference to one. And unless it's a "_" or "*" or "`", then it changes font or style.
I've moved all of my LaTeX-based content creation to Typst. It's: - Fast—Compiling my books would take around 1 minute (I often had to compile twice due to indexing). With Typst, it takes less than 5 seconds. - Easy to write—I actually don't write it, I wrote a bunch of Pandoc plugins to tweak the output from Pandoc (I write all my books in Jupyter these days, so lots of markdown). - Easy to read—I've used LaTeX for…
I hope that Typst at least allows you to nest elements without any issues.
Earlier quoted context omitted.
I imagine you're projecting how LaTeX works onto Typst, though despite years of use and a PhD in PL I never really figured out how LaTeX works so I'm not certain. I don't think Typst has a lot of global state to get corrupted. Like, if one package defines a variable `foo` and another package defines a variable `foo`, and you use both of them (and don't try to import `foo` from both), it's not like those `foo`s are go…
Typst uses pure functions, so they cannot mutate globale state
C-f r u s t RET But of course. I'd rather see effort go into improving LaTeX performance instead of creating some new incompatible thing in a trendy language. One could also imagine an Elixer-style "resyntaxing" of LaTeX that would preserve compatibility with decades of packages. I don't think a long-developed ecosystem should be given up lightly.
TeX has three actively-maintained engines, and there are a lot of folk putting work into improving LaTeX and its ecosystem. So effort is going into LaTeX, including performance, right now. Probably someone committed a perf improvement today, or in the last week. There are problems with TeX which can't be fixed, problems which Typst is directly addressing. I wish them all success. I will never understand the attitude…
I ask because most issues I got using LaTeX tend to be the result of LaTeX additions, very rarely are they issues from TeX itself.
Heck I even took to using TeX macros at some point because while they can be an amazing footgun they're also a lot simpler.
Earlier quoted context omitted.
With your experience of both, have you found that Typst has fewer issues with conflicting/non-commutative plugins than LaTeX does? Because that's where I lose the most time with LaTeX: packages often mess with the (piles of) global state in ways that sometimes conflict, and the only "solution" seems to be that, if you're very lucky, sometimes conscientious package authors will try to "detect" (through various hacks)…
I think compatibility issues in LaTeX often come from packages that redefine the same macros in incompatible ways. This kind of things doesn't happen in typst because all user code is pure: a package can define 1) values or pure functions that can be imported (this makes them available only in the scope where they're imported) and 2) content that can be included in the document. There's still potential for conflicts,…
C-f r u s t RET But of course. I'd rather see effort go into improving LaTeX performance instead of creating some new incompatible thing in a trendy language. One could also imagine an Elixer-style "resyntaxing" of LaTeX that would preserve compatibility with decades of packages. I don't think a long-developed ecosystem should be given up lightly.
Speed and nice error messages in (La)TeX, and to some extent ease of programming, are entirely doomed because of fundamental design choices. Being based on unhygienic macro expansion means that there is only one way to evaluate (the slow way), there will never be incremental compilation (everything can possibly be stateful in horrible ways), there will never be good error messages because there's basically no AST inf…