-
Notifications
You must be signed in to change notification settings - Fork 7.6k
Code hinting should sort by scope #3534
Comments
I'm going to label this a medium priority, because I think the ordering is very important for code hints (because it determines how much you need to type or how many times you need to hit the arrow key) |
Scope is a secondary sort. The primary sort is matchGoodness. What I'm seeing is "str" and "String" have the same matchGoodness (-279). "stringMatch" has a matchGoodness of -278 and "StringMatcher" is -277. If "String", "stringMatch" and "StringMatcher" all had the same matchGoodness score then "String" would be sorted below them. Does StringMatcher has a mode where all prefix matches are considered equal? |
No... I think the difference there is the length penalty. My comment in the review for the initial pull request was that scope could either be the primary sort and matchGoodness secondary, matchGoodness can be boosted based on scope. Boosting matchGoodness is probably better because the user can type something that more clearly points to a global but might also happen to match something closer in scope. The trick with boosting matchGoodness would be figuring out the right boost. It's always a bit of guesswork because it's trying to be psychic about what the user intends. One possibility would be something like 25 points for each scope level. So, if there were 4 levels, 75 points for innermost, 50 for module level, 25 for globals, 0 for keywords. |
Boosting matchGoodness seems pretty tricky. I would expect all the prefix matches, including builtin globals, to be listed before matches in the middle of hints. |
I have a fix that in the hinter that makes prefixes matches sort to the top by setting the matchGoodness to negative Number.MAX_VALUE. |
OK, I can buy that (and this appears to be the case with my fix in #3411), and my statement in the original description "globals and keywords should always be lower than the others" is not the right solution. The case that I started with here, though, is one where I have prefix matches on a local variable (str), variables in the current function's closure (stringMatch, StringMatcher) and a global (String). All else being roughly equal, I'd rather see the global appear below those others. |
Changing this to low priority, because I think #3411 is actually the more important one than this one. |
The global will appear below those because my fix sets all of the prefix matches to the same score, overriding any length penalty. |
Sent a pull request with the fix. |
Oh, I see what you're saying. The results also seem good to me just doing this in Session.js in my branch for #3493:
|
Subtracting 25 seems mysterious and heavily tied to how the matcher scores. It may work in one case but not in another. I think making prefix matches equal and letting the sort do the rest is a more robust solution. |
The solution presented in #3552 does not always guarantee that a prefix match will be the winner. stringMatch gives preference to matches on word boundaries (including camelCase). Here's a contrived example: To guarantee that prefix matches come out on top, It would likely be easy for me to add a flag to string match to actually check for a prefix match first and if it finds one to max out |
In most cases, #3493 will indeed prefer prefix matches, but it's not guaranteed. I think that's an improvement to the matching in general. I just pushed #3588 which adds a preferPrefixMatch option which checks for a prefix match (case insensitive check), short circuits all other matching behavior when it finds one and also sets the matchGoodness to -Number.MAX_VALUE just as you had. My current pull request doesn't set that option in the JS code hinting. Perhaps I should just do so, since that was the reason for adding the new option. |
Adding this option to string matching provides a fix for #3534 by putting the matches at the same score and using the scope as a tie breaker.
OK, I updated the pull request in #3588 to turn the option on for JS code hinting and it fixes this issue. |
Reviewed, tagged for Sprint 25 |
Fixed by filer. Closing. |
Steps to reproduce:
StringMatcher.prototype.match
(I used the top of the function)Expected:
str
on top followed bystringMatch
andStringMatcher
.Actual:
str
on top, followed byString
followed bystringMatch
andStringMatcher
Globals and keywords should always be lower than the others.
The text was updated successfully, but these errors were encountered: