3 ms·

fyi, HN doesn't support markdown

Terretta 2y ago
> 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.
- PurpleRamen 2y ago
  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.
  - Terretta 2y ago
    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.
    - rmbyrro 2y ago
      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 ^?
      - Terretta 2y ago
        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-supported-in-markdown-fields/ https://github.blog/changelog/2021-09-30-footnotes-now-suppo...
- rmbyrro 2y ago
  Following that logic, wouldn't HN be a runtime for anything written, from assembly to Python? Which sounds... not quite right?

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

PurpleRamen 2y ago
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.
- Terretta 2y ago
  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.
  - rmbyrro 2y ago
    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 ^?
    - Terretta 2y ago
      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-supported-in-markdown-fields/ https://github.blog/changelog/2021-09-30-footnotes-now-suppo...
rmbyrro 2y ago
Following that logic, wouldn't HN be a runtime for anything written, from assembly to Python? Which sounds... not quite right?