From 55d1c26f53d9448a4460075f3f20fa78ca097fb0 Mon Sep 17 00:00:00 2001 From: joey Date: Mon, 9 Jul 2007 01:19:00 +0000 Subject: [PATCH] response --- doc/bugs/Smileys_in_the_block_code.mdwn | 19 ------------ ...ks_still_processed_inside_code_blocks.mdwn | 31 ++++++++++++++++++- 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]] -- 2.44.0