Opened 8 years ago

Closed 6 years ago

## #9630 closed defect (fixed)

Reported by: Owned by: Ryan J Ollos Steffen Hoffmann normal TagsPlugin normal link rendering 0.12

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.

### comment:1 Changed 8 years ago by 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]


### comment:2 follow-ups:  3  6 Changed 8 years ago by 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.

### comment:3 in reply to:  2 ; follow-up:  4 Changed 8 years ago by Ryan J Ollos

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.

### comment:4 in reply to:  3 ; follow-up:  5 Changed 8 years ago by Steffen Hoffmann

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.

### comment:5 in reply to:  4 Changed 8 years ago by Ryan J Ollos

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

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

### comment:6 in reply to:  2 Changed 7 years ago by Steffen Hoffmann

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

See #5523.

### comment:7 Changed 7 years ago by Steffen Hoffmann

Description: modified (diff) A trailing period is incorporated into the TracLink → Prefix not removed from bracketed tags: TracLinks

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

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

### comment:8 Changed 7 years ago by Steffen Hoffmann

Summary: Prefix not removed from bracketed tags: TracLinks → Non-fuctional bracketed tags: TracLinks

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

### comment:9 Changed 7 years ago by 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.

### comment:10 Changed 7 years ago by 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.

### comment:11 Changed 7 years ago by Ryan J Ollos

Just fixing a typo in the summary.

### comment:12 Changed 6 years ago by Ryan J Ollos

Description: modified (diff)

### comment:13 Changed 6 years ago by Steffen Hoffmann

In 13730:

TagsPlugin: Reworked wiki link resolver code, refs #3624, #5523 and #9630.

behavior for tickets and wiki pages.

Unit tests have been refactored too, partially with more reasonable test cases.

### comment:14 Changed 6 years ago by Steffen Hoffmann

All unit tests passing now (tested in Trac 1.1.1), good.

### comment:15 Changed 6 years ago by Steffen Hoffmann

Resolution: → fixed new → closed

In 13815:

TagsPlugin: Completing preparation for v0.7 release.

Availability of that code as stable, tagged release
closes #2429, #3359, #3610, #3624, #3677, #3754, #3864, #3947, #3983, #4078, #4277, #4503, #4799, #5523, #7787, #7857, #8638, #9057, #9058, #9059, #9060, #9061, #9062, #9063, #9149, #9210, #9521, #9630, #9636, #10032, #10416, #10636, #11096, #11147, #11152, #11274, #11302, #11658 and #11659.

Additionally there are some issues and enhancement requests showing progress,
but known to require more work to resolve them satisfactorily, specifically
refs #2804, #4200, #8747 and #9064.

Thanks to all contributors and followers, that enabled and encouraged a good
portion of this development work.

### Modify Ticket

Change Properties