Modify

Opened 3 years ago

Closed 4 months ago

#9630 closed defect (fixed)

Non-functional bracketed tags: TracLinks

Reported by: rjollos Owned by: hasienda
Priority: normal Component: TagsPlugin
Severity: normal Keywords: link rendering
Cc: Trac Release: 0.12

Description (last modified by rjollos)

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.


Attachments (1)

ExampleOfDefect.png (31.0 KB) - added by rjollos 3 years ago.

Download all attachments as: .zip

Change History (16)

Changed 3 years ago by rjollos

comment:1 Changed 3 years ago by rjollos

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: Changed 3 years ago by hasienda

  • Keywords link rendering added

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: Changed 3 years ago by rjollos

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.

comment:4 in reply to: ↑ 3 ; follow-up: Changed 3 years ago by hasienda

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.

comment:5 in reply to: ↑ 4 Changed 3 years ago by rjollos

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.

comment:6 in reply to: ↑ 2 Changed 20 months ago by hasienda

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.

comment:7 Changed 15 months ago by hasienda

  • Description modified (diff)
  • Summary changed from A trailing period is incorporated into the TracLink to 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 15 months ago by hasienda

  • Summary changed from Prefix not removed from bracketed tags: TracLinks to 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 15 months ago by hasienda

(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 15 months ago by hasienda

(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 15 months ago by rjollos

  • Summary changed from Non-fuctional bracketed tags: TracLinks to Non-functional bracketed tags: TracLinks

Just fixing a typo in the summary.

comment:12 Changed 5 months ago by rjollos

  • Description modified (diff)

comment:13 Changed 5 months ago by hasienda

In 13730:

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

Newly added permission and resource existance awareness mimics wiki link
behavior for tickets and wiki pages.

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

comment:14 Changed 5 months ago by hasienda

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

comment:15 Changed 4 months ago by hasienda

  • Resolution set to fixed
  • Status changed from new to 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.

Add Comment

Modify Ticket

Action
as closed .
as The resolution will be set. Next status will be 'closed'.
to The owner will be changed from hasienda. Next status will be 'closed'.
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.