How to prevent automatic wikilinks inside fenced code blocks?

Suppose I enable wikilinks with square brackets, like this:

Let’s say I have a Markdown document named “some destination”. If I write the square-brakets-around-the-name in a fenced code block, the following is what happens:

How can I prevent automatic wikilinking inside code blocks?

Motivating example: if I’m trying to write an explanation of how the wikilinking thing works, and I want to show the literal text that I have to type … which appears to be impossible to do!

What version of DEVONthink are you running?

Oh, sorry, I should have said. This is 3.7.2 on macOS 10.14.

For purposes of this test, I disabled the Prism extension (as well as the other extensions) in Preferences ▹ Media.

No problem.

It’s not possible to modify the behavior on a per-file or filetype basis. You’d have to temporarily disable the automatic Wikilinking.

However, I am reporting a bug as the raw Markdown link is being shown in the rendered view. It should be a standard link, not an inactive string showing the underlying Markdown for the link.

Also, in your example it would appear the Wikilink shouldn’t be active. Perhaps @cgrunenberg could account for code and fenced code blocks to ignore Wikilinks.

Definitely looks unexpected in the rendered view. The links there are non-functional while the source links actually work! :open_mouth: :slight_smile:

1 Like

Thank you for the explanation.

To add to the discussion about brackets inside fenced code blocks: I tried to find a quote character that would prevent the linking, but while using backslashes (\ ) works, they also show up in the rendered output. I also tried to get clever by using special Unicode characters that look like square brackets, and that almost works, but at least in the font & character combination that I found so far, the only close approximate is the “fullwidth left square bracket” ([) and “fullwidth right square bracket” (]), and they have some kind of spacing issue that makes the result display large gaps between the two [ on the left and the two ] on the right, which is very misleading in this situation. (In fact, you can see the problem in this very paragraph, where I typed those characters without any spaces surrounding them, yet there are huge spaces before and after the characters. This makes them unsuitable as a substitute.)

No problem.

Let’s see what Development thinks about all this. :slight_smile:

1 Like

The next release will fix this:

Bildschirmfoto 2021-09-21 um 08.58.06