From c16e85aea18f274f1c792358bacf5909b8bb16c4 Mon Sep 17 00:00:00 2001 From: isbear Date: Sat, 24 Nov 2012 15:23:15 -0400 Subject: [PATCH] Add comment on links in code bug --- ...nks_still_processed_inside_code_blocks.mdwn | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) 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 b2a8b0632..9f0a1d102 100644 --- a/doc/bugs/wiki_links_still_processed_inside_code_blocks.mdwn +++ b/doc/bugs/wiki_links_still_processed_inside_code_blocks.mdwn @@ -46,4 +46,22 @@ and have it render like: > 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]] -- 2.44.0