2. Why would we want to observe changes in real time? Do you want this when coding too?
My workflow (that I share with co-authors) is to write everything in Markdown (using Pandoc to get PDF output). When we are almost finished, we export (again with Pandoc) to LaTeX.
We collaborate on Git, because, just as when programming, I don't want my co-authors to witness my crappy thought process. That's just noise. Git allows us to use different Git-branches for the arxiv version, the conference version, and the journal version. We also use tags to indicate different submissions.
I‘m not an Typst author, but I don’t get your point. How are you going to specify a 2 column outlay, for example? Markdown is not very expressive. You can always compile (less expressive) Markdown to Typst.
2. Why would we want to observe changes in real time? Do you want this when coding too?
So your 1. is no longer markdown everyone knows, but an ad hoc, badly documented new language understandable by a tiny subset of editors/people. How is that better?
2: it is fundamentally a command line app that converts a .tex file to a pdf (and some other output formats). You can just git over that if you prefer it. The web editor is a separate application, which is very streamlined and a good option for students working together, but sure, feel free to use something else.
Yeah, collaborating in real time on the same document is pretty neat (from using google docs for this.) Having someone else typing on the same page got an unexpectedly visceral "argh! it's moving! get it off of me" reaction the first couple of times I tried it, had to switch tabs and come back later.
It's definitely only a problem for some people, and might even be specific to some aspect of the google docs implementation, I don't know yet. But yeah, that feature is not the slam dunk it sounds like, and you might not realize it until you're in the middle of it.
It seems that it would have been good to be basically extensions on markdown. For example why use = for headers rather than the established #. + For numbered lists is arguably an improvement on 1. But maybe they could support both. It seems like these are pointless differences.
Their math syntax is already a common Markdown extension but they seem to be more or less compatible in the framing although the actual match language is new which seems fine. Then of course they add on their macros.
So I guess the point is why diverge where not necessary. Not why diverge at all.
There's already a pandoc conversion to Typst and the syntax is mostly similar. Various symbols that are in use in markdown is used by the Typst in some other places (e.g. # is used for designating code mode in content mode so you can use variables function in-text).
> 2. Why would we want to observe changes in real time? Do you want this when coding too?
If you've ever wanted to just use something that's more powerful than Markdown (and not use awkward HTML in between, let's face it MD was supposed to be minimal), you have to use LaTeX, but it gets painfully slow as the project gets big. Fast feedback loops are essential. Would you rather wait 5s seconds to see that you have made changes that destroyed your layout or in an instant with incremental compilation?
3. You can collaborate with Git (and on the Web App) because Typst is also a language and a compiler (see their GitHub page at https://github.com/typst/typst) like LaTeX.
You can have it function as well as Markdown with templates and just use the sugar syntax (plus custom functions ad hoc without having to wrangle with LaTeX's enigmatic errors [1] and confusing macros even for something trivial like fonts [2]).
[1]: remember \badness 10000?
[2]: You'd have to install a package even though the OTF/TTF of the font you want is already installed on your system. And don't even mention how it's a completely different setup for PDFLaTeX, ConTeXT, and LuaLaTeX to use fonts. This is assuming you want to use LaTeX templates with markdown using Pandoc or Quarto. sigh...
> My workflow (that I share with co-authors) is to write everything in Markdown (using Pandoc to get PDF output). When we are almost finished, we export (again with Pandoc) to LaTeX.
That's your (and my) workflow. However, there is clearly demand for a collaborative workflow, as demonstrated by Overleaf and ShareLaTeX before that.
Thanks for sharing your workflow! I've long wanted to adapt something similar, but it is difficult to get away from Word - especially because the comment and revision functions in Word are more straightforward than git-based solutions
2. Why would we want to observe changes in real time? Do you want this when coding too?
My workflow (that I share with co-authors) is to write everything in Markdown (using Pandoc to get PDF output). When we are almost finished, we export (again with Pandoc) to LaTeX.
We collaborate on Git, because, just as when programming, I don't want my co-authors to witness my crappy thought process. That's just noise. Git allows us to use different Git-branches for the arxiv version, the conference version, and the journal version. We also use tags to indicate different submissions.