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.
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.
Comments
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...