Confusing behaviour of block code with Markdown

clarkwinkelmann

I'm not sure where to write about this because it's technically a feature, not a bug, but it's extremely confusing for my use case.

On my website about electric cars I deal with "EVSEID"s, the public roaming identifiers for charging stations. These IDs usually take a form like CH*SWIEE205869 or CH*VOL*E0000305.

Writing an EVSEID in a post without care usually result in missing characters because Markdown converts part of the text to italics. To prevent this I try to always use an inline code block (single backtick) and it works fine.

Now, from time to time I want to paste a list of EVSEIDs. This time, I use a Markdown code block (tripe ticks) to wrap my list of IDs to prevent Markdown from messing with it.

Now my problem is, Markdown still messes with it. At first I was extremely confused why. Here's an example list of EVSEIDs in a simple tripe-ticks code block:

CH*VOL*E0000305
CH*VOL*E0000326
CH*VOL*E0000334

Some people might not notice at all, but with my OCD I immediately see that while no characters were removed, some text still ends up in italics despite being in a code block which is supposed to strip formatting.

I found the reason. When you don't specify the code language, highlightjs tries to guess the language, and in my situation it often picks Markdown, which has italics in its syntax "highlighting".

The solution is to specify ```text language in the block quote.

CH*VOL*E0000305
CH*VOL*E0000326
CH*VOL*E0000334

Anyway, my frustration comes from the fact that not only do I need to use a block quote to evade Markdown, I also need to explicitly specify plain text for the code block.

I'm thinking of a few solutions to make the process less frustrating but I don't think anyone implemented this so far:

Disable highlightjs completely, sharing actual code should be very rare for my forum anyway
Only enable code highlighting when a language is explicitly provided in the code block

I'm also thinking of customizing the Markdown parser to prevent text that looks like an EVSEID to be converted to italics in regular non-code sentences, but probably won't ever do this because customizing the Markdown parser itself is too intimidating and could potentially break Flarum/extensions later.

If anyone has any suggestion or dealt with this already I'm open to some suggestions. I'm not stuck by any means, I know a number of ways to implement the ideas above but maybe someone has an even better way.

n-peugnet

clarkwinkelmann Only enable code highlighting when a language is explicitly provided in the code block

This is the path I choose with my highlighting extension, as like you, I found the auto language detection very frustrating. It is in my opinion completely useless as when people want to highlight code they known the language used and they usually know how to specify it in markdown.

SychO

clarkwinkelmann I'm also thinking of customizing the Markdown parser to prevent text that looks like an EVSEID to be converted to italics in regular non-code sentences, but probably won't ever do this because customizing the Markdown parser itself is too intimidating and could potentially break Flarum/extensions later.

I think this might be the best thing to do, but rather than prevent, you could auto convert that pattern to an inline code block, wouldn't require the ticks in the actual unparsed text, and I don't think this will create any future trouble with extensions.

something along the lines of

(new Extend\Formatter())
    ->configure(function (\s9e\TextFormatter\Configurator $config) {
        $config->Preg->match('/CH\*VOL\*E\d{7}/', 'C');
    })