refcount bug or not (was: Re: [pmwiki-users] 2.0.beta36 released w/pagelist bugfixes)

[Patrick R. Michaud]

On Sat, Apr 30, 2005 at 01:26:44PM -0400, Neil Herber wrote:
> At 2005-04-30  09:49 AM -0500, Patrick R. Michaud is rumored to have said:
> >I've just released 2.0.beta36, which corrects a somewhat major bug
> >in pagelist in processing excluded terms, and a minor bug in
> >handling simple tables with spaces after the final ||.
> 
> Patrick
> 
> Did my question about a possible bug in "refcount" get lost in the shuffle? 
> Or is it not a bug? Or should I make it a PITS entry? Refcount does not 
> seem to honor the $LinkWikiWords = 0 flag and lists CamelCase words as 
> missing links.

I just hadn't had a good chance to write a complete answer yet, sorry.
Even this isn't going to be a complete answer, but I'll at least
give some clue as to what's happening.

The general answer is that I've treated it as  "not a bug" because I've 
never considered refcount to be precise (it never has been, might not 
be anytime soon).  In 2.0 refcount doesn't scan the text -- it just 
uses the targets= attribute that is generated when the page is saved.  
So, if it's incorrectly reporting wikiword links, that's a bug in the 
targets= generator and not refcount.

The targets= generator should be honoring $LinkWikiWords if it's
set at the time the page is being saved.  However, as currently implemented
it doesn't recognize the (:nolinkwikiwords:) directive -- in fact,
the generation of targets= takes place assuming all directives are 
removed first.  This is arguably a bug; on the other hand there's
not a simple fix at the moment (and I've treated refcounting as imprecise
anyway so it hasn't concerned me too much).

I guess the answer is that for now this is something that just
hasn't annoyed me enough to label it a "bug" and want to invest 
the time needed to make it more precise.  But it's reasonable to call
it a bug.  So, it probably deserves a PITS entry for now, and some
votes to see how important a priority it is.

Pm