Community
Participate
Working Groups
In order to style tokens in substring proposals (bug 470203), a new search pattern R_SUBSTRING_MATCH is required along with the corresponding support in SearchPattern.getMatchingRegions(String pattern, String name, int matchRule).
New Gerrit change created: https://git.eclipse.org/r/62814
(In reply to Eclipse Genie from comment #1) > New Gerrit change created: https://git.eclipse.org/r/62814 With this patch, if the pattern is "eq" and name is "contentEquals(CharSequence cs)" for a method proposal, the matching region contains the range for the "eq" in parameter type "CharSequence" as well, which is not required. Another example - pattern "k" and name "checkBackground" - returns ranges for both the "k"s in name. I think it should be in sync with CharOperation#checkSubstringMatch, so just using String#indexOf should be good for now. If CharOperation#checkSubstringMatch is changed later to include non-consecutive occurrence of pattern characters then we will have to update the same in #getMatchingRegions also.
(In reply to Noopur Gupta from comment #2) > (In reply to Eclipse Genie from comment #1) > > New Gerrit change created: https://git.eclipse.org/r/62814 > > With this patch, if the pattern is "eq" and name is > "contentEquals(CharSequence cs)" for a method proposal, the matching region > contains the range for the "eq" in parameter type "CharSequence" as well, > which is not required. > Another example - pattern "k" and name "checkBackground" - returns ranges > for both the "k"s in name. > > I think it should be in sync with CharOperation#checkSubstringMatch, so just > using String#indexOf should be good for now. > > If CharOperation#checkSubstringMatch is changed later to include > non-consecutive occurrence of pattern characters then we will have to update > the same in #getMatchingRegions also. Noopur: The assumption was that only the method name will be given for getMatchingRegions and not with parameters. In the case mentioned by you, it includes the parameters as well. Ideal case will be for the jdt.ui to pass the method name. If that is not possible can you enumerate the list of terminal tokens which I should be looking at - in the case its "(". What else should I expect and process, say '<' for eg?
(In reply to Manoj Palat from comment #3) > (In reply to Noopur Gupta from comment #2) > > (In reply to Eclipse Genie from comment #1) > > > New Gerrit change created: https://git.eclipse.org/r/62814 > > > > With this patch, if the pattern is "eq" and name is > > "contentEquals(CharSequence cs)" for a method proposal, the matching region > > contains the range for the "eq" in parameter type "CharSequence" as well, > > which is not required. > > Another example - pattern "k" and name "checkBackground" - returns ranges > > for both the "k"s in name. > > > > I think it should be in sync with CharOperation#checkSubstringMatch, so just > > using String#indexOf should be good for now. > > > > If CharOperation#checkSubstringMatch is changed later to include > > non-consecutive occurrence of pattern characters then we will have to update > > the same in #getMatchingRegions also. > > Noopur: The assumption was that only the method name will be given for > getMatchingRegions and not with parameters. In the case mentioned by you, it > includes the parameters as well. Ideal case will be for the jdt.ui to pass > the method name. If that is not possible can you enumerate the list of > terminal tokens which I should be looking at - in the case its "(". What > else should I expect and process, say '<' for eg? As of now, SearchPattern#getMatchingRegions was invoked only for Open Type dialog from jdt.ui which directly passed the type name or package string as the search string because we could easily split the qualified type name based on '-' in the display string. With content assist, the search string being passed (from AbstractJavaCompletionProposal) is the display string of a proposal, which can be any proposal like a method, field, type, package, keyword etc. > can you enumerate the list of terminal tokens Looking at the display strings of the proposals, I can see '-' for types, '(' for methods and ':' for fields. Instead of passing the entire display string from AbstractJavaCompletionProposal in jdt.ui, we can pass only the substring upto '(', ':' or '-', whichever is found first in this order in the display string. Let me know if this is required. > > Another example - pattern "k" and name "checkBackground" - returns > > ranges for both the "k"s in name. For this case, the result should still contain only the first 'k'.
(In reply to Noopur Gupta from comment #4) > > As of now, SearchPattern#getMatchingRegions was invoked only for Open Type > dialog from jdt.ui which directly passed the type name or package string as > the search string because we could easily split the qualified type name > based on '-' in the display string. ok. > Instead of passing the entire display string from > AbstractJavaCompletionProposal in jdt.ui, we can pass only the substring > upto '(', ':' or '-', whichever is found first in this order in the display > string. Let me know if this is required. Yes. Let the jdt.ui pass only the substring upto the terminal char > > > > Another example - pattern "k" and name "checkBackground" - returns > > > ranges for both the "k"s in name. > > For this case, the result should still contain only the first 'k'. ok.
(In reply to Manoj Palat from comment #5) > (In reply to Noopur Gupta from comment #4) > > Instead of passing the entire display string from > > AbstractJavaCompletionProposal in jdt.ui, we can pass only the substring > > upto '(', ':' or '-', whichever is found first in this order in the display > > string. Let me know if this is required. > > Yes. Let the jdt.ui pass only the substring upto the terminal char Updated https://git.eclipse.org/r/#/c/60936/ accordingly.
(In reply to Noopur Gupta from comment #6) > > Updated https://git.eclipse.org/r/#/c/60936/ accordingly. Thanks Noopur. Resolving this jdt.core bug.
(In reply to Manoj Palat from comment #7) > (In reply to Noopur Gupta from comment #6) > > > > Updated https://git.eclipse.org/r/#/c/60936/ accordingly. > Thanks Noopur. Resolving this jdt.core bug. I don't see the fix in master branch of jdt.core repo yet.
.
(In reply to Dani Megert from comment #9) > . Is this "." an old habit or still necessary after Bug 481803? If yes, we should open a new bug to make this not necessary.
(In reply to Lars Vogel from comment #10) > (In reply to Dani Megert from comment #9) > > . > > Is this "." an old habit No, not an old habit and not affected by the bug you cited. That bug was about closing bugs and not about reopening. Feel free to file a new bug.
(In reply to Dani Megert from comment #11) > No, not an old habit and not affected by the bug you cited. That bug was > about closing bugs and not about reopening. Feel free to file a new bug. Bug 485222.
Gerrit change https://git.eclipse.org/r/62814 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=1e32662c898d48e42c11c75277a879371be6f4bc
Verified for 4.6 M5 using Version: Neon (4.6) Build id: I20160119-0800
