Skip to content
This repository has been archived by the owner on Sep 6, 2021. It is now read-only.

Fix 2663: MultiRangeInlineEditor case #3819

Closed
wants to merge 2 commits into from

Conversation

dangoor
Copy link
Contributor

@dangoor dangoor commented May 14, 2013

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.

…earches when the user has

typed at least two contiguous matching characters.
@ghost ghost assigned peterflynn May 14, 2013
@dangoor
Copy link
Contributor Author

dangoor commented May 14, 2013

to @peterflynn ... hopefully this is not as painful to review as other changes to the StringMatch algorithm. The change itself is fairly straightforward, and I think it's helpful, but I am open to the idea that this may not be the right sort of change.

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.

@dangoor
Copy link
Contributor Author

dangoor commented May 16, 2013

@peterflynn The dangoor/prefer-prefix branch has landed, so the "Files Changed" is now nice and small.

@ghost ghost assigned njx Jun 13, 2013
@njx
Copy link
Contributor

njx commented Jun 13, 2013

I'll see if I can handle this one since @peterflynn is out and it looks like he hasn't started on it yet. Nominating for sprint 27.


if (contiguousCount < 2) {
if (state === SPECIALS_MATCH) {
if (!findMatchingSpecial()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that there's an else, it might be clearer to reverse the sense of this if.

@njx
Copy link
Contributor

njx commented Jun 18, 2013

Initial review complete.

@njx
Copy link
Contributor

njx commented Sep 30, 2013

@dangoor - just noticed this was still open, if you feel like working on it some more sometime soon :) See comments above.

@dangoor dangoor closed this May 14, 2014
@dangoor dangoor deleted the dangoor/2663-odd-quickopen branch May 14, 2014 18:22
@dangoor
Copy link
Contributor Author

dangoor commented May 14, 2014

Closing this one. Will attack as part of other quick open fixes.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants