|
|
|
|
|
by crazygringo
159 days 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. |
|
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.