Support fenced code block within lists and blockquotes

[waylan]

As per this discussion on the markdown list, we should support fenced code blocks inside lists and blockquotes. Currently, they only work at the document root.

While we're at it, we might add support for github's syntax as an alternative??

[waylan]

Just a reminder to myself: Lots of test cases in these bug reports.

[rafalp]

Anything new on this issue? I'm using this lib in my project and allowing users to quote messages with fenced code blocks is pretty important for me. Maybe directions how can this be handled by custom extension?

[cgabard]

Hello,

I have the same issue in a personal project and solved it with a dirty hook : change the BlockParser.parseChunk() method with an extension. This hook allow some preprocessor extensions, in this case only fenced_code, to process text blocks before there are split arount blank line.

A cleaner way will be to have a new kind of extension, or add an configuration option to preprocessor extension, which allow their to be processed on each texts block.

I can submit you a PR if I know how you want I implemented this.

[waylan]

@cgabard thanks for the input. Although I have a plan. Some time ago (around the time I filed this issue) I made a small change to the BlockParser (b3e0359) which will allow fenced code blocks to be implemented as a BlockProcessor.

While BlockProcessors generally only work on one block at a time, they have access to all remaining (unprocessed) blocks in the document. Given the above mentioned change, a BlockProcessor's 'run' method could step through all remaining blocks until the end of the fenced code block is found. If there is no end to the fenced code block, the run method would return False and the BlockParser would move on just as is the test method had returned False.

The tricky part is when the fenced code is nested in a blockquote, list, etc. If we reach the end of the nested level, but haven't found the end of the fenced code block, then no fenced code block. That means keeping better track of nesting (how many levels deep, etc) which means the existing BlockProcessors probably need some refactoring to. And while I'm at it, those BlockProcessors might as well be refactored to use the new API mentioned above (it would greatly simplify a few of them). Its that last part that has been holding this up. Refactoring the BlockProcessors is a major task which I just don't have a big enough block of spare time to tackle.

Of course, if someone else wanted to give it a go, I'd be willing to mentor them through it.

[cgabard]

thanks for the reply.

It is a major piece of work but I agree it will be a better solution to solve this issue. Unfortunately, I don't have time for now to help you on this big task. But, meanwhile, I can do some smaller task for help you.

[memeplex]

+1 for this:

• github markdown supports it.
• the codehilite extension also supports it. Nowadays I can 8-space indent a codeblock and annotate it with #!python or :::python but not with ~~~~{.python}.

This is somewhat inconsistent inside python markdown itself and, moreover, it's not possible to preview some markdown before pushing it to github.

[aziz]

Just a reminder that the fenced code blocks are not working inside admonition blocks.

!!! note "This is the note title"
    Here is the sample code

    ``` js
    for (var i = 0; i < 10; i++) {
        console.log(i);
    }
    ```

[dhalperi]

+1 here as well.

@cgabard @waylan if you have some pointers about your plan and/or example similar code, I may be able to take a stab at the new implementation. I have a long plane flight coming up... :)

[dhalperi]

(My particular issue is in the attached gist: https://gist.github.com/dhalperi/5d0f7c8fc780a14495a4).

Specifically, that line 27 does not render the same as line 12, which works fine. In the attached screenshot, line 27 is the first code block under List item 2. Line 12 is the second code block not in the list.