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! 
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.
The next release will fix this:
