X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/f3ae86926265f1f44e6ea0835475f74d84517f26..ac560e288b5d4e0df9c5bc977303fd36975a3cea:/doc/bugs/Smileys_in_the_block_code.mdwn

diff --git a/doc/bugs/Smileys_in_the_block_code.mdwn b/doc/bugs/Smileys_in_the_block_code.mdwn
index ef2c233bb..3b11b83ba 100644
--- a/doc/bugs/Smileys_in_the_block_code.mdwn
+++ b/doc/bugs/Smileys_in_the_block_code.mdwn
@@ -25,3 +25,26 @@ mailing list. Please looks below to see what ikiwiki does with that smileys:
 BTW, maybe converting smileys in the block code should be disabled at all?
 
 --Pawel
+
+> Looks similar to [[wiki_links_still_processed_inside_code_blocks]]; in both
+> cases, substitution happens in a code block, which it shouldn't.
+> --[[JoshTriplett]]
+
+----
+
+> 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