X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/2f583a6e05c9f1d3c64dccc991d7578b4dd6345a..81aa58e7ca0118fbb6e1b7f53e47f01d260cdbff:/doc/bugs/Spaces_in_link_text_for_ikiwiki_links.mdwn diff --git a/doc/bugs/Spaces_in_link_text_for_ikiwiki_links.mdwn b/doc/bugs/Spaces_in_link_text_for_ikiwiki_links.mdwn index e628278ab..8aea5cd29 100644 --- a/doc/bugs/Spaces_in_link_text_for_ikiwiki_links.mdwn +++ b/doc/bugs/Spaces_in_link_text_for_ikiwiki_links.mdwn @@ -1,3 +1,53 @@ -Versions 2.0 and 2.1 of ikiwiki, and I think earlier versions as well, allowed wiki links to have spaces in the link text. For example, [[ikiwiki logo page|logo]] should create an anchor tag referencing the logo page, and [[ikiwiki logo|logo/ikiwiki.png]] should create an image tag referencing the logo. +Versions 2.0 and 2.1 of ikiwiki, and I think earlier versions as well, +allowed wiki links to have spaces in the link text. For example, [[!ikiwiki +logo page|logo]] should create an anchor tag referencing the logo page, and +[[!ikiwiki logo|logo/ikiwiki.png]] should create an image tag referencing +the logo. -As of version 2.2, this no longer works. I think the pattern \\[[...|...]] should allow spaces before the pipe. I suspect this is the same problem as reported in [[index/discussion#index11h1]]. \ No newline at end of file +As of version 2.2, this no longer works. I think the pattern \\[[...|...]] +should allow spaces before the pipe. I suspect this is the same problem as +reported in [[index/discussion#index11h1]]. + +> The above examples are ambiguous, only worked due to a bug, and were +> never documented to work. So I'm not inclined to re-add support for them. +> +> If you look at [[ikiwiki/WikiLink]], it is clear that spaces cannot be used in +> WikiLinks. It also shows how to use underscores in the link text if you +> want multiple words. +> +> This was a decision I made a long time ago due to the ambiguity between a +> WikiLink and a [[ikiwiki/Directive]]. Is "\[[foo bar|baz]]" a wikilink to +> baz with a link text of "foo bar", or an instance of preprocessor +> directive "foo" with a parameter of "bar|baz"? If it's interpreted as a +> wikilink today, that could change tomorrow if a new preprocessor directive +> is added. +> +> Before version 2.2, ikiwiki actually first treated it as a preprocessor +> directive. If that failed, it output the preprocessor directive back onto +> the page, and next the wikilink code tried treating it as a wikilink. +> In 2.2, I fixed several problems with the way an unhandled preprocessor +> directive was re-output onto the page, by prefixing it with a '\' ... +> which makes it not be treated as a WikiLink. +> +> If WikiLinks had ever been documented to work with spaces in them, then +> I'd feel I needed to support the pre 2.2 behavior, but I don't feel that +> I have to support old behavior that was never documented and happened due +> to a bug, so I current have no plans to bring the old behavior back. +> --[[Joey]] + +>> I agree that the grammar should be unambiguous. It seems to me that the +>> problem with spaces-in-wikilinks is caused by overloading the wikilink +>> and preprocessor syntax to use the same symbols. If they didn't (and is +>> there much advantage in them using the same symbols? I know in some +>> cases you have something which is a wikilink and a preprocessor directive, +>> but how often?) there'd be no problem with spaces. +>> +>> If there was ever a future, syntax-breaking major release of ikiwiki +>> (similar to python3000) I'd like to see this fixed as part of that. +>> --[[users/Jon]] + +>>> You can enable `prefix_directives` and get the disambiguated behavior +>>> and spaces in wikilinks today. It will become the default in 3.0. +>>> --[[Joey]] + +[[done]]