[pmwiki-users] RFC: Indexing categories and links

Petko Yotov 5ko at 5ko.fr
Thu Mar 4 00:40:52 CST 2010

On Thursday 04 March 2010 06:20:04, DaveG wrote :
> On 3/3/2010 2:58 PM, Petko Yotov wrote:
> > * A pagelist with link=!Name will find only pages containing [[!Name]],
> > which is new. Only newly created (:pagelist link=!Name:) will display
> > these pages.
> I think this is useful, and personally the way I always assumed
> backlinks worked. I wonder though whether using the ! as the trigger is
> too subtle. Why not a new tag, like category=Name?
> However, I don't feel strongly -- link=!Name is at least consistent with
> the !Category idea.

I now see a problem of which I haven't thought before -- with other parameters 
like name=!Name or group=!Name the "!" means "NOT Name" so link=!Name may be 
confusing and a bad idea. :-(

Especially if at some point we change the link= parameter to accept multiple 
page names like link=Page1,Page2,-Group3.* . Hmm...

> > Another feature was suggested by Peter Bowers. We can have globally
> > defined link prefixes like :
> >
> >    ! for Category
> How would this form work in conjunction with the change above? If:
>     $LinkPrefixGroup['!'] = 'Category';
> And then I do [[!Tag1]] would that be treated differently to
>     [[Category/Tag1]] or [[Category.Tag1]]
> It would need to be in order for the first change to work, but then that
> suggests that these two are also different:
>     $LinkPrefixGroup['@'] = 'Todo';
> And then I do [[!Tag1]] would that be treated differently to
>     [[Todo/Tag1]] or [[Todo.Tag1]]
> If so, in what way?

Yes, the link prefix is related to the way of indexing the links, so a link 
[[@Tag1]] will be indexed as "Todo.Tag1 @Tag1". Then

  (:pagelist link=Todo.Tag1:)
	 would find pages with [[Todo/Tag1]] and those with [[@Tag1]]

  (:pagelist link=@Tag1:)
	 would find only pages with [[@Tag1]]

The current pagelist searches for a link are simple and extremely fast and the 
new feature of having indexed both the full name and the prefixed name does 
not make searches slower.

> <<SNIP>>
> > Using a global way of dealing with links will fix some bugs we've had for
> > a long time:
> >
> >    "[[!My category | Alternative text ]]" doesn't work in 2.2.14
> >    "[[!My category |+]]" doesn't work in 2.2.14
> >    "[[!My category]]suffix"  doesn't work in 2.2.14
> >
> > So my second question is should we enable this link-prefix feature?
> I think this is a pretty neat feature, and if it fixes existing bugs,
> then that's great, and may be worth doing just for the bugs.
> I'm not sure of that it's particularly valuable on it's own though -- it
> appears to be a shortcut to typing the Group part of a link? Is that
> correct? If so I may use it, but it wouldn't be something I'd vote for
> on it's own. Maybe a 3 out of 5 vote. Definitely not opposed, but not
> raving for it either. Is there some use of it that is not immediately
> apparent?

Yes, a shortcut, and it is possible to have different html snippets for each 
type of link with $LinkPrefixFmt['!']. Something like the current 
$LinkCategoryFmt, but more flexible, for more groups.

The ability to add more link prefixes is a side-effect of the wish to treat 
all current links principally the same way:
  [[some link]], [[!some link]] and [[~some link]]

I have the feeling that [[!Link]] and [[~Link]] are used a lot, require less 
typing from the authors, and keep the wiki source text shorter and easier to 
review and update. So they may be a good thing.

On the other hand, adding more possibilities will indeed allow people to use 
them and we'll have to support all variants. Like the current possibility to 
change the page names and the URLs -- someone changes them to be more SEO 
friendly and then complains that the links in the documentation stopped 
working. :-( 


More information about the pmwiki-users mailing list