X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/963a8a06596a8a11032039a5d15d17e07e01b7dd..49992eb2cec8bb3baeb89b33c29fdec0116529a5:/doc/todo/Short_wikilinks.mdwn?ds=sidebyside

diff --git a/doc/todo/Short_wikilinks.mdwn b/doc/todo/Short_wikilinks.mdwn
index 10ea70927..b9aec9112 100644
--- a/doc/todo/Short_wikilinks.mdwn
+++ b/doc/todo/Short_wikilinks.mdwn
@@ -23,6 +23,20 @@ extra for missing pages).
 > memory to avoid re-rendering. I don't want ikiwiki to be slow or use
 > excessive amounts of memory. YMMV. --[[Joey]]
 
+>> Or you could disk cache the incomplete page containing only the body text,
+>> which should often not need re-rendering, as most alterations consist of
+>> changing the link targets exactly, and we can know pages that exist before
+>> rendering a single page. Then after backlinks have been resolved, it would
+>> suffice to feed this body text from the cache file to the template. However, e.g.
+>> the inline plugin would demand extra rendering after the depended-upon pages
+>> have been rendered, but these pages should usually not be that frequent, or
+>> contain that many other pages in full. (And for 'archive' pages we don't need
+>> to remember that much information from the semi-inlined pages.) It would help
+>> if you could get data structures instead of HTML text from the HTMLizer, and
+>> then simply cache these data structures in some quickly-loadeble form (that
+>> I suppose perl itself has support for). Regexp hacks are so ugly compared
+>> to actually parsing a properly-defined syntax...
+
 A related possibility would be to move a lot of "preprocessing" after HTML
 generation as well (thus avoiding some conflicts with the htmlifier), by
 using special tags for the preprocessor stuff. (The old preprocessor could
@@ -44,6 +58,47 @@ Other alternatives would be
 > I agree that a plugin would probably be more cumbersome, but it is very
 > doable. It might look something like this:
 
-	\[[link bar]]
+	\[[!link bar]]
+
+	\[[!link bar=VeryLongPageName]]
+
+>> This is, however, still missing specifying the link text, and adding that option would seem to me to complicate the plugin syntax a lot, unless support is added for the |-syntax for specifying a particular parameter to every plugin.
+
+>>> Well, the link text in my example above is "bar". It's true that if
+>>> you want to use the same link text for multiple distinct links, or
+>>> different link texts for the same link, this is missing a useful layer of
+>>> indirection; it's optimised for the (probably) more common case. It
+>>> could be done as a degenerate form of the syntax I propose below, BTW.
+>>> --[[Joey]]
+
+>> ... Returning to this, the syntax infact wouldn't be so bad with the |-syntax, given a short name for the plugin:
+
+       [[whatever|ref 1]]
+       \[[!ref 1=page_with_long_name]]
+
+>>> A way to do this that doesn't need hacking at the preprocessor syntax
+>>> follows: --[[Joey]]
+
+	\[[!link bar=1]]
+	\[[!dest 1=page_with_long_name]]
+
+>>>> But this doesn't work so well for links that aren't valid keys. Such
+>>>> as stuff with spaces in it. I'd like to be able to write any kind of
+>>>> links conveniently, not just something that looks like a wikilink.
+
+>>>>> You're right, and to fix that it could be turned around: --[[Joey]]
+
+	\[[!link 1=bar]]
+	\[[!dest 1=page_with_long_name]]
+
+>> It also shouldn't be difficult to support non-wiki links in this same
+>> way, so that you could still link everywhere in an uniform manner, as
+>> the (still preferred by me) HTML processing approach would provide.
+>> Perhaps a plugin call wouldn't even be necessary for the links
+>> themselves: what about aliases for the normal link mechanism? Although
+>> the 'ref' call may infact be cleaner, and adding that |-syntax for
+>> plugins could offer other possibilities for other plugins.
 
-	\[[link bar=VeryLongPageName]]
+>>> I agree, it should be easy to make it support non-wiki links too.
+>>> We seem to have converged at something we can both live with that's
+>>> reasonable to implement.. --[[Joey]]