X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/8d81dee4117ac6ad9ce79c4852aa82bdec79beea..651cdd4b2a85f4e5f9d298a7eea7d0e6d94442b1:/doc/todo/conditional_text_based_on_ikiwiki_features.mdwn?ds=sidebyside

diff --git a/doc/todo/conditional_text_based_on_ikiwiki_features.mdwn b/doc/todo/conditional_text_based_on_ikiwiki_features.mdwn
index 2b411144c..0d0f66da4 100644
--- a/doc/todo/conditional_text_based_on_ikiwiki_features.mdwn
+++ b/doc/todo/conditional_text_based_on_ikiwiki_features.mdwn
@@ -1,6 +1,6 @@
 I'd like to see some way to conditionally include wiki text based on
 whether the wiki enables or disables certain features.  For example,
-[[ikiwiki/formatting]], could use `\[[if (enabled smiley) """Also, because
+[[ikiwiki/formatting]], could use `\[[!if (enabled smiley) """Also, because
 this wiki has the smiley plugin enabled, you can insert \[[smileys]] and
 some other useful symbols."""]]`, and a standard template for [[plugins]]
 pages could check for the given plugin name to print "enabled" or
@@ -25,7 +25,7 @@ include an `else` clause; if so, you could label the text used if true as
 `then`.
 
 Syntax could vary greatly here, both for the
-[[ikiwiki/PreprocessorDirective]] and for the condition itself.
+[[ikiwiki/Directive]] and for the condition itself.
 
 > I think this is a good thing to consider, although conditionals tend to
 > make everything a lot more complicated, so I also want to KISS, and not
@@ -52,12 +52,12 @@ Syntax could vary greatly here, both for the
 > As to the syntax, to fit it into standard preprocessor syntax, it would
 > need to look something like this:
 >
->	\[[if test="enabled(smiley)" """foo"""]]
+>	\[[!if test="enabled(smiley)" """foo"""]]
 > 
 > --[[Joey]]
 
 >> [[ikiwiki/PageSpec]] syntax seems perfect, and your proposed syntax for the `if`
->> [[ikiwiki/PreprocessorDirective]] looks fine to me.
+>> [[ikiwiki/Directive]] looks fine to me.
 >>
 >> [[ikiwiki/PageSpec]]s don't give you `none` for free, since `!foo/*` as a boolean
 >> would mean "does any page not matching `foo/*` exist", not "does `foo/*`
@@ -70,12 +70,12 @@ Syntax could vary greatly here, both for the
 >>
 >> A few use cases for `included`, which I would really like to see:
 >>
->> * On the sidebar page, you could say something like \[[if test="!included"
+>> * On the sidebar page, you could say something like \[[!if test="!included"
 >>   """This page, without this help message, appears as a sidebar on all
 >>   pages."""]].  The help text would then only appear on the sidebar page
 >>   itself, not the sidebar included on all pages.
 >>
->> * On [[ikiwiki/blog]] entries, you could use `included` to implement a cut.
+>> * On [[blog]] entries, you could use `included` to implement a cut.
 >>   (Please don't take that as an argument against. :) ) For instance, you
 >>   could use included rather than [[plugins/toggle]] for the detailed
 >>   changelogs of ikiwiki, or to embed an image as a link in the feed rather
@@ -110,7 +110,19 @@ This is now completely [[todo/done]]! See [[plugins/conditional]].
 Is there a way to test features other than plugins? For example,
 to add to [[ikiwiki/Markdown]] something like
 
-    \[[if test="enabled(multimarkdown)" then="You can also use..."]]
+    \[[!if test="enabled(multimarkdown)" then="You can also use..."]]
 
 (I tried it like that just to see if it would work, but I wasn't that lucky.)
 --ChapmanFlack
+
+> No, not supported. I really think that trying to conditionalise text on a
+> page for multimarkdown is a path to madness or unreadability though.
+> Perhaps it would be better to have .mmdwn files that can only contain
+> multimarkdown? --[[Joey]]
+
+>> Really, there was only one (or maybe two) pages I had in mind as appropriate
+>> places for conditional text based on multimarkdown—the underlay pages
+>> for 'markdown' and maybe also 'formatting', because those are the pages you
+>> look at when you're trying to find out how to mark stuff up for the wiki, so
+>> if MM is enabled, they need to at least mention it and have a link to the
+>> MM syntax guide.--ChapmanFlack