summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorjoey <joey@0fa5a96a-9a0e-0410-b3b2-a0fd24251071>2007-07-04 02:04:36 +0000
committerjoey <joey@0fa5a96a-9a0e-0410-b3b2-a0fd24251071>2007-07-04 02:04:36 +0000
commit80e3887e07f8a647f66f5a98045367955350292a (patch)
treeec4b2f1ec4582b8337309f24db044f05faa5e6f9
parent51a292b07784d43649ece2dfecafda6367fde0a8 (diff)
web commit by http://xtermin.us/: But also affects CamelCased style text in freelinks.
-rw-r--r--doc/bugs/Smileys_in_the_block_code.mdwn19
1 files changed, 19 insertions, 0 deletions
diff --git a/doc/bugs/Smileys_in_the_block_code.mdwn b/doc/bugs/Smileys_in_the_block_code.mdwn
index 863f570ab..3b11b83ba 100644
--- a/doc/bugs/Smileys_in_the_block_code.mdwn
+++ b/doc/bugs/Smileys_in_the_block_code.mdwn
@@ -29,3 +29,22 @@ BTW, maybe converting smileys in the block code should be disabled at all?
> 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