Community
Participate
Working Groups
First thanks for a great job on 3.1 - excellant! I have the following set up in /Window/Preferences/Task tags: - Tag:todo (default), Priority:Normal - Tag:todo!, Priority:High - Tag:todo?, Priority:Low The "Tasks" view does not show the different priorities - it shows then all as 'Normal' priority. I would also suggest that the platform be shipped as default with these task tags. They are intuitive and a change would be backward compatible. Thanks again for your hard work.
These are nice interesting tags, but the standard is more in favour of TODO, FIXME and XXX. Still it should work properly with these.
Philippe, is this a candidate for 3.1.1?
Will depend on fix risk.
Looks like it is a duplicate of 97315 - a known problem. It is a major loss of functionality for us. We have hundreds of tags and depend on the priority sorting for organizing the current work. May I request to upgrade the Severity to "Major"? Thanks.
This is a different problem. The bug 97315 refers about the wrong priority to be set. I found the problem in the abstract image builder. This problem is related to the fact that several tasks start with the same characters. The shortest one is selected.
I was wrong. This is a duplicate of bug 91426. Once I apply the fix for bug 91426, I get the right priority for each task tag. *** This bug has been marked as a duplicate of 91426 ***
This is another bug. If more than one task starts with the same character, we select the first one. I will work on a fix.
I added the following comment in the JavaCore.getDefaultOptions() Note: the tasks are ordered, and the first matching tag will be selected; e.g. "TODO!,TODO" will match "TODO!" against "TODO" first. I think the UI should propose a "UP" and "DOWN" buttons to allow the user to specify his own order. The alphabetic order might not be the desired one. Moving to JDT/UI.
The note should read: Note: the tasks are ordered, and the first matching tag will be selected; e.g. "TODO,TODO!" will match "TODO!" against "TODO" first.
Adding Up and Down buttons is IMO confusing for the user since there is already a priority field. It will be hard to explain what Up/Down would mean since it will not affect all tags (only those with common prefixes). Why don't we simply sort the task tags so that tags with common prefixes are ordered in a way that longer onces appear before shorter onces. This is what the user expect to happen anyway so there is no need for an additional user interface. Olivier, could the sorting be done in JDT/Core ?
The preference page doesn't allow you to enter two tags with the same name, regardless if they have a different severity. So the problem is only about tags that a prefix of an other tag. When matching, the longest match should always be preferred. Using the order doen't make much sense to me. Why would the user ever want to sort the longer behind the shorter? It would never result in any matches.
The severity is independant from the ordering of tags. The implementation is already order sensitive, and it would be the least amount of changes to reflect this in the UI. Note that it would be consistent with the handling of access rules or classpath entries. But indeed it only matters in presence of conflicting tags.
Also see comments in bug 53727 for motivation on allowing ordering vs. sorting. Note that for backward compatibility purpose, having JDTCore start to do the sorting would be non intuitive (we never do this in other APIs) and would change some contracts. Selecting the first match is likely a more straightforward approach.
The original reporter in bug 53727 and in bug 53727 comment 2 both want the 'longest match wins' behaviour. It is IMO the intuitive and expected behaviour and does not further complicate the UI. We had bug reports requesting the UI to sort the elements form users that had a large number of task tags. The ordering of tags was so far unspecified by jdt.core. In jdt.ui we used this fact to always put the 'default' tag first (the default tag is the tag used with the ${todo} code template variable). All users so far had to use our UI and did not/could not care about the order of all entries except the first one. Please stay backward compatible and keed the order of the entries unspecified. Again: it makes no sens to order a longer name behind a substring of itself. Why even offer this to the user?
Backward compatibility imposes we remain order sensitive: i.e. first match is selected and has always been. UI is doing some sorting already (alphabetical), so to me either you make it smarter (considering tag length) or you make it user controlled with ordering buttons. Having the UI reflects what is going on underneath is likely the best approach here; and having JDTCore be order sensitive is the most powerful way (allows hiding etc...). Try to add tag 'aaa', you'll see it added first to the list; even though it isn't default.
And to clarify, we are not suddenly making the order specified; we always did but never surfaced it inside our API doc. All we propose to do is to fix the doc to reflect what the implementation does.
Here are my 2 cents: - what users want to have is that longer tags match before shorter ones. There isn't a single request to allow arbitrary odering for matching and I think it isn't needed in the future. Ordering them would only make sense for me if we support patterns. - the algorithm in JDT/Core is currently unspecified Option one: - JDT/UI (and all other clients) have to make sure that the tags are ordered in a way so that longer tags appear before shorter in the list so that we get the wanted behaviour with the current implementation in JDT/Core. Option two: - JDT/Core implements the longest match first algorithm. Since the semantic of the method is currently not speced I think changing it should be fine. From an API point of view I prefer option two (if we would start with a new method I think that's what we would implement). Philippe, what are your main objections regarding changing the behaviour in core ?
A bug that got forgotten... As mentioned, we think the correct implementation and what users expect is to always match for the longest match. As this isn't yet specified I think it's fine to introduce that behaviour. Moving to jdt.core.
Agreed - longest match is what makes sense to me.
Let' see what we can do.
*** This bug has been marked as a duplicate of bug 53727 ***
Verified for 3.4M1 using build I20070806-1800.
