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

121–130 of 132 posts

Re: Beyond Markdown (2018)

#121

Post by ilyt »

hsfzxjy wrote: post #20
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?

same difficulty on mine, just switch into alternate character page and both need no shifting or button holding there, no idea what he's on about.

Re: Beyond Markdown (2018)

#122

Post by ilyt »

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…

It's not really problem with being "perfectly specced" or not, it's just matter of inertia.

If markdown just used bold _italics_ at the start, or needed a tag for HTML instead of passing it as is... it would be entirely fine and just as popular now. Or any other generally agreed upon as "good" fix.

But inertia makes things like that near-impossible to change now. Only additions can sorta work and even those are hard as critical mass of dialects needs to apply them for it to work.

Re: Beyond Markdown (2018)

#124

Post by ilyt »

boerseth wrote: post #18
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…

> If the rules are too complicated, then they are a challenge for all parties, both users and implementers.

You are still confouding rules for writing with rules for parsing. It's absolutely possible and easy to make rules making writing easier but parsing harder.

For example, if you make rule that makes formatting markers like **\_ be order insensitive (so **_word**_ formats same as **_word_**), much easier for user, as they don't need to remember order of which the operators were used, harder to code (I assume)

Re: Beyond Markdown (2018)

#125

Post by jitl »

Macha wrote: post #111
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?

Notion users, Reddit users, etc. I will say that forward slashes are still more common in regular english text even among non-programmers than underscores. For example, listing options a/b/c. And you know, URLs.

I don’t really think of Notion as “markdown” but I suppose you’re right since we support a bunch of markdown conventions. Some things are different though like `> ` is a toggle block, and `” ` a quote block. Unfortunately we already abuse / for a command menu, which is by far my least favorite feature. I want to make a setting to disable it but it goes against our anti-settings philosophy.

Re: Beyond Markdown (2018)

#126

Post by eslaught »

evolve2k wrote: post #83
eslaught wrote: post #48

Needs a 2018 in the title. He actually implemented these ideas: https://djot.net/

What a terribly named project. Surely riffing from; Mark, Common or Down would have been more effective.

After the controversy over naming CommonMark (where @jgm et al. caught flak over originally trying to name it Standard Markdown), I'm not surprised that he picked something totally unrelated. And really, it's not Markdown at all at this point, so being more clearly differentiated from Markdown / CommonMark seems like a plus to me.

Re: Beyond Markdown (2018)

#127

Post by dredmorbius »

oneeyedpigeon wrote: post #85
ggm wrote: post #69

Earlier quoted context omitted.

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.

This.

Markdown (or other markup languages, lightweight or otherwise) in general specify semantic document structure.

The presentation or layout are defined by the style and/or stylesheet --- CSS in the case of markdown.

That said, the definition list is intended to be something of a header/content block, as defined by the W3C.

Re: Beyond Markdown (2018)

#128

Post by drawkbox »

majkinetor wrote: post #88
drawkbox wrote: post #66

Earlier quoted context omitted.

> 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.

You can make a separate file that has comments or even another JSON file that has descriptions by JSONPath or key.

Some libs also support comments and trim before processing but I prefer the external/metadata way. Comments add weight.

Re: Beyond Markdown (2018)

#130

Post by MilStdJunkie »

premysl wrote: post #51
bobbylarrybobby wrote: post #28

Earlier quoted context omitted.

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 i…

Ah, DocBook //imageobjectco with something like calspair as well. I've been wanting it badly, but there's zero movement in the Asciidoctor group to try and tackle that beast.

With all due respect, and speaking as an amateur programmer, when it comes to lightweight markup, is there a better way to write a parser besides regular expressions? I suppose it's how the semantics are abstracted.

Asciidoc does get you conditionals and transclusion in the core spec, without needing to resort to extensions. This is what brought me over. That and the XML interoperability.

The Eclipse WG isn't published yet, but, in my opinion, it's a more stable surface to build on than the "many worlds" of Markdown.

Every time someone shows me a cool markdown trick, it requires me to pull something down from github and `npm-install` (or equivalent). But, well, that's kind of the point, isn't it? Markdown's ease of implementation allows a degree of glorious hackery that's just not possible otherwise. While Asciidoctor's great albatross - and its great asset - is Ruby . . which inevitably involves Opal at some point.

Post reply on HN