You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue was originally over at emacs-lsp/lsp-python-ms#79, but upon investigation, it seems that it could be a problem with company-lsp.
OS and emacs version:
I'm on macOS with Emacs 27.0.50
The problem only arises with mspyls in emacs. I've made sure by running pyls in emacs, as well as mspyls in VScode and none of the issues happened.
Description:
To reproduce the problem in a python buffer with mspyls + lsp-mode enabled, supposed we're trying to have autocompletion for print(). Start off by typing p followed by r and i, n etc. and we'll see the candidates narrow down and become fewer.
Specifically, at prin we'll see that only 5 candidates are present, namely, print, ImportWarning, StopIteration..... Of course, this is due to the fuzzy match result.
The strange thing now happens as soon as I hit t to complete print. Now with either mspyls in VSCode or pyls in emacs, only a single candidate print will remain in the tooltip. However, with mspyls in emacs, the tooltip is suddenly filled with hundreds (maybe more) of unrelated candidates such as if, else, bin, bool, break, AttributeError, compile, continue, copyright etc. As if it was a completion for a wildcard character.
Further investigation:
I have set company-lsp-cache-candidates to t, nil, and 'auto and compared the results. Here's my observation:
The behaviour I described in the title only happens if company-lsp-cache-candidates is set to 'auto.
If company-lsp-cache-candidates is set to t, I will miss several fuzzy-matched candidates, but no unrelated candidates show up either.
If set to nil, the completion works ideal as one would expect -- no unrelated candidates, and fuzzy-matched ones are present too. However, I feel that emacs slows down / lags a bit with this option.
The text was updated successfully, but these errors were encountered:
This issue was originally over at emacs-lsp/lsp-python-ms#79, but upon investigation, it seems that it could be a problem with company-lsp.
OS and emacs version:
I'm on macOS with Emacs 27.0.50
The problem only arises with mspyls in emacs. I've made sure by running pyls in emacs, as well as mspyls in VScode and none of the issues happened.
Description:
To reproduce the problem in a python buffer with mspyls + lsp-mode enabled, supposed we're trying to have autocompletion for
print()
. Start off by typingp
followed byr
andi
,n
etc. and we'll see the candidates narrow down and become fewer.Specifically, at
prin
we'll see that only 5 candidates are present, namely,print
,ImportWarning
,StopIteration
..... Of course, this is due to the fuzzy match result.The strange thing now happens as soon as I hit
t
to completeprint
. Now with either mspyls in VSCode or pyls in emacs, only a single candidateprint
will remain in the tooltip. However, with mspyls in emacs, the tooltip is suddenly filled with hundreds (maybe more) of unrelated candidates such asif
,else
,bin
,bool
,break
,AttributeError
,compile
,continue
,copyright
etc. As if it was a completion for a wildcard character.Further investigation:
I have set
company-lsp-cache-candidates
tot
,nil
, and'auto
and compared the results. Here's my observation:company-lsp-cache-candidates
is set to'auto
.company-lsp-cache-candidates
is set tot
, I will miss several fuzzy-matched candidates, but no unrelated candidates show up either.nil
, the completion works ideal as one would expect -- no unrelated candidates, and fuzzy-matched ones are present too. However, I feel that emacs slows down / lags a bit with this option.The text was updated successfully, but these errors were encountered: