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

Inline code block inside a table header is not recognized #757

Closed
franckl opened this issue Apr 12, 2018 · 7 comments
Closed

Inline code block inside a table header is not recognized #757

franckl opened this issue Apr 12, 2018 · 7 comments
Labels
bug Issue reports a bug

Comments

@franckl
Copy link

franckl commented Apr 12, 2018

Description

Inline code block (example) is not recognized when placed inside an html table

However, it does work when the table is placed inside a !!!tips (admonition). See screenshots below and code to reproduce.

I am using the latest python/pip/mkdocs/material versions on linux and osx with chrome.

image

image

!!!tips
    <table>
        <thead>
            <tr>
                <th colspan="2"><a name="Tab11">Table 11</a>: Significations of `:::freefem lparams` corresponding to HIPS interface</th>
            </tr>
        </thead>
        <tbody>
            <tr>
                <td style="font-weight: bold">Entries of `iparm`</td>
                <td style="font-weight: bold">Significations of each entries</td>
            </tr>
            <tr>
                <td>`iparm[0]`</td>
                <td>Strategy use for solving (Iterative=0 or Hybrid=1 or Direct=2). Defaults values are : Iterative</td>
            </tr>
            <tr>
                <td>`iparm[1]`</td>
                <td>Krylov methods. If iparm[0]=0, give type of Krylov methods: 0 for GMRES, 1 for PCG</td>
            </tr>
            <tr>
                <td>`iparm[2]`</td>
                <td>Maximum of iterations in outer iteration: default value 1000</td>
            </tr>
            <tr>
                <td>`iparm[3]`</td>
                <td>Krylov subspace dimension in outer iteration: default value 40</td>
            </tr>
            <tr>
                <td>`iparm[4]`</td>
                <td>Symmetric(=0 for symmetric) and 1 for unsymmetricmatrix: default value 1 (unsymmetric matrix)</td>
            </tr>
            <tr>
                <td>`iparm[5]`</td>
                <td>Pattern of matrix are symmetric or not: default value 0</td>
            </tr>
            <tr>
                <td>`iparm[6]`</td>
                <td>Partition type of input matrix: default value 0</td>
            </tr>
            <tr>
                <td>`iparm[7]`</td>
                <td>Number of level that use the HIPS locally consistentfill-in: Default value 2</td>
            </tr>
            <tr>
                <td>`iparm[8]`</td>
                <td>Numbering in indices array will start at 0 or 1: Default value 0</td>
            </tr>
            <tr>
                <td>`iparm[9]`</td>
                <td>Scale matrix. Default value 1</td>
            </tr>
            <tr>
                <td>`iparm[10]`</td>
                <td>Reordering use inside subdomains for reducingfill-in: Only use for iterative. Default value 1</td>
            </tr>
            <tr>
                <td>`iparm[11]`</td>
                <td>Number of unknowns per node in the matrix non-zeropattern graph: Default value 1</td>
            </tr>
            <tr>
                <td>`iparm[12]`</td>
                <td>This value is used to set the number of time the normalization is applied to the matrix: Default 2.</td>
            </tr>
            <tr>
                <td>`iparm[13]`</td>
                <td>Level of informations printed during solving: Default 5.</td>
            </tr>
            <tr>
                <td>`iparm[14]`</td>
                <td>HIPS_DOMSIZE Subdomain size</td>
            </tr>
        </tbody>
    </table>
@squidfunk
Copy link
Owner

@facelessuser I'm sorry to ask, but do you have any ideas? It looks like an issue with the inline highlighting parser.

@squidfunk squidfunk added the bug Issue reports a bug label Apr 12, 2018
@facelessuser
Copy link
Contributor

@franckl, as this doesn't seem to be reproducible by me, please provide markdown source that you are using to demonstrate the mentioned issue. Also, please provide things such as Python Markdown version, pymdown-extensions version, etc.

@facelessuser
Copy link
Contributor

Ideally provide a minimal case (minimum required to reproduce).

@facelessuser
Copy link
Contributor

@franckl, I reread, and I think I understand what is going on. Markdown is not supposed to be parsed inside block HTML.

Some block HTML is most likely not recognized the same way when it is indented under admonitions causing some inline code to be recognized.

In general, it isn't ideal to mix block HTML and Markdown, but there are options to allow you to mix them: https://python-markdown.github.io/extensions/extra/#simple-example. Keep in mind that sometimes the extra solution can be a bit odd is some cases, and you will have to conform the HTML to how Markdown expects it; mainly removing indentation etc. Anyways, I'd play with the extra option, or just use plain HTML inside HTML blocks.

In short, Markdown in inline tags are usually parsed, but not in block without an extension. Additionally, inline tags under block tags won't be parsed as the parser shouldn't usually traverse the content under the block tag unless it is for some reason treated as normal text by the parser. I'd have to look further to understand why your HTML under the admonition is being parsed. Maybe later today when I have time.

@facelessuser
Copy link
Contributor

facelessuser commented Apr 12, 2018

In general, I think block HTML is supposed to have an empty line before it per spec, though some parsers don't require this, but Python Markdown does. Most likely this is the cause of conflicting behavior.

@facelessuser
Copy link
Contributor

One last note, if using pymdown-extensions, I'd use https://facelessuser.github.io/pymdown-extensions/extensions/extrarawhtml/ to parse in block HTML to avoid extension conflicts. It will share the same quirks as the previously mentioned solution, because it is essentially the same, but it splits it out from extra to prevent pulling in incompatible extensions that might conflict with pymdown-extensions you may be using.

@squidfunk
Copy link
Owner

squidfunk commented Apr 15, 2018

Closing as answered. Please re-open if you experience any further issues. Many thanks to @facelessuser!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issue reports a bug
Projects
None yet
Development

No branches or pull requests

3 participants