doc/bugs/wiki_links_still_processed_inside_code_blocks.mdwn

   1 In [[ikiwiki/markdown]] syntax, none of the other special characters get processed
   2 inside a code block.  However, in ikiwiki, [[wiki_links|ikiwiki/wikilink]] and
   3 [[preprocessor_directives|ikiwiki/directive]] still get processed
   4 inside a code block, requiring additional escaping.  For example, `[links
   5 don't work](#here)`, but `a [[ikiwiki/wikilink]] becomes HTML`. --[[JoshTriplett]]
   6
   7 Indented lines provide a good way to escape a block of text containing
   8 markdown syntax, but ikiwiki links like \[[this]] are still
   9 interpreted within such a block. I think that intepretation should not
  10 be happening. That is I should be able to write:
  11
  12         [[this]]
  13
  14 and have it render like:
  15
  16         \[[this]]
  17
  18 --[[cworth]]
  19
  20 ----
  21
  22 > Has there been any progress or ideas on this bug recently?  I use an
  23 > expanded CamelCase regexp, and without much escaping in freelink text, or
  24 > url links, or in codeblocks I get IkiWiki's attempt at creating a "link
  25 > within a link".
  26 >
  27 > I have no ideas other than perhaps once IkiWiki encounters \[\[ or the
  28 > position is reset with a backreference from a CamelCased word, further
  29 > processing of wikilinks is disabled until the position is reset and a "no
  30 > not makelinks" flag or variable is cleared.
  31 >
  32 > I've come up with some _really_ ugly workarounds to handle case specific
  33 > stuff like codeblocks but the problem creeps up again and again in
  34 > unexpected places.  I'd be happy to come up with a patch if anyone has a
  35 > bright idea on a nice clean way (_in theroy_) to fix this.  I'm out of ideas.
  36 >
  37 > --CharlesMauch
  38
  39 > I've moved the above comment here because it seems to be talking about
  40 > this bug, not the similar Smileys bug.
  41 >
  42 > In the case of either bug, no, I don't have an idea of a solution yet.
  43 > --[[Joey]]
  44
  45 > I've now solved a similar bug involving the smiley plugin. The code used
  46 > there should give some strong hints how to fix this bug, though I haven't
  47 > tried to apply the method yet. --[[Joey]]
  48
  49 >> As far, as I can see, smileys bug is solved by checking for code/pre. In
  50 >> this case, however, this is not applicable. WikiLinks/directives *should* be
  51 >> expanded before passing text to formatter, as their expansion may contain
  52 >> markup. Directives should be processed before, as they may provide *partial*
  53 >> markup (eg `template` ones), that have no sense except when in the page
  54 >> cotext. Links should be processed before, because, at least multimarkdown may
  55 >> try to expand them as anchor-links.
  56 >>
  57 >> For now, my partial solution is to restrict links to not have space at the
  58 >> start, this way in many cases escaping in code may be done in natural way
  59 >> and not break copypastability. For example, shell 'if \[[ condition ]];'
  60 >> will work fine with this.
  61 >>
  62 >> Maybe directives can also be restricted to only be allowed on the line by
  63 >> themselves (not separated by blank lines, however) or something similar.
  64 >>
  65 >> --[[isbear]]
  66
  67 [[!debbug 487397]]