aboutsummaryrefslogtreecommitdiff
path: root/doc/bugs/wiki_links_still_processed_inside_code_blocks.mdwn
blob: de9f6e5db9c6088398ddfc054d96f1594d99e333 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
In [[markdown]] syntax, none of the other special characters get processed
inside a code block.  However, in ikiwiki, [[wiki links|wikilink]] and
[[preprocessor directives|preprocessordirective]] still get processed
inside a code block, requiring additional escaping.  For example, `[links
don't work](#here)`, but `a [[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]]