| ▲ | Nested Code Fences in Markdown(susam.net) |
| 90 points by todsacerdoti 3 hours ago | 18 comments |
| |
|
| ▲ | starkparker 14 minutes ago | parent | next [-] |
| 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
```
````
|
|
| ▲ | chuckadams an hour ago | parent | prev | next [-] |
| Markdown's parser seems to be a fascinating anomaly: a specification that consists entirely of exceptions and corner cases. |
| |
| ▲ | metalliqaz 29 minutes ago | parent [-] | | lol this is a great wording for something I've not been able to express before I sometimes wonder... is it Markdown's specification chaos the reason for its success? Maybe it was just barely enough spec to be usable but also small enough to allow anyone to make an implementation that seemed right. No qualifications to fail. Thus, it proliferated. The xkcd[1] problem is a darn shame, though. At least CommonMark exists for people who want to point to a "Standard" [1] https://xkcd.com/927/ | | |
| ▲ | TimorousBestie 26 minutes ago | parent [-] | | Markdown is definitely a case of “worse is better” and it helped that it was half-canonicalizing ASCII formatting workarounds that had been in common use for decades. |
|
|
|
| ▲ | pratikdeoghare 14 minutes ago | parent | prev | next [-] |
| 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... |
|
| ▲ | mohsen1 an hour ago | parent | prev | next [-] |
| 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 |
|
| ▲ | Igor_Wiwi 19 minutes ago | parent | prev | next [-] |
| I will use it as a rendering benchmarking for mdview.io https://mdview.io/#mdv=N4IgbiBcCMA0IBMCGAXJUTADrhzWOAtgnjgMI... |
|
| ▲ | codazoda an hour ago | parent | prev | next [-] |
| 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 ```. |
|
| ▲ | zokier 41 minutes ago | parent | prev | next [-] |
| 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). |
|
| ▲ | zelphirkalt 2 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | _ache_ a minute ago | parent | next [-] | | Do you realize that your solution is basically to use a tag, which is why Markdown have been developed, to not use them. The classic way in markdown to insert block of code is to indent the code. | |
| ▲ | charles_f an hour ago | parent | prev | next [-] | | Your solution for the problem described here is to escape with a different character. MD's is to add more special characters. Both are valid and exist in other languages, I wouldn't qualify one as better thought than the other - though since we're talking about text that I don't want modified, if I prefer adding ticks rather than going into the text and escaping them one by one. The complication doesn't stem from lack of distinct start and end, what you are trying to solve for here, is when you have multiple languages in a single block, and want pretty colors on each. Seeing that HTML doesn't support imbrication of pre tags (or rather doesn't render one embedded in the next), that would probably not work without producing something that is not pure html. > In a parser that would be much simpler to parse Parsing a variable number of ` is not more complex than looking ahead for a closing boundary. In fact, once you introduce escaping characters, you need to handle escaping of the escaping character, which is slightly more complex. | | |
| ▲ | zelphirkalt 6 minutes ago | parent [-] | | The syntax highlighting of the code of each language itself is not the problem. This post is about markdown. A typical markdown parser doesn't do syntax highlighting for code blocks. That's usually done by some other library, like for example pygments. The issue is about markdown syntax. What happens on another language's level does not concern the markdown parser. | | |
| ▲ | charles_f 4 minutes ago | parent [-] | | That's exactly my point, the solution you're discussing is about something else, and not relevant to what's discussed in this post. |
|
| |
| ▲ | armchairhacker an hour ago | parent | prev | next [-] | | > In case one wants to output literally "[[[" one could escape it using backslash, as usual in many languages. Sometimes you want to paste a large region of code into a code block, and escaping the content is harder than fixing and start and end delimiters. This matters particularly in Markdown, where embedding large regions of code or text is common, whereas other languages you’d put it in its own file. So I still suggest the ability to change the number of open and close brackets. Then you’ll also need an implicit newline or other way to distinguish content that starts with an open bracket. | |
| ▲ | embedding-shape 2 hours ago | parent | prev [-] | | Indeed! Last time I dealt with this exact problem in a toy application made for myself, I ended up making the markdown parser only read ```$LANG syntax, and making it assume just ``` is a closing tag, not accepting it as a opening tag. Made it easier for the pretty syntax formatter to do it's job too, as it no longer has to figure out the language. |
|
|
| ▲ | epage 2 hours ago | parent | prev [-] |
| > 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. |
| |
