Community
Participate
Working Groups
I20050112-1200 On Ctrl+Click and 'Navigate > Open (F3)', the Properties File editor starts a lengthy search for references to the selected property key. This is a fairly unusual action, and it is confusing for the user that a seemingly quick command needs so much time when invoked in the Properties File editor. The Java Editor always jumps to the declaration of the current item, which is always a fast operation. The right command for this 'property key reference search' would be 'Search > References > Workspace'. This would also solve the problem of displaying multiple targets; the Search view is perfect for this.
So, to summarize: remove the Ctrl+Click feature? This is not an option.
Yes, remove the Ctrl+Click feature and use well-established eclipse interactions. The current solution feels like a hack for people used to working with the java editor: - You get a modal progress dialog during the search -> In Eclipse 3.x, long-running jobs should be done in the background. - The results are presented in a modal dialog -> The user can only jump to one search result at a time. To jump to another reference, the whole search must be repeated. - Ctrl+Click and 'Navigate > Open (F3)' used to jump to 'the thing under the cursor'. 'Search > References' used to be the way to search for references.
We could add a time-out (==> preference): if it doesn't find matches in that timeout a search will be started and you can continue working. 0 would mean to always search.
OK, that sounds like a fair solution for everyone :-). I've opened bug 83066 as a request for 'Search > References' support.
Markus, are you still seeing this as an issue?
> Markus, are you still seeing this as an issue? Yes, especially when I do this in the jdt.ui plug-in, where I have to watch a progress bar for 2000 .java files, and I know that the whole delay is unnecessary anyway because we use the Eclipse NLS mechanism...
Currently we first do a text search and if that fails then we do a Java search for Eclipse style NLS strings. Simplest solution could be to reverse the search order, iff the Java search is fast enough. Or is there a quick way to detect if Eclipse style NLS strings are used or not?
(In reply to comment #7) > Currently we first do a text search and if that fails then we do a Java search > for Eclipse style NLS strings. Simplest solution could be to reverse the search > order, iff the Java search is fast enough. Java search is fast enough with o.e.jdt.ui plugin - works almost as fast as F3 in Java Editor. Hence I think we can change the order of search, i.e. first do a Java Search (fast) and then do a text search (slow). Will attach a patch..
Created attachment 182506 [details] fix Patch for > Hence I think we can change the order of search, i.e. first do > a Java Search (fast) and then do a text search (slow).
(In reply to comment #9) > Created an attachment (id=182506) [details] [diff] > fix > > Patch for > > Hence I think we can change the order of search, i.e. first do > > a Java Search (fast) and then do a text search (slow). Fixed in HEAD.
Verified for 3.7 M4 with I20101206-1800.
This fix causes bug 388112.
