4 ms·
1. Why not use Markdown-compatible syntax? 2. Why would we want to observe changes in real time? Do you want this when coding too? My workflow (that I share
by JohnKemeny 3y ago
1. Why not use Markdown-compatible syntax?
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.
- huijzer 3y ago1. Why not use Markdown-compatible syntax? 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? You prefer to debug by looking at the code only?
- JohnKemeny 3y ago1. Using `classoption: twocolumn` 2. I see that I wasn't completely clear. I meant: why do we want to see our collaborators' changes in real time? To me, that would be very disturbing.
- eichin 3y agoYeah, 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.
- bobbylarrybobby 3y agoI'm with you. Git with one sentence per line is generally my preferred workflow for markdown, asciidoc, etc.
- kaba0 3y agoSo 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.
- kevincox 3y agoIt 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.
- Ar-Curunir 3y ago> 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.
- jcparkyn 3y agoYou can still use git with typst, if you use the offline (open-source) compiler instead of the web app.
- karencarits 3y agoThanks 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
- jskherman 3y ago> 1. Why not use Markdown-compatible syntax? 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 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...