Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Beyond Markdown (2018)

johnmacfarlane.net

Post reply on HN
Print view View original

21–30 of 132 posts

Re: Beyond Markdown (2018)

#21

Post by fiddlerwoaroof »

hyperpape wrote: post #7
sqs wrote: post #2

I understand where the author is coming from and respect their contributions to Commonmark. But... There are tons of markup languages for prose that have well-defined specs. So, why did Markdown win? IMO, because it does not have a well-defined spec. It is highly tolerant of formatting errors, inconsistencies, etc. If an author makes a mistake when writing Markdown, you can always look at it in plain text. Whereas a…

> Whereas a perfectly-spec'd markup language would probably evolve toward an unreadable-to-humans mess in the committee-driven pursuit of precision. Maybe, and I mean that sincerely...but are you just saying this must happen or can you actually point to where MacFarlane's proposals would make a significantly less pleasant language?

Requiring a blank line before a sublist just looks wrong.

Re: Beyond Markdown (2018)

#22

Post by ajdude »

egypturnash wrote: post #16

> To dramatically reduce ambiguities, we can remove the doubled character delimiters for strong emphasis. Instead, use a single _ for regular emphasis, and a single * for strong emphasis. I would love to see * gone but I must note that _ is annoyingly hard to type on a screen keyboard. Back in the days of USENET one common choice was using a / to delimit /emphasis/ - the usual reading was that this indicated words th…

I agree. I admit, I still /do this/ for emphasis, and have always wondered why Markdown didn't follow suit.

Re: Beyond Markdown (2018)

#23

Post by jitl »

egypturnash wrote: post #16

> To dramatically reduce ambiguities, we can remove the doubled character delimiters for strong emphasis. Instead, use a single _ for regular emphasis, and a single * for strong emphasis. I would love to see * gone but I must note that _ is annoyingly hard to type on a screen keyboard. Back in the days of USENET one common choice was using a / to delimit /emphasis/ - the usual reading was that this indicated words th…

But I like to write paths like /usr/bin/ in my text and don’t want to worry about backtick code quoting them every time

Re: Beyond Markdown (2018)

#24

Post by jitl »

throwawaaarrgh wrote: post #15

> All of these rules lead to unexpected results sometimes, and they make writing a parser for CommonMark a complex affair. > What if we tried to create a light markup syntax [..] revising some of the features that have led to bloat and complexity in the CommonMark spec? Are you writing this new format to make life easier for the humans using it, or the humans programming it? It's sad when programmers don't see the fo…

I am flamfoozled by paragraph-in-list and list-indentation regularly in status quo markdown. Maybe it’s because the syntax is a little weird for the edge cases today? Or maybe I’m just a goof who needs to go read GitHub’s parser source.

Re: Beyond Markdown (2018)

#25

Post by jitl »

fiddlerwoaroof wrote: post #21
hyperpape wrote: post #7

Earlier quoted context omitted.

> Whereas a perfectly-spec'd markup language would probably evolve toward an unreadable-to-humans mess in the committee-driven pursuit of precision. Maybe, and I mean that sincerely...but are you just saying this must happen or can you actually point to where MacFarlane's proposals would make a significantly less pleasant language?

Requiring a blank line before a sublist just looks wrong.

I couldn’t figure out what was meant by a sublist. Like any hierarchy? Or just list-in-paragraph-in-list, not list-in-list? That one could use some HTML disambiguation in the article.

EDIT: yeah it’s always required. That kills me.

Re: Beyond Markdown (2018)

#26

Post by bobbylarrybobby »

loloquwowndueo wrote: post #19
egypturnash wrote: post #16

> To dramatically reduce ambiguities, we can remove the doubled character delimiters for strong emphasis. Instead, use a single _ for regular emphasis, and a single * for strong emphasis. I would love to see * gone but I must note that _ is annoyingly hard to type on a screen keyboard. Back in the days of USENET one common choice was using a / to delimit /emphasis/ - the usual reading was that this indicated words th…

Do you have some reference for “simple swipe on B”? Doesn’t work for me (not that simple I guess?)

They're probably referring to the iPad keyboard (https://www.ghacks.net/2019/08/02/how-to-enable-the-swipe-ke...)

Re: Beyond Markdown (2018)

#27

Post by mindwok »

axblount wrote: post #4
sqs wrote: post #2

I understand where the author is coming from and respect their contributions to Commonmark. But... There are tons of markup languages for prose that have well-defined specs. So, why did Markdown win? IMO, because it does not have a well-defined spec. It is highly tolerant of formatting errors, inconsistencies, etc. If an author makes a mistake when writing Markdown, you can always look at it in plain text. Whereas a…

Also, "worse is better" https://en.wikipedia.org/wiki/Worse_is_better

Nice, I didn't know there was a term for this.

I completely agree. My favourite software is not just functional, it also is opinionated and expresses a philosophy on how to do something. Simply adding flexibility forever in a quest to be useful for everyone ends up making it useful for no-one.

Re: Beyond Markdown (2018)

#28

Post by bobbylarrybobby »

sqs wrote: post #2

I understand where the author is coming from and respect their contributions to Commonmark. But... There are tons of markup languages for prose that have well-defined specs. So, why did Markdown win? IMO, because it does not have a well-defined spec. It is highly tolerant of formatting errors, inconsistencies, etc. If an author makes a mistake when writing Markdown, you can always look at it in plain text. Whereas a…

Asciidoctor has a spec, reads pretty similarly to markdown, and is infinitely better IMO. And it (well, AsciiDoc) predated markdown!

I think markdown won because it was specifically made with HTML output in mind, instead of arbitrary output (docbook, in the case of AsciiDoc, which is pretty much infinitely malleable).

Re: Beyond Markdown (2018)

#30

Post by qingcharles »

egypturnash wrote: post #16

> To dramatically reduce ambiguities, we can remove the doubled character delimiters for strong emphasis. Instead, use a single _ for regular emphasis, and a single * for strong emphasis. I would love to see * gone but I must note that _ is annoyingly hard to type on a screen keyboard. Back in the days of USENET one common choice was using a / to delimit /emphasis/ - the usual reading was that this indicated words th…

I really like your proposal, but in the days of USENET the // wasn't interpreted by the machine but simply by our minds, just like * for bold. Would there be any extra issues caused by italics being / rather than *?

I'm honestly with you on this and I'm in the middle of building a huge Markdown site where I have the freedom to change the syntax now if I want.

Post reply on HN