Community
Participate
Working Groups
This team I'm with uses // TODO task tags a lot. My name is Andreas Krüger, so to mark stuff I personally need to work on, I use tags // TODO AK I assign "high" priority to these tasks, to make it easier for me to find them. This works - but only if my personal tag happens to be listed above the normal one in Windows / Preferences / Java / Task Tags . For one thing, it is not easy to get it there. But this is a workaround only, and besides the point. In my opinion, the algorithm should be sequence-independent.
Are you suggesting matching the longer tags first or making the tag order both significant and settable with up/down buttons?
This is a JDT core issue. I don't think the order in the UI should matter. Core should match longer sequences first.
I think matching the longest tag first is exactly the wrong thing to do. I no place is this implied by the UI, and the UI is what the user sees. Either they should be matched in the order shown in the UI or they should all be matched all of the time.
And if the order in the UI does become significant, there should be buttons added to reorder the tags.
*** Bug 102569 has been marked as a duplicate of this bug. ***
The task tag definition order should not matter. The longest tag should always match when more than one tag start with the same characters.
Created attachment 74386 [details] Proposed fix With this patch, the longest match works fine. The user can define task tags like: TODO, TODO!, TODO? or TODO AK, TODO, FIXME and get the proper priority reported. However this leads to a bug in the syntax highlighting. The highlighted part doesn't correspond to the right tag. See bug 197530 for details.
(In reply to comment #3) > I think matching the longest tag first is exactly the wrong thing to do. Why? I believe the longest match is exactly what users are expecting to see.
Created attachment 74463 [details] Proposed fix + regression test
Created attachment 74464 [details] Proposed fix + regression test I forgot to include the right regression test.
Released for 3.4M1. Regression test added in org.eclipse.jdt.core.tests.builder.BasicBuildTests#testTags4
(In reply to comment #8) > (In reply to comment #3) > > I think matching the longest tag first is exactly the wrong thing to do. > Why? I believe the longest match is exactly what users are expecting to see. Matching from the list in the order shown is what I'd expect.
*** Bug 198072 has been marked as a duplicate of this bug. ***
(In reply to comment #12) > Matching from the list in the order shown is what I'd expect. As long as the UI has no way to sort the items in the list, this is not possible as some tasks could never be used (TODO! vs TODO). The longuest match has been implemented.
(In reply to comment #14) > (In reply to comment #12) > > Matching from the list in the order shown is what I'd expect. > As long as the UI has no way to sort the items in the list, this is not > possible as some tasks could never be used (TODO! vs TODO). Admittedly I'm not volunteering to implement it at the moment, but maybe it *should*?
Verified for 3.4M1 using build I20070806-1800. Note that UI still does not color correctly tags with white spaces (in 'TODO AK', only 'TODO' is colored as a task tag, 'AK' is still colored as a part of a comment text) but this is already described in bug 58205...
