Live data from Hacker News

StrictMark: Markdown, Refactored

doc.replicated.cc

11–20 of 53 posts

Re: StrictMark: Markdown, Refactored

#11

At first glance, there's a lot of words and not many examples. It's hard to quickly see what's different and special about this version of Markdown, other than "it's a formal subset of the other formats". I see some examples for specific elements, but I'd love to see "here's an example demonstrating the problem(s) this addresses", and "here's the fixed version of that example". There could be sub-sections of contrast…

Yep. The [document][1] itself may be a basic example.

[1]: http://doc.replicated.cc/%5EWiki/strictmark.sm?@text "The source code of the doc"

Re: StrictMark: Markdown, Refactored

#13
post #5

It's a good effort, but I'm afraid it isn't a good fit for me, three things stand out: 1) the use of # rather than underline for headings. That why I feel you loose the beauty of the source form - headers disappear visually without a smart editor - if you demand a smart/wysiwyg editor anyway... Might just use a sgml/xml/html subset. 2) one symbol references. This strikes me as overly limiting - why not alphanumeric s…

There are many issues with the use of underline for headings:

1) Constantly fixing them to match the length of the heading, or just suck it up and always use the short form:

    My Heading
    ----
2) You're typing twice as much. I can easily start a line with # to make a heading, vs write the heading line, then carriage return, then add a bunch of dashes to make it a heading.

3) This is the fatal flaw - you only get 2 levels of headings when using underlines.

Re: StrictMark: Markdown, Refactored

#14
post #5

It's a good effort, but I'm afraid it isn't a good fit for me, three things stand out: 1) the use of # rather than underline for headings. That why I feel you loose the beauty of the source form - headers disappear visually without a smart editor - if you demand a smart/wysiwyg editor anyway... Might just use a sgml/xml/html subset. 2) one symbol references. This strikes me as overly limiting - why not alphanumeric s…

> 1) the use of # rather than underline for headings. While in theory I understand the appeal of the "WYSIWYG" syntax of underlining headings, in practice I've always found it less readable than expected. Consider, for instance: I am a paragraph belonging to the previous section but it looks like the heading belongs to me. I am a heading indicating a new section ======================================= I am a paragrap…

I very rarely see this style -- which comes from "Setext", IIRC, which might be patient zero of the "human readable plain text markup styles" -- in the wild anymore, and I suspect it's probably for the reasons you're describing here. I almost never use it myself, except in contexts where the "source file" is just as likely to be read as a rendered HTML version. README files are a good example.

> In some editors/IDE, the underline even gets highlighted / boldfaced, thereby exacerbating this effect.

I think a lot of editors just don't know about this style of heading, but they do know that a line of three or more dashes is used to create a horizontal rule, so they're trying to highlight that.

Re: StrictMark: Markdown, Refactored

#16
Markdown was engineered to be flexible _on purpose_ because it was designed for writers and readers, not programmers.

Writers are less likely to care about what symbol means "bulleted list item", as long as anything that makes sense for it, just works.

It's a mistake to think of Markdown as a programming language, or a "formal grammar".

That being said, if it works for you go for it...

Re: StrictMark: Markdown, Refactored

#17
post #11

At first glance, there's a lot of words and not many examples. It's hard to quickly see what's different and special about this version of Markdown, other than "it's a formal subset of the other formats". I see some examples for specific elements, but I'd love to see "here's an example demonstrating the problem(s) this addresses", and "here's the fixed version of that example". There could be sub-sections of contrast…

Yep. The [document][1] itself may be a basic example. [1]: http://doc.replicated.cc/%5EWiki/strictmark.sm?@text "The source code of the doc"

I kinda got that vibe, but the source should have been way easier to find

Re: StrictMark: Markdown, Refactored

#18
From the spec:

> No double symbols, i.e. strong not *strong*.

I understand the rationale. But, this is immediately no longer Markdown. "It's 'Markdown, Refactored!'" If "refactored" means "incompatible," sure? I guess? But still: incompatible.

"So what?" Good question, imaginary interlocutor. Here's so what: one of Markdown's defining features, love or it hate it, is that it deliberately doesn't make you choose between emphasizing with * characters or emphasizing with _ characters, other than being consistent with the start and end. Use a single * or _ character, get emphasis/italics; use double, get strong/bold; you don't get underlines because you don't use those in typography.

The same is true for lists: only "-" is acceptable, not "+" or "". Fine, but there are a lot of Markdown documents that are out there that use "" as the list character, and I am sure there is at least one weirdo inexplicably using "+".

So StrictMark breaks every Markdown document that uses boldface, and probably about half the Markdown documents that use italics. (I don't know about other Markdown users, but over the years I have not been consistent with how I markup italics, for a variety of reasons.) And, it probably breaks about half the unordered lists in the wild, too.

I understand that this is being done for well-intentioned and noble reasons, but: it ain't Markdown. It's a new, incompatible plaintext markup system. This creates a bit of an uncomfortable point: if I'm going to have to redo all my documents (or just do things The New Way going forward), then why not switch to AsciiDoc or Textile?

Re: StrictMark: Markdown, Refactored

#19

> The unordered list markup symbol is a dash -. The other two Markdown options are * and +. But * is ambiguous and + is unpopular and there must be one way only! THANK YOU for getting rid of the asterisk. As a former org-mode user it has always bugged me when people use the asterisk for lists, not headings. :)

I appreciate your viewpoint, but as someone who has used * out of habit for plain text lists long before Markdown was a thing, this is kind of a big ask. :)
Post reply on HN