Earlier quoted context omitted.
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 ¾?
Only if you can do that for, say, 937\/997.
Beyond Markdown (2018)
91–100 of 132 posts
Re: Beyond Markdown (2018)
#92I 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…
> Whereas a perfectly-spec'd markup language would probably evolve toward an unreadable-to-humans mess in the committee-driven pursuit of precision. This proposal shows us a clear step in that direction, going from something simple and easy for humans to understand, with complex implementation, to emphasize part of a word: fan*tas*tic To proposing a simple implementation that's... weird for humans: fan~_tas_~tic
It seems like a minor concession since most uses of intra-word emphasis are more cutesy than communicative[1] (it is of course sometimes very useful when there is a subtle syllable emphasis, or a suble typo that you want to point out).
[1] Maybe I’m being a hypocrite here? I definitely am in favor of a lot of “cutesy” ways to communicate (things that are more stylistic than necessary). But not intra-word emphasis, really.
Re: Beyond Markdown (2018)
#93I 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 li…
I agree that empty line in front of a nested list is ugly. I very often make hierarchical descriptions of things like events or things to do or recipes and that kind of thing would be annoying to have to deal with. I like my lists tight.
I would have tried harder to find some other way to make the grammar simple.
I haven’t seen anything else (in addition) that makes it less “human readable” though.
Re: Beyond Markdown (2018)
#94This is why I like the way Racket does this with the Pollen language. You can use Pollen mark up and create your own tags and then decide how they are converted. It all becomes a list of X-expressions that can be manipulated in any form you like. But the tree nature of an X-expression means you don’t get issues like *strong* word*.
For example I can write ◊bold{strong* word} and it becomes (bold “strong* word”). It’s very clear how this should be rendered.
Re: Beyond Markdown (2018)
#95I 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…
What you're saying is that the most stupid and broken "solutions" win…
Now one could speculate about the reasons.
Re: Beyond Markdown (2018)
#96I 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 ca…
SGML is a hot mess. It should have died decades ago.
Re: Beyond Markdown (2018)
#97Re: Beyond Markdown (2018)
#98Re: Beyond Markdown (2018)
#99Is there any great modern rich document alternative? That wound truly go beyond markdown
Asciidoc is the best option if you need a bit more than Markdown.
Re: Beyond Markdown (2018)
#100I 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…
I think JSON and Markdown are very different, in fact.
JSON is very strict. It won't let you have a comma after the last element of a list, for instance (which is very annoying in many cases). It won't let you add comments in any way, shape or form. It won't let you use single quotes instead of double quotes. Or forget quotes in keys. Or mess with case in null / true / false. Or use NaN values.
Markdown is ill-defined, and will happily let you do whatever the hell you want.
JSON is made for programs, and is a PITA to write as a human (for the reasons mentioned above). But a pleasure to parse and (to some extent) generate automatically. It's not very good with text.
Markdown is made for humans, and I'd hate to have to parse a markdown file and do something with its content other than basic formatting. It's bad at anything but text.