highlightjs / highlight.js

JavaScript syntax highlighter with language auto-detection and zero dependencies.
https://highlightjs.org/
BSD 3-Clause "New" or "Revised" License
23.79k stars 3.61k forks source link

`noHighlightRe` should win out over `languageDetectRe` #3700

Open sakurawald opened 1 year ago

sakurawald commented 1 year ago

If a class name matches noHighlightRe it should always be ignored - even if it otherwise looks correct and is also a match of languageDetectRe... this would allow you to use lang-* as your detect match but then also have an exclude list in the noHightlightRe regex.

IE, the block list overrides the allow list. This is an edge case. If no one steps up to work on this before v12 this will auto-close as it's such a small edge case (and also a breaking change).


Is your request related to a specific problem you're having? I am using highlight.js to with "hljs.highlightAll()", and get these warnings. image

The solution you'd prefer / feature you'd like to see added... an option like: excluded-languages: {mermaid, ...} or an option to disable these warnings.

sakurawald commented 1 year ago

I have tried this code but there seem to be some problems.

        hljs.configure({
            noHighlightRe: "lang-mermaid",
        });
        hljs.highlightAll();

image

sakurawald commented 1 year ago

I also try this and get:

        hljs.configure({
            noHighlightRe: /^lang-mermaid$/i
        });
        hljs.highlightAll();

image

joshgoebel commented 1 year ago

What harm are the warnings?

joshgoebel commented 1 year ago

Maybe use a union regex?

/^(no-?highlight|mermaid)$/i
sakurawald commented 1 year ago

Maybe use a union regex?

/^(no-?highlight|mermaid)$/i

I have tried this and

        hljs.configure({
            noHighlightRe: /^(no-?highlight|lang-mermaid)$/i
        });
        hljs.highlightAll();

however, still get the same warnings. (that seems the noHighlightRe doesn't work at all.

joshgoebel commented 1 year ago

Show us your raw HTML.

sakurawald commented 1 year ago

Show us your raw HTML.

Try this.

<pre><code class="lang-mermaid">graph TD;
      A--&gt;B;
      A--&gt;C;
      B--&gt;D;
      C--&gt;D;
</code></pre>
joshgoebel commented 1 year ago

So, you can't turn off the warning - not if it starts with lang-...

lang- or language- are reserved meanings... anytime we see that we assume you REALLY want to highlight and the language SHOULD be found, or else it's an error. It's not possible to use noHighlight in these cases.

I'd suggest instead:

// mermaid is highlighted just like plaintext, in that it isn't
hljs.registerAliases("mermaid", { languageName: "plaintext" })
sakurawald commented 1 year ago

So, you can't turn off the warning - not if it starts with lang-...

lang- or language- are reserved meanings... anytime we see that we assume you REALLY want to highlight and the language SHOULD be found, or else it's an error. It's not possible to use noHighlight in these cases.

I'd suggest instead:

// mermaid is highlighted just like plaintext, in that it isn't
hljs.registerAliases("mermaid", { languageName: "plaintext" })

I am using Typora to edit some markdown files. If I use the markdown file in hexo. I need to use mermaid to render mermaid source block, and the class name is lang-mermaid. What confuse me is that, why the render test matched class first, instead of the not-matched class first to exclude some unwanted blocks.

Anyway, thank you.

joshgoebel commented 1 year ago

What confuse me is that, why the render test matched class first, instead of the not-matched class first to exclude some unwanted blocks.

I'm not sure there is any reason. I think that the exclude and include patterns matching the same element is simply a rare edge case that was simply never considered - and has never been reported as an issue until now.

Would you be willing to work on a PR to change the behavior? There might be a window where we could merge such a change as part of the v12 release.

sakurawald commented 1 year ago

What confuse me is that, why the render test matched class first, instead of the not-matched class first to exclude some unwanted blocks.

I'm not sure there is any reason. I think that the exclude and include patterns matching the same element is simply a rare edge case that was simply never considered - and has never been reported as an issue until now.

Would you be willing to work on a PR to change the behavior? There might be a window where we could merge such a change as part of the v12 release.

Currently not. The case is when you use highlightjs and mermaid to render a .md file exported from typora, I just mention this.