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

11–20 of 132 posts

Re: Beyond Markdown (2018)

#11

Post by avgcorrection »

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…

This is only perhaps correct in that a loosey-goosey proposals can spread farther because it is seemingly simple to implement (less MUST and whatever) and by the time you notice inconsistencies between implementations, the thing has reached a sort of critical mass already and the things aren’t that inconsistent so you just shrug and say whatever.

But in the case of MarkDown the original implementation was just not that great. Which has nothing to do with being easier; MacFarlane’s Djot is an easier to implement and easier to describe language.

And of course your point about “committee-driven pursuit of precision” is just a made up hypoethical which is not worth responding to. (The only committee has been on CommonMark, which is a definition of “MarkDown” (TM) which merely tries to deal with years of drift between different MarkDown implementations. With their famously long-winded spec-by-prose-enumeration style.)

Re: Beyond Markdown (2018)

#12

Post by avgcorrection »

anschwa wrote: post #10

Personally, I would like to see a markdown spec that eliminates parsing ambiguity by restricting the "edge-case" features that HTML is really much better at describing in a standard and structured way. I think we could pick one way to handle emphasis, lists, and code blocks that covers a specific and predictable 80%. Anything that becomes hard to describe without including additional notation to the grammar is probab…

https://github.com/jgm/djot

Re: Beyond Markdown (2018)

#13

Post by ninepoints »

giraffe_lady wrote: post #9
ninepoints wrote: post #3

Earlier quoted context omitted.

I'd argue that it won the adoption it did in spite of parsing ambiguities and the lack of a spec. Not because of it. There are plenty of examples of well specified things that have gained mass adoption, so I think you are confusing cause and correlation here.

Well-specified formats that are primarily produced by humans writing them by hand? The main entries in this category are programming languages .

IDK, JSON? HTML and XML are markup languages also. There are obvious issues with markdown that were fixed/resolved in various markdown variants, and missing features as well that I don't think anyone could argue helped adoption. Case in point, the most commonly used markdown flavor is GFM because we all adopted GitHub and that was what they support.

Re: Beyond Markdown (2018)

#14

Post by ggm »

I wish more markdowns accepted some notation for keyword bullet lists. Indented lists which mark with a bolded or emphasised term.

If you can do this, you can write manual pages for options or flags

Re: Beyond Markdown (2018)

#15

Post by throwawaaarrgh »

> 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 forest for the trees.

Re: Beyond Markdown (2018)

#16

Post by egypturnash »

> 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 that would normally be rendered as /italics/. You'd often see it used to indicate the titles of books and movies, as well, since the typographical convention was typically that these were italicized as well - note that both and typically render as italics, for instance. I have always disliked Markdown's choice to use * as a delimiter for both italics and bold; / always implied italics to me, and * always implied bold.

Anyway. I propose that / would be a much better delimiter for emphasis than _. On a US keyboard, it can be typed without a shift key. And on a US IOS screen keyboard, it is a simple swipe on B, versus shifting to the numeric entry page and swiping on &.

Re: Beyond Markdown (2018)

#17

Post by prepend »

I write a lot of markdown. Ive taught lots of people to use it. I’ve never encountered these problems.

Markdown is meant to be simple. To represent complex things, use something else.

I don’t think I’ll ever use this and if someone tries to make me learn this instead of regular markdown, I’ll probably just not bother.

I don’t want to diminish anyone’s creativity, but this seems like a lot of work put into something unnecessarily.

Re: Beyond Markdown (2018)

#18

Post by boerseth »

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…

If the rules are too complicated, then they are a challenge for all parties, both users and implementers. I think it is useful to be able to imagine at least on some higher level what a parser would do to the stuff I write, so everyone benefits from the ease of understanding that comes with simpler rules. The question is just how far we can simplify without reducing usability.

The rest of the article frequently takes the side of the users, and mentions how confusing certain existing rules are to them. I know I frequently don't know what to expect from Markdown in certain corner cases, and felt vindicated by the author calling them out here. Some of their ideas for simplification would surprisingly even let us do things that are currently not possible.

Re: Beyond Markdown (2018)

#19

Post by loloquwowndueo »

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?)

Re: Beyond Markdown (2018)

#20

Post by hsfzxjy »

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…

Why would a _ be harder to type than a * on a screen keyboard?
Post reply on HN