31–40 of 53 posts
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...
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...
I think I see the appeal of specifying a robust subset of markdown, something that you can trust will probably be parsed the same way for as many dialects as possible.
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...
lists are one of markdown's weak points though with numbered lists completely ignoring the numbers
I would hate to have to change 30 numbers because i want to move an item from last to first.
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...
One downside of markdown being so flexible is that it's hard to remember if a given dialect implements a certain feature, or how it will handle a certain corner case I think I see the appeal of specifying a robust subset of markdown, something that you can trust will probably be parsed the same way for as many dialects as possible.
What also annoys me is that they didn't base it off Wiki formatting. It would've been great if it had at least some compatibility for basic stuff like headings and links.
http://doc.replicated.cc/%5EWiki/strictmark.sm?@text
http://doc.replicated.cc/%5EWiki/strictmark.sm
So obviously an implementation was made, but whoever wrote the article didnt bother to share the implementation.
The opinionation that removes synonyms will kill any chances of this working with legacy IMO. Any significant doc base will hit myriad issues that come down to "I didn't like that form of it." I was initially OK with the idea of a parseable subset, which would be useful, but this goes too far with a "one way only" attitude. No thanks.
That said, someone should do what the project claims to do, without gutting the language. A formalized subset of CommonMark that only skips formally indescribable specs but otherwise preserves everything else would be useful in some situations. It might even become the defacto CommonMark spec if it's easier to implement.
Earlier quoted context omitted.
> 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,…
Perl program https://sourceforge.net/p/rosegarden/code/HEAD/tree//branche...
Documentation https://sourceforge.net/p/rosegarden/code/HEAD/tree//branche...
I wonder now how much of this was picked up unknowingly from Setext-derived documents.
The author is here, AMA.