In markdown syntax, none of the other special characters get processed
inside a code block. However, in ikiwiki, wiki links and
preprocessor directives still get processed
inside a code block, requiring additional escaping. For example, [links
don't work](#here), but a <a href="../../ikiwiki/wikilink/">wikilink</a> 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:
<span class="createlink"><a href="/ikiwiki.cgi?do=create&from=bugs%2Fwiki_links_still_processed_inside_code_blocks&page=this" rel="nofollow">?</a>this</span>
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
As far, as I can see, smileys bug is solved by checking for code/pre. In this case, however, this is not applicable. WikiLinks/directives should be expanded before passing text to formatter, as their expansion may contain markup. Directives should be processed before, as they may provide partial markup (eg
templateones), that have no sense except when in the page cotext. Links should be processed before, because, at least multimarkdown may try to expand them as anchor-links.For now, my partial solution is to restrict links to not have space at the start, this way in many cases escaping in code may be done in natural way and not break copypastability. For example, shell 'if [[ condition ]];' will work fine with this.
Maybe directives can also be restricted to only be allowed on the line by themselves (not separated by blank lines, however) or something similar.
--?isbear
I found a bug where footnotes can't be added inside tables (both the table plugin and markdown) because the markup isn't processed in the page context. What you describe regarding the processing order should fix it. Nevermind, it generally seems that footnotes aren't allowed in tables and footnotes can't be referred to more than once in Markdown. --awesomeadam