Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SuperFences produces different/"invalid" HTML after 10.11 #2471

Closed
mvelikikh opened this issue Sep 29, 2024 · 3 comments · Fixed by #2472
Closed

SuperFences produces different/"invalid" HTML after 10.11 #2471

mvelikikh opened this issue Sep 29, 2024 · 3 comments · Fixed by #2472
Labels
S: triage Issue needs triage. T: bug Bug.

Comments

@mvelikikh
Copy link

Description

SuperFences started producing "invalid" HTML after 10.11.
It happens for code blocks without language that use hl_lines, e.g.:

``` hl_lines="1"
some
code
```

I am aware that it got changed in that version but it breaks the code that is working fine in 10.10.2.

Minimal Reproduction

  1. use the following python code
import markdown
text = ('``` hl_lines="1"\n'
        "test\n"
        "data\n"
        "```\n"
        "\n"
        "some text\n"
        "```sql\n"
        "select * from dual;\n"
        "```")
html = markdown.markdown(text, extensions=['pymdownx.superfences'])
print(html)
  1. run in 10.10.2:
<pre class="highlight"><code>test
data</code></pre>
<p>some text
<pre class="highlight"><code class="language-sql">select * from dual;</code></pre></p>
  1. run in 10.11:
<p>``` hl_lines="1"
test
data
<pre class="highlight"><code>
some text
```sql
select * from dual;</code></pre></p>

Version(s) & System Info

  • Operating System: Windows 10
  • Python Version: 3.12
  • Package Version: pymdown-extensions-10.11
@mvelikikh mvelikikh added the T: bug Bug. label Sep 29, 2024
@gir-bot gir-bot added the S: triage Issue needs triage. label Sep 29, 2024
mvelikikh added a commit to mvelikikh/mvelikikh.github.io that referenced this issue Sep 29, 2024
@facelessuser
Copy link
Owner

This was not an explicitly tested case, so that is most likely why this regression occurred. It is perfectly reasonable for this to be expected to work though.

Most likely, the language is now getting parsed from hl_lines in this case, and then we have a weird option of = remaining. The language match should enforce that we have a word boundary and no trailing = to be considered a language \b(?!=).

We adjusted the header but also cleaned up the regex to be a bit more precise with the reworked logic. Where before we incidentally allowed an omitted language, now we must explicitly expect it and define it such that it won't be confused with attributes or options: option="value".

facelessuser added a commit that referenced this issue Sep 29, 2024
@facelessuser
Copy link
Owner

It ends up being slightly more complicated pattern update as we have to account for names with non-word chars, so a simple check of (?=[\t ]|$) ends up validating the language specifier much better. So now we don't run into issue when using things like c++ etc.

@facelessuser
Copy link
Owner

The fix has been released. Thanks for the report!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S: triage Issue needs triage. T: bug Bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants