68 lines
2.8 KiB
Markdown
68 lines
2.8 KiB
Markdown
In [[ikiwiki/markdown]] syntax, none of the other special characters get processed
|
|
inside a code block. However, in ikiwiki, [[wiki_links|ikiwiki/wikilink]] and
|
|
[[preprocessor_directives|ikiwiki/directive]] still get processed
|
|
inside a code block, requiring additional escaping. For example, `[links
|
|
don't work](#here)`, but `a [[ikiwiki/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
|
|
interpreted within such a block. I think that intepretation should not
|
|
be happening. That is I should be able to write:
|
|
|
|
[[this]]
|
|
|
|
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]]
|
|
|
|
> I've now solved a similar bug involving the smiley plugin. The code used
|
|
> there should give some strong hints how to fix this bug, though I haven't
|
|
> tried to apply the method yet. --[[Joey]]
|
|
|
|
>> As far, as I can see, smileys bug is solved by checking for code/pre. In
|
|
>> this case, however, this is not applicable. WikiLinks/directives *should* be
|
|
>> expanded before passing text to formatter, as their expansion may contain
|
|
>> markup. Directives should be processed before, as they may provide *partial*
|
|
>> markup (eg `template` ones), that have no sense except when in the page
|
|
>> cotext. Links should be processed before, because, at least multimarkdown may
|
|
>> try to expand them as anchor-links.
|
|
>>
|
|
>> For now, my partial solution is to restrict links to not have space at the
|
|
>> start, this way in many cases escaping in code may be done in natural way
|
|
>> and not break copypastability. For example, shell 'if \[[ condition ]];'
|
|
>> will work fine with this.
|
|
>>
|
|
>> Maybe directives can also be restricted to only be allowed on the line by
|
|
>> themselves (not separated by blank lines, however) or something similar.
|
|
>>
|
|
>> --[[isbear]]
|
|
|
|
[[!debbug 487397]]
|