Less aggressive filtering of code completions - class methods

[cdce8p]

When using code completions, I often wonder if it would be possible to use less aggressive filtering for class / instance methods and attributes. At the moment Pylance requires the first two chars to match before it starts fuzzy matching. Since it would be quite limited, I don't think there would be any noticeable performance issues.

Say for example mock.assert_called_once(). I often think about called and start writing that only to then notice that it doesn't match since I missed as for assert. Enabling fuzzy matching for all chars in that case would make it easier to find what I'm looking for without thinking too much about it.

[jakebailey]

I think we do this mainly so we can limit the number of matches when auto-imports are involved; maybe we should always return full results for "definitely known" members, and then apply the 2 character minimum to auto-imports.

[erictraut]

The 2-character minimum applies only to the auto-import path already. The other code paths use fuzzy matching, but the fuzzy-matching algorithm takes into account how many characters match and don't match. As you type more characters, that ratio changes, and the algorithm will give it a higher matching score. Here's the code for the algorithm if you're interested. I'm in no way wedded to the current algorithm. It was just some heuristics I threw together that seemed to work pretty well. I'm sure we can do better if we play with it.

[cdce8p]

The algorithm itself seems to work pretty good. However I still believe from my testing that the 2-char minimum is active. A few examples:

Only results with the first char matching are shown

No suggestions for mock.ac

If the first two match, fuzzy matching is active

[cdce8p]

It does make sense to enable fuzzy matching only after the first two chars. Otherwise you probably wouldn't filter at all in some cases. However after these two all matching results could be visible, even if only down the list.

[cdce8p]

@erictraut I just looked at the algorithm again and you were probably right. It might be that it doesn't calculate the editDistance correctly if the first char doesn't match. I'm willing to give it a go and see if I can improve / fix it. Is there a way I can test it? Does Pyright exposes the suggestion list one it's own? I would assume I can't use my own version for Pylance, or can I?

https://github.com/microsoft/pyright/blob/b9e61e9f2ae6179284fed8e7b534e5dcb46c8f8b/packages/pyright-internal/src/common/stringUtils.ts#L36-42

[heejaechang]

@cdce8p this part of code, Pylance share core logic with pyright. so, if you change/test based on pyright and check-in, Pylance will get that behavior in v.next release as well.

that being said, it might be better to do the work once we decide on the similar issue as well (#362)

[jakebailey]

This issue has been fixed in version 2020.12.0, which we've just released. You can find the changelog here: https://github.com/microsoft/pylance-release/blob/master/CHANGELOG.md#2020120-2-december-2020