Conversation
|
Fixes #11 |
dlon
left a comment
There was a problem hiding this comment.
Thanks! I'm not necessarily opposed to the idea. Fenced code blocks are an extension of standard markdown, though, so it may have to be an option.
| elif tag.name == 'pre': | ||
| tag.insert_before('\n\n') | ||
| tag.insert_after('\n\n') | ||
| tag.insert_before('\n\n```\n') |
There was a problem hiding this comment.
This will cause any <pre> element to be surrounded with a code fence, not just <pre><code>.
There was a problem hiding this comment.
For safety and clarity that's not bad, but makes it harder to convert back to html.
Maybe for <pre> we only indent as you already did, but for <code> we backtick explicitly? Then the process to reverse back to html has a method it can follow.
| @@ -233,7 +233,6 @@ def _markdownify(tag, _listType=None, _blockQuote=False, _listIndex=1): | |||
| lines.pop() | |||
| for i,line in enumerate(lines): | |||
There was a problem hiding this comment.
This loop doesn't do anything. I can't remember if lines[i] = line.replace(...) is still necessary, but it's currently not being assigned to lines[i].
Unlike other formats markdown doesn't really have an 'official' spec, and fenced code blocks are kinda of the standard across almost all users of markdown for code. If anything https://commonmark.org/ is probably 'the standard', and does have fenced back tick codeblocks as part of it. :) |
Changes the representation of
<pre><code>to fenced code blocks instead of indented code blocks in Markdown.Fenced code blocks allow for user-friendly addition of language syntax, e.g.:
Syntax highlighting for these types of fenced code blocks is today widely available and make code snippets more legible.
I therefore suggest to replace this as the default rendering of
<pre><code>.