]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/blobdiff - doc/todo/matching_different_kinds_of_links.mdwn
updated, compatible with the merged trail
[git.ikiwiki.info.git] / doc / todo / matching_different_kinds_of_links.mdwn
index f8796652e8e75b499af64f46a3dbd40c9ccc3e0b..da3ea49f6e99ad8d2d807b8a06bc9fbf6424c027 100644 (file)
@@ -53,7 +53,7 @@ I don't have any opinion on this syntax (whether it's good or not)...--Ivan Z.
 
 -------
 
 
 -------
 
->> [[!template id=gitbranch author="[[Simon_McVittie|smcv]]" branch=smcv/link-types]]
+>> [[!template id=gitbranch author="[[Simon_McVittie|smcv]]" branch=smcv/ready/link-types]]
 >> [[!tag patch]]
 
 ## Documentation for smcv's branch
 >> [[!tag patch]]
 
 ## Documentation for smcv's branch
@@ -104,6 +104,12 @@ Some code refers to `oldtypedlinks`, and other to `oldlinktypes`. --[[Joey]]
 > Oops, I'll fix that. That must mean missing test coverage, too :-(
 > --s
 
 > Oops, I'll fix that. That must mean missing test coverage, too :-(
 > --s
 
+>> A test suite for the dependency resolver *would* be nice. --[[Joey]]
+
+>>> Bug fixed, I think. A test suite for the dependency resolver seems
+>>> more ambitious than I want to get into right now, but I added a
+>>> unit test for this part of it... --s
+
 I'm curious what your reasoning was for adding a new variable
 rather than using `pagestate`. Was it only because you needed
 the `old` version to detect change, or was there other complexity?
 I'm curious what your reasoning was for adding a new variable
 rather than using `pagestate`. Was it only because you needed
 the `old` version to detect change, or was there other complexity?
@@ -118,6 +124,17 @@ the `old` version to detect change, or was there other complexity?
 > my docs for `%typedlinks`, so I'll try to write docs for it as
 > `pagestate` and see if they work any better. --s
 
 > my docs for `%typedlinks`, so I'll try to write docs for it as
 > `pagestate` and see if they work any better. --s
 
+>> On reflection, I don't think it's any better as a pagestate, and
+>> the contents of pagestates (so far) aren't documented for other
+>> plugins' consumption, so I'm inclined to leave it as-is, unless
+>> you want to veto that. Loose rationale: it needs special handling
+>> in the core to be a dependency type (I re-used the existing link
+>> type), it's API beyond a single plugin, and it's really part of
+>> the core parallel to pagestate rather than being tied to a
+>> specific plugin. Also, I'd need to special-case it to have
+>> ikiwiki not delete it from the index, unless I introduced a
+>> dummy typedlinks plugin (or just hook) that did nothing... --s
+
 I have not convinced myself this is a real problem, but..
 If a page has a typed link, there seems to be no way to tell
 if it also has a separate, regular link. `add_link` will add
 I have not convinced myself this is a real problem, but..
 If a page has a typed link, there seems to be no way to tell
 if it also has a separate, regular link. `add_link` will add
@@ -133,6 +150,8 @@ with a empty type. (Bloaty.)) --J
 > not counting tags and other typed links?". A typed link is
 > still a link, in my mind at least. --s
 
 > not counting tags and other typed links?". A typed link is
 > still a link, in my mind at least. --s
 
+>> Me neither, let's not worry about it. --[[Joey]] 
+
 I suspect we could get away without having `tagged_is_strict`
 without too much transitional trouble. --[[Joey]]
 
 I suspect we could get away without having `tagged_is_strict`
 without too much transitional trouble. --[[Joey]]
 
@@ -140,3 +159,38 @@ without too much transitional trouble. --[[Joey]]
 > care either way; [[Jon]] expressed concern about people relying
 > on the current semantics, on one of the pages requesting this
 > change. --s
 > care either way; [[Jon]] expressed concern about people relying
 > on the current semantics, on one of the pages requesting this
 > change. --s
+
+>> Removed in a newer version of the branch. --s
+
+I might have been wrong to introduce `typedlink(tag foo)`. It's not
+very user-friendly, and is more useful as a backend for other plugins
+that as a feature in its own right - any plugin introducing a link
+type will probably also want to have its own preprocessor directive
+to set that link type, and its own pagespec function to match it.
+I wonder whether to make a `typedlink` plugin that has the typedlink
+pagespec match function and a new `\[[!typedlink to="foo" type="bar"]]`
+though... --[[smcv]]
+
+> I agree, per-type matchers are more friendly and I'm not enamored of the
+> multi-parameter pagespec syntax. --[[Joey]]
+
+>> Removed in a newer version of the branch. I re-introduced it as a
+>> plugin in `smcv/typedlink`, but I don't think we really need it. --s
+
+----
+
+I am ready to merge this, but I noticed one problem -- since `match_tagged`
+now only matches pages with the tag linktype, a wiki will need to be
+rebuilt on upgrade in order to get the linktype of existing tags in it
+recorded. So there needs to be a NEWS item about this and
+the postinst modified to force the rebuild.
+
+> Done, although you'll need to plug in an appropriate version number when
+> you release it. Is there a distinctive reminder string you grep for
+> during releases? I've used `UNRELEASED` for now. --[[smcv]]
+
+Also, the ready branch adds `typedlink()` to [[ikiwiki/pagespec]],
+but you removed that feature as documented above.
+--[[Joey]]
+
+> [[Done]]. --s