Nested code fences in Markdown (susam.net)

> In fact, a code fence need not consist of exactly three backticks or tildes. Any number of backticks or tildes is allowed, as long as that number is at least three

Unfortunately, some markdown implementations don't handle this well. We were looking at using code-fence like syntax in Rust and we were worried about people knowing how to embed it in markdown code fences but bad implementations was the ultimate deal breaker. We switched to `---` instead, making basic cases look like yaml stream separators which are used for frontmatter.

All this complication seems to stem from the simple fact, that the fences don't have a recognizably distinct start and end marker. It's all "`" or "~", instead of one symbol at the start and another, different symbol at the end. And then going into the different numbers of backticks or tildes. Why add such ambiguity, that will only make it harder to parse things correctly? This immediately raises the question: "What if I start a block with 4 backticks and end it with 5?"

All these complications would have been avoidable with a more thought through design/better choices of symbols. For example one could have used brackets:

    [[[lang
    code here
    ]]]

And if one wanted to nest it, it should automatically work:

    [[[html
    html code
    [[[css
    css code
    ]]]
    [[[js
    js code
    ]]]
    html code
    ]]]

In case one wants to output literally "[[[" one could escape it using backslash, as usual in many languages.

In a parser that would be much simpler to parse. It is kind of like parsing S-expressions. There is no need for 4 backticks, 5, or any higher number. I don't want to sit there counting backticks in the document, to know what part of a nested code block some code belongs to. It's a silly design.

I might be able to use this, especially in LLMs where I ask them to give me things in code fences all the time. If I ask for markdown in a code fence, it all falls apart. If, however, I asked for markdown in a ~~~ code fence, or even ~~~~~, all would be right with the world, since they typically use ```.

Markdown's parser seems to be a fascinating anomaly: a specification that consists entirely of exceptions and corner cases.

I love hacker news! You learn something useful here and there.

I always used html elements like <pre /> and <code /> to go around this in the past

I realize that it would be somewhat antithetical for markdown, but I increasingly feel that length-prefixing everything makes lot of stuff easier at pretty low cost. Anything depending on delimiters or start/end tags inevitably ends up with difficult quoting rules or some other awkward scheme (like seen here).

[dead]

I will use it as a rendering benchmarking for mdview.io https://mdview.io/#mdv=N4IgbiBcCMA0IBMCGAXJUTADrhzWOAtgnjgMI...

This is also how you handle adding code blocks in GitHub comment suggestions, fwiw.

    ````suggestion
    This example should instead be:

    ```basic
    10 PRINT "LOL"
    20 GOTO 10
    ```
    ````

  `````ts
  const Accordian = styled.details<{ isAprilFirst: boolean; }>`
  ````css
    accent: rebeccapurple;
    font-family: ${
  ```js
      props => props.isAprilFirst ? 'Comic Sans' : 'Time New Roman'
  ```
    };
  ````
  `;

  `````

I faced this problem when designing my own notation [1].

Solved it by surrounding code with more ticks than maximum number of consecutive ticks inside its text. This allows arbitrary nesting.

Postgres solves it by using `$something$ whatever $something$` [2].

[1] https://github.com/PratikDeoghare/brashtag [2] https://www.postgresql.org/docs/current/sql-syntax-lexical.h...

#+BEGIN_SRC lolcode

blah

#+END_SRC

org-mode to the rescue ;p

Markdown assumes the user won’t do anything silly, and I’m fine with that. Rather the people enabling such behaviour are annoying.

TIL about triple curlies! mind blown

I hoped this would have some discussion of the design rather than simply saying how to do it, because I already knew (because it's come up on Stack Overflow / Stack Exchange meta a few times).

Ah, YAML and Markdown, two beautiful accidents of tech. It still boggles my mind that we collectively couldn’t come up with a post hoc spec and fix all the warts with a strict parser for either of them. Sure, it would break quite a bit of existing stuff, but the pain would probably be worth it.

Markdown is so fragile. When you start combining tables, code blocks, and collapsible sections it falls apart. I wish there was a robust way to emit GFM from something more solid.

Didn't know this. It kind reminds me of MIME multipart messages (used in email attachments, MMS, etc.) where the header includes a "boundary" tag which the parser will look for to terminate the part. It feels strange, like it could be some injection risk where if the file knew what the boundary was going to be, it could desync the bounds and turn one malicious, inactive file into one or more bad files.

C# has this same model:

https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...