fenced_code markup not working inside a customblock

[mschwerhoff]

I've just started experimenting with custom blocks in the context of the website generator Pelican, and was wondering what the preferred/recommended way of nesting fenced code blocks under custom blocks is.

Pelican by default supportes the syntax from CodeHilite (the ⎵ characters denote significant whitespace), as well as fenced code blocks:

⎵⎵⎵⎵#!python
⎵⎵⎵⎵print("I'm a string")

and

⎵⎵⎵⎵:::python
⎵⎵⎵⎵print("I'm a string")

and also

```python
print("I'm a string")
```

The good news: the former two syntax directly work when nested under a custom block. E.g.:

::: myblock
⎵⎵⎵⎵A *regular* line of `Markdown` formatted text.

⎵⎵⎵⎵⎵⎵⎵⎵#!python
⎵⎵⎵⎵⎵⎵⎵⎵print("I'm deeply offended *äh* indented")

To avoid the deep indentation, I typically prefer the fenced code blocks style, and thus tried the following:

::: myblock
⎵⎵⎵⎵A *regular* line of `Markdown` formatted text.

⎵⎵⎵⎵```python
⎵⎵⎵⎵print("Less is more")
⎵⎵⎵⎵```

Since fenced code blocks are only supported at the document root level, this requires installing the SuperFences as well.

Are there any other (maybe better) options?

Also, feel free to use this write-up in an FAQ or elsewhere (and to close this "issue"), maybe it can help others that find themselves in a similar situation.

[vokimon]

Thanks for raising the question that indeed it spotted a bug. Github backtick syntax should definitely work inside a customblock. Would you mind to rewrite the issue as a bug report, for others to identify it better?

It should work because once a customblock is detected, any indented code is dedented and reparsed as markdown and because it is dedented, backtick code should be now a valid root level one with no need of superfences.

[vokimon]

fenced_code documentation is honest about its limitations and seems ok with them, delegating to super_fences when nesting inside other blocks. I think it would be ok to keep it unsupported but i still have some hope on finding a solution so let me explore it further before closing the bug.

Both fenced_code and superfences, are defined as preprocessors to temporary preplace the code from the input text by a hash so that following processors won't mess up the code. Later they substitute it back with the formatted code.

The problem is that preprocessor are called before the parser, so when custom_blocks recall the parser with the dedented code, fenced_code is not applied. Maybe the key might be to find a way to call preprocessors as well.