Community
Participate
Working Groups
3.3 Often you want to find a string in a comment or string literal which can also be in a class file (resp. its attached source). We see two approaches: a.) add it to file search: Extensions can provide source content to archive files and class files. File search then would use these files instead of the binary content to search b.) add it to Java search: Add a new search option 'Text references' I believe there are two many problems with a.): How to present matches (file search result view only shows resources), how to open a match, what if the user really wants to search the content of the binary file, how to specify a scope b.) has the advantage that the search scope are Java aware, the result view shows Java elements, etc. The question is, where would b.) be implemented. It could be implemented in the UI, as we know how to visit all Java files and look at their content. But maybe it would be better if jdt.core does it, as the search could also be useful for other clients.
Adding Jerome and Frederic for opinions. We have added this item to our (proposed) 3.4 plan.
There's already a request on JDT/Core for this kind of search: bug 16426. Not sure that current SearchEngine would allow this kind search of without deep changes...
I think a brute force text search (no index) would be good enough. That's what we also do in file text search.
(In reply to comment #3) > I think a brute force text search (no index) would be good enough. That's what > we also do in file text search. > How would that scale ?
Yes, according to our experiences in text search this scales well for common user scenarios.
Besides finding stuff in comments it would be very useful to find where constants are references - something that Java search currently can't do for .class files. Personally I'd like to see this implemented in JDT Core and not JDT UI.
There are 2 issues here. 1. pure text search in attached sources 2. java text search in comment/literals
>There are 2 issues here. >1. pure text search in attached sources This is what I would like to see most. Would use this to find constant refs and code patterns. >2. java text search in comment/literals What exactly do you mean with 'java text'? Types, members etc? Keywords? A simple text search where I can select the scope (string literal, documentation comment, traditional comment, end-of-line comment, all) would fit needs.
Regarding the search scope (only comments, only literals..) I think we should keep the search as general as possible but offer the possibility to limit matches to - comments - literals But if the user wants, he can also use reg-ex on the code.
Moving to JDT core as discussed.
Time permitting for 3.4
This involves API. We should decide now whether we do this for 3.4.
Not for 3.4
One idea would be to ask Platform/Resources to have EFS leverage JAR entries as resources
> One idea would be to ask Platform/Resources to have EFS leverage JAR entries as > resources That would then be bug 23341, which is blocked by bug 23265. But I would rather go into the direction of comment 7 and comment 8 and add a source-attachment-aware brute-force textual search. E.g. add something like SearchEngine.searchText(String pattern, int matchRule, IJavaSearchScope, SearchRequestor, IProgressMonitor), where matchRule supports SearchPattern.R_EXACT_MATCH, R_REGEXP_MATCH, R_CASE_SENSITIVE. The reported results would be of type TextSearchMatch, which also has queries isInsideLineComment(), isInsideBlockComment(), isInsideStringLiteral(), or even int getEnclosingTokenId() (which returns a constant from ITerminalSymbols) and maybe int[] getCoveredTokenIds() (which returns a set of ids of all tokens that intersect with the match range).
Targeting 3.5 for a brute force solution.
It seems that the main purpose of this bug is to address the "constant reference in .class files" issue. This is bug 12044. Once this is addressed, we can address the pure text search issue providing some support from Platform/Search (e.g. we would implement an extension point to give the source to search to the text search framework).
Suggest to wait for bug 23341.
Actually this bug is blocked by bug 23341. Moving 23341 from "Blocks:" to "Depends on:". Also removing this bug from JDT/Core plan for 3.5 (unless bug 23341 is resolved :-) )
>Actually this bug is blocked by bug 23341. Moving 23341 from "Blocks:" to >"Depends on:". Right, pasted too fast.
*** Bug 237159 has been marked as a duplicate of this bug. ***
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
