new patch

[ikiwiki.git] / doc / bugs / wiki_links_still_processed_inside_code_blocks.mdwn

diff --git a/doc/bugs/wiki_links_still_processed_inside_code_blocks.mdwn b/doc/bugs/wiki_links_still_processed_inside_code_blocks.mdwn
index d26e725b0a1c0dbce6b89918d67255954c2498db..9f0a1d1022459d4a00cfbbec88dcf2c86281c0b4 100644 (file)
--- a/doc/bugs/wiki_links_still_processed_inside_code_blocks.mdwn
+++ b/doc/bugs/wiki_links_still_processed_inside_code_blocks.mdwn
@@ -1 +1,67 @@
-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`.
\ No newline at end of file
+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]]
+
+>> 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 `template` ones), 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]]
+
+[[!debbug 487397]]