Skip to content
This repository was archived by the owner on Oct 30, 2023. It is now read-only.

Conversation

@gawhyte
Copy link

@gawhyte gawhyte commented Aug 5, 2015

https://help.github.com/articles/github-flavored-markdown/#fenced-code-blocks

I think this would be a handy feature, but I understand if you don't want to poison the implementation with Markdown dialects.

I modified sub _DoCodeBlocks to do two passes. First it tries to find any fenced code blocks using code adapted from sub _DoCodeSpans, hashes them, then proceeds to perform the traditional codeblock check. I did not write any new tests, but it continues to pass existing ones.

@bobtfish
Copy link
Owner

I'm down with accepting this, but can you add a new test that tests this syntax?

@rlauer6
Copy link

rlauer6 commented Nov 14, 2022

btw - this PR fixes another issue - it would be great if it could be merged in and CPAN updated...

Here's some markdown that demonstrates the bug...

1. Line 1
1. Line 2
1. Line 3 with code block

   ```
   line 1
   line 2
   ```
1. Line 4 with code block

   ```
   a line
   
   a line after a blank line
   ```
1. Line 5

The bug renders the blocks as 'code' and fails to detect the block on line 4:

the bug!

...with patch...

with patch

@h3xx
Copy link

h3xx commented Aug 15, 2023

Mostly works, but it appears to be double-processing code inside the fences. I.e. # foo --> <h1>foo</h1> --> &lt;h1&gt;comment&lt;/h1&gt;.

Generates strange output given the following markdown:

```
# comment
```

Output:

<pre><code>&lt;h1&gt;comment&lt;/h1&gt;
</code></pre>

Expected:

<pre><code># comment
</code></pre>

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants