-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[CLOSED] Fix 2663: MultiRangeInlineEditor case #3575
Comments
Comment by dangoor to Interesting side note: I tried searching for "doc" in Sublime (3). Sublime puts DocumentCommandHandlers at the top (just barely). I honestly don't think that captures user intent as well as matching DocumentCommandHandlers. If I type "dch", I'm pretty clearly going for camelCase matches. That's not at all clear when typing "doc", though. |
Comment by dangoor
|
Comment by njx I'll see if I can handle this one since |
Comment by njx Initial review complete. |
Comment by njx
|
Comment by dangoor Closing this one. Will attack as part of other quick open fixes. |
Issue by dangoor
Tuesday May 14, 2013 at 14:26 GMT
Originally opened as adobe/brackets#3819
Note that this branch is built on dangoor/prefer-prefix, which I suspect will land first.
This is a fix for #2663. The original "problem" there is that MultiRangeInlineEditor-test has a backtrack in it, whereas MultiRangeInlineEditor does not, so searching for "multir" results in a different sort of match between the two strings. (MultiRangeInlineEditor vs. MultiRangeInlineEditor-test).
Looking at this result, though, the "fix" (adjusting backtracking behavior to give the same result both times) would change both matches to be more like MultiRangeInlineEditor, when arguably they should be more like MultiRangeInlineEditor.
My fix should make the matching line up with scoring and user intent a bit better. If the user has already typed two characters in a row that match, the code now makes the assumption that the user may be trying to put a contiguous string together and tries that first. I think the results are generally better with this scheme. Note that it changed some pre-existing test cases (for the better, I think).
This change will also probably reduce some cases in which results appear to bounce around in the list as characters are typed.
dangoor included the following code: https://github.com/adobe/brackets/pull/3819/commits
The text was updated successfully, but these errors were encountered: