Live data from Hacker News

Why are we still using Markdown?

bgslabs.org

291–300 of 328 posts

Re: Why are we still using Markdown?

#291
"we" aren't using anything, "you" are.

Use the best tool for the task. markdown is really good for talking to AI as a human for example.

Same goes for JSON, YAML, etc.. use what makes sense to you. I like markdown but I have issues with it as well. I like html, but i despise it sometimes. One-size-fits-all is the real enemy.

My view is that for all *langs (markdown, config, data, code, styling,etc..) we should leave the proverbial cave and come down from the trees, and talk about interoperability and best practices. Contracts, expectations, and exceptions.

There is this pattern where we invest in some software technology, and it becomes this ideology people fight over. Or invest a lot into it and fall into sunken-cost thinking.

Being able to rapidly figure out the best tool/solution, and readily tear out the old and patch in the new with minimal loss and friction, that should be the next era of tech. Not a repeat of the old, with a slight twist. I don't need another JSON, Markdown, HTML, CSS, C, Rust,etc.. especially with the advent of LLMs (hype aside), syntax is important but it isn't what it used to be. I want to be able to write in Markdown and know that if there is a better format, I can easily stop using it and reliably transpile all my existing Markdown, and tooling that works with Markdown to use that new format.

Adaptability and communication are the biggest dead-weights holding back technological progress.

Re: Why are we still using Markdown?

#292
post #168

Earlier quoted context omitted.

But you still have to use it for man pages, even though nobody prints man pages anymore.

A man page is simply a formatted text file. The display of it is performed by the program defined in the MANPAGER or PAGER environment variable, or by a default program, usually less(1). That is the program that would be responsible for navigating any hyperlinks, and the format of references to other pages is already pretty easy to pick out so developing a man page reader that could follow references to other man pag…

> The display of [a man page] is performed by the program defined in the MANPAGER or PAGER environment variable, or by a default program, usually less(1).

A man page source isn't a binary format, so your statement that they're "plain text" is technically correct. (The same is also true of TeX and LaTeX files, and even PostScript if you want to stretch the definition of "plain text" until it snaps.) But the renderer is groff or (legacy) troff with the `an` macro set. less(1) (or, originally, more(1)) is just the pager that consumed the former's output (if the output format is ASCII, which is one of many) and handled paging on the terminal for the convenience of the user.

In my old Sun workstation (and even early Linux desktop) days, I rarely used man(1) in the terminal because 1/terminals were usually too small and weren't usefully resizable like they are today, and 2/unadorned monospaced fonts don't look nearly as nice as properly typeset pages do. (Color terminals were just coming on the horizon, and text could only be emboldened, not italicized.) Instead, I typically used xman whenever I could. The best way I can describe xman is as if you were rendering man pages into PDFs and viewing them in Preview on the Mac. Man pages were much more comfortable to read that way.

Re: Why are we still using Markdown?

#293
post #243

Earlier quoted context omitted.

> So you can still see the actual text that you're editing But you're not editing that text! You're editing some other text and see a bunch of asterisks all over the place. And this is especially bad in nested styles - try some colored bold word in a table cell - without hiding the markup you'll basically lose most of visibility into the text/table layout > to reduce ambiguity it does the opposite, you can't easily d…

Ha, I remember this religious debate all the way back in the days of text-mode word processing in the 80s on CP/M and PC. I was indoctrinated in the WordStar camp where style controls were visible in the editor between actual text characters, so you could move the cursor between them and easily decide to insert text inside or outside the styled region. This will forever seem a more coherent editing UI to me. This mig…

> easily decide to insert text inside or outside the styled region.

Only for the 3 primitive styles that were supported? 3 table cells of RedBold GreenLowerCaps BlueUnderlineItalic isn't easy anymore

But also - there wasn't a single app in the 80s with a different easy approach, right? So removing noise had a downside.

> styling command. It is part of the document structure.

Not for the most used markdown markers, where styling = semantic.

