summaryrefslogtreecommitdiff
path: root/doc/bugs/wiki_links_still_processed_inside_code_blocks.mdwn
blob: b2a8b06323cd7f497918d748eb0b710ef981b10f (plain)

In [[ikiwiki/markdown]] syntax, none of the other special characters get processed inside a code block. However, in ikiwiki, [[wiki_links|ikiwiki/wikilink]] and [[preprocessor_directives|ikiwiki/directive]] still get processed inside a code block, requiring additional escaping. For example, [links don't work](#here), but a [[ikiwiki/wikilink]] becomes HTML. --[[JoshTriplett]]

Indented lines provide a good way to escape a block of text containing markdown syntax, but ikiwiki links like [[this]] are still interpreted within such a block. I think that intepretation should not be happening. That is I should be able to write:

[[this]]

and have it render like:

\[[this]]

--[[cworth]]


Has there been any progress or ideas on this bug recently? I use an expanded CamelCase regexp, and without much escaping in freelink text, or url links, or in codeblocks I get IkiWiki's attempt at creating a "link within a link".

I have no ideas other than perhaps once IkiWiki encounters [[ or the position is reset with a backreference from a CamelCased word, further processing of wikilinks is disabled until the position is reset and a "no not makelinks" flag or variable is cleared.

I've come up with some really ugly workarounds to handle case specific stuff like codeblocks but the problem creeps up again and again in unexpected places. I'd be happy to come up with a patch if anyone has a bright idea on a nice clean way (in theroy) to fix this. I'm out of ideas.

--CharlesMauch

I've moved the above comment here because it seems to be talking about this bug, not the similar Smileys bug.

In the case of either bug, no, I don't have an idea of a solution yet. --[[Joey]]

I've now solved a similar bug involving the smiley plugin. The code used there should give some strong hints how to fix this bug, though I haven't tried to apply the method yet. --[[Joey]]

[[!debbug 487397]]