Comment by jameshart
1 day ago
Sure.
And driving on the left is one of the most reasonable sides of the road to drive on, but in a country where everyone drives on the right, it’s good to accept that, though driving on the left offers just as many advantages, nonetheless you shouldn’t insist on continuing to do so.
Markdown is also one of the most reasonable markup languages to use for text, and it has won sufficient share that it should be your default choice for lightweight markup, no matter how reasonable org-mode is.
Are you suggesting I should pick the markup format for my private files according to the perceived popularity of another format?
I'm not sure what's your point. Are you telling people who use org-mode that they shouldn't?
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.
6 replies →
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?
No? I’m pushing back against advocacy for broader adoption of org mode beyond personal file markup though, which is what I feel like this piece is arguing.
> note that this is not about Emacs at all. This is about Org mode syntax and its advantages even when used outside of Emacs.
One of the advantages of "going with the flow" when you can is that you benefit from numbers. You're a market of one, but by "going with the flow" the total market is huge.
Even if for me personally 185V mains power would be better, I can't buy gear for 185V, none of the electricians around here know how to work with it, the cables and sockets and everything else are defined around the prevailing systems at 220-250V here.
Maybe in my kitchen a 520mm dishwasher would be great, but alas dishwashers you can buy here are 600mm or 450mm ("slimeline") models, so 520mm isn't available.
With my poor hearing 14-bit PCM would be absolutely fine, but Sony's "Compact Disc" used 16-bit so that's what everybody uses and records by default.
If you work with Markdown, there are a lot of existing tools which are ready to use. There are tools for Org Mode, but maybe not as many.
There's definitely a sliding scale here. Refusing to use Twitter because it's full of Nazis is very different from refusing to conform to society's expectation that you wear clothes outside for example. There are people willing to spend most of their lives in jail because they refuse to wear clothes but almost all of us don't think that's a principle we care about enough to prioritise (also some of us get cold).
bro we're talking about text formats for organizational skills not justifying public nudity
It's a matter of taste, isn't it? It's like LaTeX vs. Typst. You create the environment that works best for you.
In my experience, not really. I'd love to use Typst, you have no idea -- but when most journals require you to use their LaTeX template, then my personal taste doesn't really enter into the equation.
For personal workflows, yes. In your own backyard, you decide what side of the road you drive on.
But when building a product for other people to use - a messaging tool like slack or a commenting platform like GitHub code review…?
GitHub has at least some support for org-mode rendering. Which is a good reminder that a lot of this stuff really doesn't have to be a stark either-or choice—a lot of standardization isn't inevitable or natural or necessary, but just a choice we happen to make, often for systemic reasons that aren't inherently justified (legibility/etc).
What if you're building a product for other people like you to use?
I think this is very common, like people building tools for trackers vs Ableton/Live/etc style DAWs, or those writing software only targeting the OS they use? Not every product is built with the goal of worldwide adoption.
Back to the specific case being discussed, I can easily export usable markdown from org. The people I share it with have never noticed it wasn't markdown since the start, so why wouldn't I continue to use org even when interacting with people who don't? It makes my private side of the exchange better for me, and it doesn't affect the public side negatively for others.
2 replies →
You cant even paste markdown into Slack, it’s embarrassing.
Markdown (subjectively) looks better than Org when it’s plaintext - postfix headers and dashed lists are annoying to parse but they distinguish sections visually. Org by comparison feels like a sea of asterisks.
(I am tickled by the /italic/ syntax though…)
I don’t like using “-“ for bullets and “*” for headings. I do love underlines for underlined text, slash for italics, and asterisks for bold. Other than that, po-tay-to, po-tah-to. Let’s all just pick one and use it consistently. I do agree with the argument that says “Markdown” is meaningless and you’re always forced to ask “What do you mean by that? Which flavor, exactly?” But that happens with anything “lightweight” as it is inevitably extended to deal with more complex demands and becomes more heavyweight in the process.
Markdown is worse than other formats in many ways. It has several ambiguities, there are significant variations between implementations, fairly basic features like tables, footnotes, strikethrough, etc. are "extensions" that aren't widely supported.
The only real advantage of markdown is that it is has because more ubiquitous/popular than others, possibly in part because it is relatively easy to implement, as long as you don't care that much about exact compatibility with other implementations.
I would ask you to read the article before writing a comment like that.
The whole point of the article is that there is no Markdown. At least not a single instance from it. So when you're referring to Markdown, you're actually referring to a few dozens of slightly different markup languages which are hard to identify and except for a few, very tedious to convert.
In my opinion, this is far from being "reasonable".
Orgdown is explicitly mentioned only as one LML that doesn't come with the listed downsides of Markdown. So if you think that my article tries to convince you to use orgdown instead, you've missed the part where I say that there are many good alternatives of Markdown that do perform better when it comes to real world processes. I just tried to use orgdown as one example among many to state my point by showing an alternative. If you think that orgdown is the only one, you did not read the article carefully enough.
YMMV
This is advice that I would have rolled with pre-Generative AI.
Today, I'm not so sure. I'm actually way used to zim-wiki syntax because that's what I started off with; and already "moving it around" is becoming orders of magnitude easier given the ability to vibe-code tons of little scripts that make it work better with everything else -- and while this might seem a bit counter to the point -- I think one can reasonably rely on the idea of "market share isn't that important anymore compared to 'you, personally, should use the thing that works the best for you because translation will get orders of magnitude easier.'"
> This is advice that I would have rolled with pre-Generative AI.
/me laughs in pandoc
I'm surprised nobody else brought it up - what are the pros of left-hand driving? Is it about where the controls are in relation to handedness? Some sort of safety benefit? Better visibility in certain scenarios? And are postal carriers in America who drive LLVs getting the _best_ or the _worst_ of both worlds?
(I like to think about these sorts of things!)
I've driven both. Drove LHD for more than a decade in India. Now driving in RHD country for 2y now. Personally, I enjoy RHD more because I am right-handed and I get to do things easily with my RH. Otherwise, I realized that safety benefits comes from the driving discipline and not driving on a particular side of the road. Driving on Aus/Japan is way safer than India, despite all of them being LHD.
How does RHD make it easier to do things with your right hand?
I’m right-handed in a LHD country, and this means I used my right hand for almost everything. The gear selector, radio, climate controls, GPS… all done with my right hand. My left hand controls the turn signal, that’s about it. I think I’d have a very hard time with a RHD car where I need to be precise with buttons and touch screens using my left hand.
this is so true. i wrote a document in org and i'm still in the hospital after crashing into someone's markdown file
And here I am still carrying the torch for BBCode-alikes...
Markdown can be trivially embedded in org-mode, so no need to even miss out on that which "won sufficient share": * Org with md block #+begin_src markdown ..... #+end_src
Markdown may be a winner, but preferring it when org-mode exists is like tying both arms behind my back and trying to do serious things with my feet.
So like,
Yep. I wouldn't like to see the result of embedding any org of reasonable complexity in md though, while I've embedded pretty complex md in org. And performed various operations on the whole thing, but now we're going from syntax to (Emacs) features.
[dead]
I’m not sure I see the benefit in that.
Org is essentially the parent of _all_ other plaintext formats, and is able to treat them specifically at the native level. So for example there's a single command to run a code block, but the code runner is correctly resolved. And multiple blocks in different languages can communicate with each other. Entire projects can be placed in a single org files and still operate as though they're separate files. Literate programming is a breeze. Organization of anything is trivial.
2 replies →
As long as we're telling people they should conform to what everyone else uses, why aren't you using Microsoft Word format instead?
We are talking about choosing a lightweight text markup language. Not choosing a file format for rich text files.