Heather

Platforms that use Markdown-like syntax for formatting text but aren't actually compatible with Markdown. Gaze with me into the maw of madness:

These aren't even consistent enough that I can reliably remember "okay I should always use this one particular syntax for italics and that at least will always work". Nothing will always work. Life is suffering. At least Cohost is an island of standards-compliance in an ocean of nightmares.

my original philosophy behind this as someone pushing 40 was that my canonical ASCII renderings of bold, italic, and underline are *bold*, /italic/, and _underline_, which doesn't agree with any other site on the internet, so we might as well at least obey CommonMark

Or rather, it is following a completely different lineage that predates Markdown. Google Chat is copying, among other things, MSN Messenger¹ and that is 5 years older than Markdown is. Markdown allowing _italic_ or *italic* feels like it is probably specifically appeasing chat apps using _italic_ even if it favours *italic*.

Underline and italic often traditionally had the same syntactic meaning. In Copy-editing you signal that something should be italicized by underlining it and apparently some publishers still use underline to mean italic pre-typesetting.

John Gruber chose wrong and now we all have to suffer for it²

1. I'm assuming they took it from ICQ or AIM. And that one of those two got if from an earlier predecessor. I just know MSN did it because I was trying to work out where I picked up that convention just last week.

2. There is a decent argument to make that in text where underscores may reasonably appear within words (e.g., variables, usernames), having underscore italicize causes too many problem.

See -- markdown isn't for chat app or even medium-Posting, really. It's for document (and documentation) writing, and it's sort of rough for Posting Ergonomics that aren't the Longpost, and great for Longer Form Stuff -- need to do a table? just make an ascii one, it will format it. Etc.

In terms of underscores and asterisks being interchangeable, it's perhaps a little nonsensical to have * and _ do the same thing, unless you also have underline. There were a few specs that included underline as 3 underscores or asterisks, in the 2010s, I think reddit being the leading one of them.

Then, it becomes clear -- What if you need to have bold, underline, and italics? How do you make that easy to edit for the post-writer? Not having to count characters, and instantly recognizable on a skim of the 'source code'?

You simply would do:

_**___This___**_ or *__***This***__*.  

You could of course do 
_____*this**_____ 
but it's way less readable.

This is also why you need to put two spaces after every linebreak on cohost -- Sometimes you want to split lines in the source, but have them be a combined line in the final post. These are concessions made for ease of re-use and editing and multiple people using the file, not reading/writing themselves.

Is that good? No. Is that bad? Not really. It's just the way things are, and maybe the context helps someone, or at least makes it easy to understand why things are the way they are, and through that, how to work around it.

Mostly CoHost just needs an IDE. No no, hear me out:

Wait why are you leaving.

edit: So there's been talk in the comments and shares -- I'm going to post this, which i posted as a reply in the comments, to maybe FAQ some of this

my understanding is a big part of the problem is that the '/' symbol being used would make markdown way harder to parse, because it needs to live beside HTML, and / is the closing tag character.

= too. So what you've got left over, essentially, is 'everything not used commonly by HTML to delineate tags', which leaves you with

*
_
+
-
|
`
.

and some others I'm sure I'm forgetting. Markdown makes a lot more sense when 'it has to be parsed, alongside HTML, in the same document'. For better and for worse.

There's a learning experience I recommend everyone who does computers try, which is that in the python track of Exercism, there's a problem involving someone's half formed, terrible regex for parsing markdown input being dropped in your lap. Your job isn't to impliment a good markdown parser. It's to make the one you were given work. It is soul crushing. You will understand basic regexes by the end of it. You won't understand how to parse markdown, not really.