Non-functional bracketed tags: TracLinks

[Ryan J Ollos]

The sentence fragment tag:subversion. results in the tags query /tags?q='subversion.'. This means that if you have a sentence such as Do a search for tag:subversion., the query is incorrect unless you add a space between tag:subversion and the trailing period. This is unlike a wiki TracLink, in which the trailing period won't be incorporated (see #5523).

Example: Go to the page for wiki:TagsPlugin.

Second issue: Enclosing the tags TracLink in brackets doesn't result in a TracLink with the prefix removed, as is done for e.g. [wiki:TagsPlugin] which yields TagsPlugin.

[Ryan J Ollos]

Here is the markup that was used to generate the screen capture shown in comment:Description:

wiki:SwDev
wiki:SwDev.
[wiki:SwDev]
tag:subversion
tag:subversion.
[tag:subversion]

[Steffen Hoffmann]

Then possible would want to exclude other non-letter-characters too, like ,;:!? - right?

But please allow a general rambling: I remember another ticket where a similar issue has been raised, but for including whole sentences. While one might think, that adding options would be always fine, there is at least one related developer phrase: feature bloat, maybe more. I see the probability of satisfying every demand actually decreases with added complexity, because fewer people will be able to master the greater possibilities. Most probably (own experience) more users are distracted by increasing complexity. IMHO Trac is a good example for the "reduce to the max" paradigm. (Uff, sorry, feel better now. :-)

So I'll be willing to follow only after more complex character processing is verified. Nevertheless your examples look valid and might serve well at least as a starting point. But let's consider some more cases that spring into my mind:

SW.Dev

some sort of trademark, possible by only cleaning string 'edges', not deeper inside strings, or by using quotes to avoid ambiguous markup

.SW!Dev.

same as above, can only think of quoting to keep general reduction as the rule and still retain such a special case

SWDev…

common omission mark, somewhat harder to reduce to avoid too much reduction here, maybe solved by quoting too?

Regardless of what I said about quoting as a possible solution to almost all difficult cases, we should still try hard to require it as seldom as possible for convenience. The square bracketed version is common for labeled resource links, I know, but certainly not supported yet. Did it ever work for this plugin. I think no, at least not with tags>=0.6, right? And there has been a demand for caseless matching too. Certainly not exhaustive, but enough for now.

Anyway, thanks for the input, that might come about right as I'm actually in the process of re-defining the (Tag)WikiSyntaxProvider internals regarding quoting and more.

[Ryan J Ollos]

Replying to hasienda:

Regardless of what I said about quoting as a possible solution to almost all difficult cases, we should still try hard to require it as seldom as possible for convenience. The square bracketed version is common for labeled resource links, I know, but certainly not supported yet. Did it ever work for this plugin. I think no, at least not with tags>=0.6, right? And there has been a demand for caseless matching too. Certainly not exhaustive, but enough for now.

I haven't used TagsPlugin prior to 0.6 so I can't say if this was previously supported, and I completely agree with your concerns about feature bloat. My sole reason for reporting is that the behavior for a tags TracLink does not match the behavior for the wiki TracLink. As a user, I was thinking that since I can write "You should checkout the wiki:TagsPlugin.", I should also be able to write "Do a search for tag:rendering.". I need to dig deeper into this, but I think the behavior for the TagsPlugin TracLink should match that for built-in TracLinks.

So I think the key here is to follow the default behavior of Trac. The rules that apply for a TracLink wiki page should probably apply for a TracLink query. I can maybe dig into this over the weekend and submit a patch.

[Steffen Hoffmann]

Replying to rjollos:

Replying to hasienda: ... So I think the key here is to follow the default behavior of Trac. The rules that apply for a TracLink wiki page should probably apply for a TracLink query.

Agree.

I can maybe dig into this over the weekend and submit a patch.

Save your time. As I already mentioned above, I'm already developing a complex patch set, and this will fit it nicely. Looking up the wiki: processor as guidance should be trivial. If you could test my changes after commit, this would be most valuable.

[Ryan J Ollos]

Replying to hasienda:

If you could test my changes after commit, this would be most valuable.

Certainly. I'll be able to test right away.

[Steffen Hoffmann]

Replying to hasienda:

But please allow a general rambling: I remember another ticket where a similar issue has been raised, but for including whole sentences.

See #5523.

[Steffen Hoffmann]

Follow-up on #5523 for stripping punctuation, please.

This ticket remains for the rendering issue related to bracketed tags: link markup

[Steffen Hoffmann]

#10612 has been closed as a duplicate of this ticket, but it has a patch worth reviewing.

[Steffen Hoffmann]

(In [13129]) TagsPlugin: Add unit testing for the tag: TracWiki link resolver, refs #3624, #5523 and #9630.

Currently failing two of the tests due to known issues.

Ryan's proposed patch in #10612 has been helpful to get this done too.

[Steffen Hoffmann]

(In [13131]) TagsPlugin: Allow short notation of bracketed tags: TracLinks, refs #9630.

Applying Ryan J Ollos's fix suggested in his patch attached to #10612, making the corresponding one of the previously failing tests pass now.

[Ryan J Ollos]

Just fixing a typo in the summary.