[[!tag wishlist]]

As noted in [[todo/tag_pagespec_function]], there is a "misbehavior" of a `tagged()` pagespec: it matches even pages which have plain links to the tag page.

And in general, it would be quite useful to be able to distinguish different kinds of links: one more kind, in addition to "tag", is "bug dependency" noted in [[todo/structured_page_data#another_kind_of_links]] and [[todo/tracking_bugs_with_dependencies#another_kind_of_links]].

It could distinguish the links by the `rel=` attribute. ([[Tags already receive a special rel-class|todo/rel_attribute_for_links]].) This means there is a general need for a syntax to specify user-defined rel-classes on wikilink (then bug deps would simply use their special rel-class, either directly, or through a special directive like `\[[!depends ]]`), and to refer to them in pagespecs (in forward and backward direction).

Besides pagespecs, the `rel=` attribute could be used for styles. --Ivan Z.

> FWIW, the `add_link` function introduced in a recent
> release adds an abstraction that could be used to get
> part of the way there to storing data about different types of
> links. That function could easily be extended to take an optional
> third parameter specifying the link type.
> 
> Then there's the question of how to store and access the data. `%links`
> does not offer a good way to add additional information about links.
> Now, we could toss `%links` entirely and switch to an accessor function,
> but let's think about not doing that..
> 
> The data that seems to be needed is basically a deep hash, so
> one could check `$linktype{$page}{tag}{$link}` to see if
> the page contains a link of the given type. (Note that pages could
> contain links that were duplicates except for their types.)
> 
> There would be some data duplication, unfortuantly, but if `%linktype`
> is not populated for regular wikilinks, it would at least be limited to
> tags and other unusual link types, so not too bad.
> 
> `%linktype` could be stored in `%pagestate`.. if so
> the actual use might look like `$pagestate{$page}{linktype}{tag}{$link}`.
> That could be implemented by the tag plugin right now
> with no core changes. (BTW, then I originally wrote tag, pagestate
> was not available, which is why I didn't make it differentiate from
> normal links.) Might be better to go ahead and add the variable to
> core though. --[[Joey]] 

>> I've implemented this with the data structure you suggested, except that
>> I called it `%typedlinks` instead of `%linktype` (it seemed to make more
>> sense that way). I also ported `tag` to it, and added a `tagged_is_strict`
>> config option. See below! --[[smcv]]

I saw somewhere else here some suggestions for the wiki-syntax for specifying the relation name of a link. One more suggestion---[the syntax used in Semantic MediaWiki](http://en.wikipedia.org/wiki/Semantic_MediaWiki#Basic_usage), like this:

<pre>
... the capital city is \[[Has capital::Berlin]] ...
</pre>

So a part of the effect of [[`\[[!taglink TAG\]\]`|plugins/tag]] could be represented as something like `\[[tag::TAG]]` or (more understandable relation name in what concerns the direction) `\[[tagged::TAG]]`.

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]]
>> [[!tag patch]]

## Documentation for smcv's branch

### added to [[ikiwiki/pagespec]]

* "`typedlink(type glob)`" - matches pages that link to a given page (or glob)
  with a given link type. Plugins can create links with a specific type:
  for instance, the tag plugin creates links of type `tag`.

### added to [[plugins/tag]]

If the `tagged_is_strict` config option is set, `tagged()` will only match
tags explicitly set with [[ikiwiki/directive/tag]] or
[[ikiwiki/directive/taglink]]; if not (the default), it will also match
any other [[WikiLinks|ikiwiki/WikiLink]] to the tag page.

### added to [[plugins/write]]

#### `%typedlinks`

The `%typedlinks` hash records links of specific types. Do not modify this
hash directly; call `add_link()`. The keys are page names, and the values
are hash references. In each page's hash reference, the keys are link types
defined by plugins, and the values are hash references with link targets
as keys, and 1 as a dummy value, something like this:

	$typedlinks{"foo"} = {
		tag => { short_word => 1, metasyntactic_variable => 1 },
		next_page => { bar => 1 },
	};

Ordinary [[WikiLinks|ikiwiki/WikiLink]] appear in `%links`, but not in
`%typedlinks`.

#### `add_link($$;$)`
 
 This adds a link to `%links`, ensuring that duplicate links are not
 added. Pass it the page that contains the link, and the link text.
 
An optional third parameter sets the link type (`undef` produces an ordinary
[[ikiwiki/WikiLink]]).

> Some code refers to `oldtypedlinks`, and other to `oldlinktypes`.
> 
> 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 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
> to `@links` when adding a typed, or untyped link. If only untyped
> links were recorded there, one could tell the difference. But then
> typed links would not show up at all in eg, a linkmap,
> unless it was changed to check for typed links too.
> (Or, regular links could be recorded in typedlinks too,
> with a empty type. (Bloaty.))
> 
> I suspect we could get away without having `tagged_is_strict`
> without too much transitional trouble. --[[Joey]]