Comment by crazygringo
1 day ago
If you think you'll ever want to use third-party tools to process that markup, or if some of your private files will transform into public files at some point, then yes, considering popularity makes a lot of sense.
If they're just text files you edit raw that will never interact with anything else but your text editor, then of course popularity doesn't matter at all. But in my experience, my use cases tend to expand over time.
The article even talks about org mode's interoperability, mainly about the fact that pandoc supports it. And then bizarrely ignores the fact that it has much less ecosystem support than Markdown. So this is very much a subject the article itself brings up, and something that therefore also deserves to be critiqued.
OP here. I stuck with orgmode all these years /because/ of the interoperability.
If I'm writing in Org, I can tangle / detangle between other plaintext sources, including source code. As well as export to collaborate.
The proposition is "yes, and", not "either / or".
It's /fine/ to switch to the popular "team" standard and stay there when needed. Several of my workplace documents, including wiki entries start off as local org-mode drafts. Once I'm okay to share, I export to markdown or draft wiki page and solicit comments. After that, if the document is for shared maintenance, I let my org-text alone, and switch to the "team" format.
This is perfectly fine.
That and the many kinds of markdown. I've been bitten enough by having to look up yet another poorly maintained document on how to markdown for /this/ particular app or website or utility, that I'd rather pandoc translate between my (sane, well documented, fully extensible) org text and whatever I need to share with others, than learn edge cases of various markdowns.
Sure, but I think it's safe to say Markdown has more interoperability, no?
Yes you can always use pandoc, but conversion usually brings quirks of its own. And more generally, the less conversion steps you need, the better.
If you just stick to vanilla markup, you don't encounter incompatibilities. The "many kinds of markdown" isn't an issue if you're not using platform-specific extensions in the first place. Which, usually, you're not, unless you need to do something very specific to that application.
Yes, more interoperability at the cost of capability.
Also, yes, conversion is quirky. That is why Org works until it does, and then I trade off being stymied by markdown's more plain-ness, in favour of collaborating with others.
And with vanilla markup, the trouble is that many applications /do not/ use just vanilla markup. People /invariably/ want "one key tweak" (like, front-matter or table of contents or footnotes or some such thing), and everyone ends up doing their own thing.
Perhaps the trouble with markdown is it's /too/ plain. So yes, lots of people can do lots of lowest common denominator stuff, but it does not extend to individuals wanting "just one thing" which also adds up to a lot of people.
Edit: a real-life example... I typically run code from org-mode for interactive testing and debugging --- the kind of stuff we write small throwaway scripts for.
In this one project, I made it so that /I/ or anyone else using org-mode could do it from org, for local development, and anyone else could just use the script as-is... including the CI pipeline.
[1] https://gitlab.com/nilenso/cats/-/raw/master/README_TESTS.or... (notice that the gitignore procedure needed for this trick is self-executable from this org file itself, in addition to being self documenting)
[2] https://gitlab.com/nilenso/cats/-/blob/master/bin/curl-tests...
3 replies →
If I just stick to vanilla markdown, then I don't have features that I would really like in my notes, like tables, footnotes, etc.
Ahem. When I started with Markdown, I was regularly experiencing all the issues mentioned for years. The most popular format was Word (doc). Perhaps I should have stuck with that?