61–70 of 132 posts
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.
I think many/most people use slashes more often than they use asterisks, however.
Earlier quoted context omitted.
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.
And again, this complaint will only be relevant in contexts where this specific convention is used.
> 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…
I agree. I admit, I still /do this/ for emphasis, and have always wondered why Markdown didn't follow suit.
> While Markdown’s syntax has been influenced by several existing text-to-HTML filters — including Setext, atx, Textile, reStructuredText, Grutatext, and EtText — the single biggest source of inspiration for Markdown’s syntax is the format of plain text email.
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.
Most people don’t write markdown! What’s the demographic of markdown writers who don’t write file paths? Bloggers?
Oh yes. I made the fun decision to write a markdown parser/contenteditable component for https://sqwok.im and ended up spending probably a month on it, largely writing endless unit tests and covering odd cases like that.
It's far from perfect and probably will still break on certain ambiguous inputs. I like his ideas for clarifying the language for the most general audience.
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…
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, object, lists. From there any data or types can be serialized or filled. With JSON you can do types via overloads/additional keys, you can add files by url/uri or base64, and any additional needs using parts of basic JSON. Even large numbers can just be strings with type defs as additional keys/patterns. Financial data can just use strings or ints with no decimal largely because this is the safest way to store financial data to prevent float issues.
KISS is life and sometimes things are just done, no improvements needed. Now you can take JSON and add things on top of it if you want. Same with Markdown. The base doesn't need to change... ever.
Don't SOAP my JSON. Don't HTML my Markdown. Though you can add specs (JSONSchema/OpenAPI) and formatting tools on top in a processing step. For messaging and base content, they are perfect, simple, clear, concise and no need to change.
> 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…
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
You mean a definition list like the HTML native one?
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 >
I meant
-a the minus aflag text
-b the minus bflag text
Something the something text
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…
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
fan~_tas_~tic