> HN doesn't support markown

Oh, but it does, it's just plaintext with classic “[squared](circle)” convention: clickable inline (references) following [annotated clauses]. We can read the term, and click the ref.

Markdown's point is if plaintext is supported, so is Markdown.

If it's not rendered, then it's not supported. This is very obvious in this case, where the square-brackets have no additional value, but make it just harder to read the text. The links are getting rendered independent of the brackets, so markdown-syntax has no function here.

I think most markdown symbols add semantic comprehension or emphasis value in _plain_ text. That is functional[^1] even here.

Including the squared circle for inline links.

[^1]: As in functional requirements, is serving to convey the markup intent in a non rich text rendering.

Something tells me you felt clever posting this. If you're open to a different perspective:

The underscore makes your text worse to read, IMO. Same with the MD anchor syntax.

HN supports italicizing by wrapping an expression with asterisks *. Why insist on a foreign standard?

HN commenters use the [{i}] notation all the time for footnote referencing. Which can be used for links, declutttering the main text.

Why add a ^?

Certainly, italics in asterisks, but underscores are valid too in plain text, double either to get bold. I wanted the _underscore_ since I was talking about plaintext and didn't want it disappeared, though I *suppose* this works too.

^ means superscript, as footnote numbers are in publishing, but more importantly, https://github.blog/changelog/2021-09-30-footnotes-now-suppo...

Following that logic, wouldn't HN be a runtime for anything written, from assembly to Python? Which sounds... not quite right?