Re: Why are we still using Markdown?

#294
post #260

Earlier quoted context omitted.

One problem with the /italics/ form is that it's not convenient when writing about filesystem paths (though I do like its visual indication of slanting).

I agree that file paths should be in `backticks`. Or italics can be //double slash// to avoid ambiguities with file paths. That still leaves the windows style //some/file/path as ambiguous But I’ll never accept single * as natural for italics.

Try finding the backtick on a mobile phone keyboard in less than a minute, tho. So very annoying. (SwiftKey I'm look at you, bud.)

Re: Why are we still using Markdown?

#295
post #270
post #268

Earlier quoted context omitted.

Indeed. I'd go with dead simple rules. The below assumes whitespace or punctuation on either side: *bold* _italic_ *_bold italic_* _*also bold italic*_ Any other combination does not parse as formatting, and is considered literal text. Yes, this prevents marginally useful cases like putting an it al ic fragment in the middle of the word. I'd be fine with that.

If I’m understanding correctly, your rules are based on word boundaries? How do you define a word boundary?

Word boundaries are a complex thing, especially in languages like Chinese or Japanese. Whitespace and punctuation are much less complicated, even if we take the full Unicode case. So the boundary where formatting is considered is between (whitespace | punctuation) and anything else.

Re: Why are we still using Markdown?

#296
post #197

Earlier quoted context omitted.

Yeah, * asterisks * for italic has always felt wrong to me. I can understand underscores if slashes cause confusion with file paths. *bold* and _italic_ would have been better.

I agree that using *asterisks* just feels wrong for italics, and are much better suited for bold. However, surely the _underscore_ is just perfect to visually indicate underlining? As for /slashes/, which would visually be perfect for italics, the only reason they conflict between italics and filepaths is the fact that in both cases they are expected to be used at the beginning and end of a word. Maybe using an unnat…

> Maybe using an unnatural placement of )parentheses( could have worked as a non-conflicting indicator of italics.

Using different delimiter for opening and closing is a good idea on its own, too. I think it makes parsing simpler and unambiguous wrt nesting.

I've imagined something like this:

  `(monospace)
  _(underline)
  /(italics)
  ~(overstrike)
Probably looks a bit more distracting, though.

Re: Why are we still using Markdown?

#297
post #295
post #270

Earlier quoted context omitted.

If I’m understanding correctly, your rules are based on word boundaries? How do you define a word boundary?

Word boundaries are a complex thing, especially in languages like Chinese or Japanese. Whitespace and punctuation are much less complicated, even if we take the full Unicode case. So the boundary where formatting is considered is between (whitespace | punctuation) and anything else.

So now you have to distribute a character class table in every implementation of your language, which is precisely what the author of Djot wanted to avoid.

Re: Why are we still using Markdown?

#299
post #3

Because, like UNIX/Linux itself, worse is better: https://en.wikipedia.org/wiki/Worse_is_better - and perfect is the enemy of "good enough." We want to encourage people to produce written output with minimal friction. Barriers to writing--and especially barriers to producing documentation--should be minimized. Writing well is difficult enough! Markup is overhead. Complex markup is even more overhead. Markdown is the…

> We want to encourage people to produce written output with minimal friction.

What's wrong with .txt ?

Re: Why are we still using Markdown?

#300

This is just like the debate over YAML. In both cases, the language is simple enough, and people use it sanely enough in practice that I just don't care about the warts. Contrast this with something like C++, where the warts are less avoidable and therefore more worthy of notice. Markdown as I use it is functional and simple and no one has suggested an alternative I like better, so I keep using it. Also, as I use it,…

YAML is actually very complex, to the point that basically nobody implements the full YAML 1.2 spec from 2009 (https://matrix.yaml.info/), while 1.1 contains footguns like `country: fr` and `country: no` parsing issues.

Though I agree simple usage is good enough in practice, there are a lot of edge cases that can cause subtle bugs.

Post reply on HN