111–120 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.
Most people don’t write markdown! What’s the demographic of markdown writers who don’t write file paths? Bloggers?
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.
> 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…
But I like to write paths like /usr/bin/ in my text and don’t want to worry about backtick code quoting them every time
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…
> Every attempt to change JSON has and should be shot down. I really wish JSON allowed for final trailing commas in arrays/objects. It would make for more readable diffs, simpler text templating, easier writing/parsing for us humans, etc. I'd happily trade all of TOML, YAML, XML, and every other similar format in existence for that one change.
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…
You are completely right. The underlying theme here is that the requirements matter. The requirement for Markdown is to be simple and easy. It's intended for use by people who are going to ignore whatever specs and documentation there are. They'll write a little comment, a bug ticket, or a readme and they might need things like links, bold, italic, etc. And the job is to turn that into some legible HTML. So most of i…
Or the lowest.
This is how populist politics works. The thing that appeals to the most people isn't necessarily the thing we should be doing.
The internet and web appealed to a small percentage of people in the early 90s, and it was glorious. You had to put in effort to get anything out, which meant most people didn't bother, which meant it was a nice place. The music industry similarly had a high level of entry. Both are filled with crap now.
Elitist old man shouting at clouds? Maybe. Doesn't mean I'm wrong though.
> 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…
Fuck no. Same idiocy as turning -- into long em, makes writing any technical posts mighty annoying
Get better screen keyboard. On mine _ doesn't require shift, neither does *
Earlier quoted context omitted.
But I like to write paths like /usr/bin/ in my text and don’t want to worry about backtick code quoting them every time
There's the same problem with variables and filenames containing 2+ underscores, resulting in unwanted italics.
> 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…
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...
Earlier quoted context omitted.
I really like your proposal, but in the days of USENET the // wasn't interpreted by the machine but simply by our minds, just like * for bold. Would there be any extra issues caused by italics being / rather than *? I'm honestly with you on this and I'm in the middle of building a huge Markdown site where I have the freedom to change the syntax now if I want.
I'd like to see *this is bold* /this is italics/ _this is underlined_ Beyond simple conventions like this, I'd just as soon drop into HTML as deal with some other markup that ends up being just as complex. We don't need to allow permutations and combinations such as bold and italics, double-weight bold, etc. these never occur in normal prose typesetting and if you need it just use HTML for those rare cases.
underlines is not used enough to take the commonly used character ~this is fine~, trailing tilde is rare enough