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

81–90 of 132 posts

Re: Beyond Markdown (2018)

#81

Post by atoav »

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…

I had a look at djot, which adresses all of the author's grievances and I must say... I don't like it.

Sure, it probably is easier to parse, and maybe there are a few edge cases that it does better, but the goal of markdown is to have text that is:

A) human readable and looks good without parsing it

B) can be parsed and presented using different themes

In djot they sacrifice a lot (e.g. we now have to insert empty lines in a nested list?!) of point A for questionable gains at point B. Guess what I as a user care more about?

Markdown accepting a wide range of inputs is not a mistake, it is a feature. If that makes parsing more complex that is an acceptable side effect not a mistake.

Re: Beyond Markdown (2018)

#82

Post by oneeyedpigeon »

simonklitj wrote: post #61
kej wrote: post #53

Earlier quoted context omitted.

I think many/most people use slashes more often than they use asterisks, however.

Sure, but a slash before and after a word? I don’t think that’s common outside of file paths.

Not even common including file paths, unless you mean directory paths. Even then, only necessary if you really want to unambiguously indicate a directory in the path itself.

Re: Beyond Markdown (2018)

#84

Post by zmix »

melagonster wrote: post #64
jitl wrote: post #47

Earlier quoted context omitted.

Most people don’t write markdown! What’s the demographic of markdown writers who don’t write file paths? Bloggers?

this may be a huge number, because Evernote and a lot of note applications relying on markdown.

> Evernote

Since when?

Re: Beyond Markdown (2018)

#85

Post by oneeyedpigeon »

ggm wrote: post #69
dredmorbius wrote: post #57

Earlier quoted context omitted.

There is an extended syntax for that: First Term : This is the definition of the first term. Second Term : This is one definition of the second term. : This is another definition of the second term. https://www.markdownguide.org/extended-syntax >

How this renders is suboptimal to me. It's like a variant of heading. I meant -a the minus aflag text -b the minus bflag text Something the something text It's basically table or grid layout without lines.

That's a CSS issue rather than anything to do with markdown or the markup it generates.

Re: Beyond Markdown (2018)

#86

Post by oneeyedpigeon »

toastal wrote: post #68
ggm wrote: post #14

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

> keyword bullet lists You mean a definition list like the HTML native one?

I'm sure they mean DLs, yes - this is the one thing I always bemoan that markdown lacks, even more so than tables.

Re: Beyond Markdown (2018)

#87

Post by tannhaeuser »

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…

> messy HTML5 over "XHTML"

Nothing messy about HTML, whatever version. It just uses SGML features from a more civilized age, such as inferring tags not explicitly present when unambiguously required by the content model grammar.

Btw a large fragment of markdown can be implemented using SGML's SHORTREF feature, as can customizations such as GitHub-flavored markdown. John Gruber's markdown language is specified as a canonical rewriting into HTML with the option of inline HTML as fallback, making SGML SHORTREF a particularly fitting implementation model since it works just the same. It's quite striking how a technique for custom syntax invented in the 70's (however imperfectly specified, though not in a worse-is-better way lol) could foresee Wiki syntaxes and also determine the most commonly used markup language (HTML) fifty years later.

Agree with the gist of your post, though. As fantastic as MacFarlane's pandoc is, the idea to re-assign redundancies in markdown (eg. interpret minute presence/omission of space chars to mean something) was bound to fail, and that was very clear to me skimming only through a few paragraphs of the CommonMark manifesto. When it was first discussed here back then, someone commented that this was bound to happen when a logician (McFarlane) approached Wiki syntax.

Re: Beyond Markdown (2018)

#88

Post by majkinetor »

drawkbox wrote: post #66
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…

> IMO, because it does not have a well-defined spec. Same reason that JSON won. JSON and Markdown are base standards that were generated by market need to simplify. JSON won because it was not overly complex and there was some flexibility. If you need more go YAML or use JSON as a platform for more. Every attempt to change JSON has and should be shot down. JSON really just has basic CS types: string, int/number, bool…

It should at least have comments. Then it can freeze.

Re: Beyond Markdown (2018)

#89

Post by avgcorrection »

jitl wrote: post #23
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

This is a real problem considering that some programmers are just sloppy with code-quoting paths and such. And it’s even debatable whether (sort of stylistically) you should even code-quote paths.

Re: Beyond Markdown (2018)

#90

Post by avgcorrection »

defrost wrote: post #37
SoftTalker wrote: post #32

Earlier quoted context omitted.

I'd like to see *this is bold* /this is italics/ _this is underlined_ Beyond simple conventions like this, I'd just as soon drop into HTML as deal with some other markup that ends up being just as complex. We don't need to allow permutations and combinations such as bold and italics, double-weight bold, etc. these never occur in normal prose typesetting and if you need it just use HTML for those rare cases.

As a point of order; \* more than 3\/4's of people may not feel that way, particularly those discussing snake\_case Vs CamelCase

You mean ¾?
Post reply on HN