urosm
/
ikiwiki
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

response

master
joey 2007-07-09 01:19:00 +00:00
parent 35b72434b4
commit 55d1c26f53
2 changed files with 30 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
doc/bugs/Smileys_in_the_block_code.mdwn
View File

@ -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

31
doc/bugs/wiki_links_still_processed_inside_code_blocks.mdwn
View File

@ -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]]