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

51–60 of 132 posts

Re: Beyond Markdown (2018)

#51

Post by premysl »

bobbylarrybobby wrote: post #28
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).

The Asciidoctor flavour of AsciiDoc doesn't have a specification. There is only a working group. The parsers are a mess composed of regular expressions.

There are in effect two different versions of AsciiDoc, because Asciidoctor people have appropriated the name while making their own changes to it and marking what they dislike as deprecated.

AsciiDoc cannot express all of DocBook, for example figures with multiple images.

While I despise Markdown, there isn't all that much to be a fanboy of. Just the syntax is overall saner.

Re: Beyond Markdown (2018)

#52

Post by dredmorbius »

cbarrick wrote: post #33
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…

In IPA, slashes are used for abstract phonemic notation ( pronunciation guides). Converting that to would be annoying for certain communities. https://en.wikipedia.org/wiki/International_Phonetic_Alphabe...

There's the concept of escaping notation using a single backslash: \

So:

  **strong text** -> bold "strong text"
  
  \*\*doubled splats\*\* -> "doubled splats" w/ "**" on either side
This is also cumbersome to type, but at least there's a path to what you want to present even if the character is reserved for markup.

Re: Beyond Markdown (2018)

#53

Post by kej »

SoftTalker wrote: post #34
jitl wrote: post #23

Earlier quoted context omitted.

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

Most people don't write file paths. Only a concern for programmers, who should be fine escaping them by whatever mechanism.

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

Re: Beyond Markdown (2018)

#55

Post by dredmorbius »

cratermoon wrote: post #41

Just make it so that literal * has to be escaped, and use a greedy parse. * foo* always means * followed by , and the closing * is missing and would be flagged. foo ... uh oh missing a closing *, can't parse Oh boy, HN mangled this. I'm leaving it as an examplar

You can show string-literal text without HN's markup interpolation by indenting the start of the line by two characters:

  You can show string-literal text *without* HN's markup interpolation by indenting the start of the line by two characters:

Re: Beyond Markdown (2018)

#56

Post by teddyh »

s1mon wrote: post #45
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.

Underlining is an emphasis hack for mechanical typewriters or in handwriting. There's no reason to use it typographically in something which has all the layout possibilities of a modern computer or printer. https://practicaltypography.com/underlining.html

Except to indicate something new and modern which needs its own visual distinction… like hyperlinks. Using underlining as the default for hyperlinks was genius.

Re: Beyond Markdown (2018)

#57

Post by dredmorbius »

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

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>

Re: Beyond Markdown (2018)

#58

Post by blooalien »

doubleunplussed wrote: post #38
SoftTalker wrote: post #34

Earlier quoted context omitted.

Most people don't write file paths. Only a concern for programmers, who should be fine escaping them by whatever mechanism.

And in markdown you chuck them between backticks to indicate they're verbatim text to be rendered in monospace.

> "And in markdown you chuck them between backticks to indicate they're verbatim text to be rendered in monospace."

Only if the intent is for the URL to be copy/pasted, otherwise you enclose the URL in or [text](url) to make it clickable.

Re: Beyond Markdown (2018)

#59

Post by mnot »

Making breaking changes to markdown is about as practical as doing it to HTML -- already existing content and mindshare give the current form massive inertia.

The is especially the case when it works for the vast majority of use cases (or can be hammered into them); ambigiuities are very visible to implementers and detail-oriented folks, but most people never see these issues, or don't care about them.

And, while it sucks that it's complicated to implement, that burden is on relatively few people. See also: the HTML Priority of Constituencies.

Re: Beyond Markdown (2018)

#60

Post by JimmyRuska »

I also made my own editor a long time ago, used it for personal use and on the writing site roleplay.cloud. It had lisp-like syntax, custom expansions. It also had some of these ideas, reference links, I would run code snippets with [python ...]. Normal html code would also work, like [br] instead of

https://web.archive.org/web/20121017064607/http://94.249.190...

https://news.ycombinator.com/item?id=4437875

These days, it would be good to mix/match ideas from: pugjs, htmlx, jupyter, dhall

Post reply on HN