Comment by adityaathalye
1 day ago
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...
> Yes, more interoperability at the cost of capability.
Well, then why aren't you using LaTeX? Isn't that more capable?
> And with vanilla markup, the trouble is that many applications /do not/ use just vanilla markup. People /invariably/ want "one key tweak"
And, that's going to be true as someone adopts it outside of Emacs, right?
Surely, someone will decide that the way Org Mode is doing something is wrong, right? They're going to do something like say, "Hey, why don't we permit Markdown style headings, too?" or something similar.
Or are you suggesting Org Mode military police? Felony markup possession?
There's nothing special about Org Mode that makes it immune to the problems you're describing. They will happen immediately upon wider adoption.
And if you somehow do stop it, well, it's tech. If you don't have a patent on it then someone will fork the idea and you'd have Borg Mode directly competing with you anyways.
2 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.