7

With certain syntax colourings active (for example "apl" but not "c"), and for certain specific characters, symbols that have meaning in markdown are visible while also causing formatting. Examples are

*II*

and

*1*

but not

*I*
2
  • 1
    Can you clarify what you mean? Are you saying that some syntax highlighters (like lang-apl) are visibly formatting characters that they shouldn't, or are you saying that the Markdown highlighter shouldn't show the symbols that it formats? – zcoop98 Jul 21 at 20:53
  • 1
    @zcoop98 Neither. I find it hard to believe that the syntax highlighter would italicise specific names and numbers. Rather, it looks that the Markdown processor fails to recognise code blocks when certain languages are in effect, and so we get both markdown effect and syntax highlighting. Not sure why the MarkDown processor wouldn't remove the asterisks, though… – Adám Jul 21 at 20:56
7

There are no bugs here; at least, not the bug that you think:

...it looks that the Markdown processor fails to [recognize] code blocks when certain languages are in effect, and so we get both [the] markdown effect and syntax highlighting.

A quick peek at this post's source/ HTML markup shows that the appropriate segments have been detected as code blocks: all 3 code blocks' contents have been wrapped properly in <pre><code>...</code></pre> tags with the s-code-block class applied:

<div class="s-prose js-post-body" itemprop="text" style="display: block;">
   <p>With certain syntax colourings active (for example "apl" but not "c"), and for certain specific characters, symbols that have meaning in markdown are visible while also causing formatting. Examples are</p>
   <pre class="lang-apl s-code-block"> <!-- Specified language and s-code-block classes -->
       <code class="hljs language-markdown"> <!-- The actual class HL.js is using (!!!) -->
           <span class="hljs-emphasis">*II*</span> <!-- HL.js class for this code section -->
        </code>
    </pre>
   <p>and</p>
   <pre class="lang-apl s-code-block">
        <code class="hljs language-markdown">
            <span class="hljs-emphasis">*1*</span>
        </code>
    </pre>
   <p>but not</p>
   <pre class="lang-apl s-code-block">
       <code class="hljs language-css">
           *
           <span class="hljs-selector-tag">I</span>
           *
        </code>
    </pre>
</div>

What is perplexing, at first glance, is that while the blocks are classified as lang-apl, the actual language highlighter the first two are using is language-markdown (which explains the italicized Markdown formatting we see):

<pre class="lang-apl s-code-block">
    <code class="hljs language-markdown">
        <span class="hljs-emphasis">*1*</span>
    </code>
</pre>

What's actually going on here, however, is revealed by a glance at the console:

Image of console with 3 of the below message visible

The first notice reads:

WARN: Could not find the language 'apl', did you forget to load/include a language module?

This tells us that highlight.js doesn't recognize lang-apl as a highlighter.
The real insight, though, comes from the next line:

WARN: Falling back to no-highlight mode for this block.
<code class=​"hljs language-markdown">​…​</code>​

While the error says it's falling back to "no-highlight" mode, what's really occurring (the real bug here?) is that the next best guess is being used for the block– in this case, that's apparently Markdown.

This also accounts for why the third block isn't italicized, since the third error indicates that the highlighter is falling back to language-css instead of Markdown, hence the difference.

(One might be inclined to blame the highlighter for this error, but there are really no right answers when trying to guess the language of a 3 to 4 character string.)

Takeaways

  1. APL isn't actually a language supported by highlight.js
  2. Stack Exchange has the highlighter set to use the "next best guess" as a fallback
  3. For some snippets, especially tiny ones, this is a terrible strategy, which leads to strange and unpredictable results
    • This last bit has been detailed before, by a maintainer of the highlight.js library
    • Throw some support to that feature request if you want this to change! (The language recognition part of highlighting on Stack could be so much better, the current implementation handicaps the library in this department)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .