summaryrefslogtreecommitdiff
path: root/doc/bugs
diff options
context:
space:
mode:
authorjoey <joey@0fa5a96a-9a0e-0410-b3b2-a0fd24251071>2007-07-09 01:19:00 +0000
committerjoey <joey@0fa5a96a-9a0e-0410-b3b2-a0fd24251071>2007-07-09 01:19:00 +0000
commit55d1c26f53d9448a4460075f3f20fa78ca097fb0 (patch)
treea0781f8dd6e7c348bdfe1eaec42f8d7fcf809b7c /doc/bugs
parent35b72434b41f1e5412458bc14c2c9d8a78b1b03d (diff)
response
Diffstat (limited to 'doc/bugs')
-rw-r--r--doc/bugs/Smileys_in_the_block_code.mdwn19
-rw-r--r--doc/bugs/wiki_links_still_processed_inside_code_blocks.mdwn31
2 files changed, 30 insertions, 20 deletions
diff --git a/doc/bugs/Smileys_in_the_block_code.mdwn b/doc/bugs/Smileys_in_the_block_code.mdwn
index 58196002b..08ff90789 100644
--- a/doc/bugs/Smileys_in_the_block_code.mdwn
+++ b/doc/bugs/Smileys_in_the_block_code.mdwn
@@ -29,22 +29,3 @@ 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
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 881cf96a4..de9f6e5db 100644
--- a/doc/bugs/wiki_links_still_processed_inside_code_blocks.mdwn
+++ b/doc/bugs/wiki_links_still_processed_inside_code_blocks.mdwn
@@ -1,4 +1,8 @@
-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]]
+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
@@ -12,3 +16,28 @@ 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]]