Skip to content
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

Open
core-ai-bot opened this issue Aug 29, 2021 · 6 comments
Open

[CLOSED] Fix 2663: MultiRangeInlineEditor case #3575

core-ai-bot opened this issue Aug 29, 2021 · 6 comments

Comments

@core-ai-bot
Copy link
Member

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

@core-ai-bot
Copy link
Member Author

Comment by dangoor
Tuesday May 14, 2013 at 14:32 GMT


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.

@core-ai-bot
Copy link
Member Author

Comment by dangoor
Thursday May 16, 2013 at 16:14 GMT


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

@core-ai-bot
Copy link
Member Author

Comment by njx
Thursday Jun 13, 2013 at 22:37 GMT


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.

@core-ai-bot
Copy link
Member Author

Comment by njx
Tuesday Jun 18, 2013 at 01:41 GMT


Initial review complete.

@core-ai-bot
Copy link
Member Author

Comment by njx
Monday Sep 30, 2013 at 21:47 GMT


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

@core-ai-bot
Copy link
Member Author

Comment by dangoor
Wednesday May 14, 2014 at 18:22 GMT


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

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

No branches or pull requests

1 participant