Closed AmaiKinono closed 4 years ago
Could you give me a minimum example and exact steps to reproduce the issue?
Sure.
Make sure you checkout 0.0.3 tag in this repository. I found later versions seem to break things.
Put this TAGS file in an empty directory: TAGS.tar.gz
emacs -Q
, require company
and company-ctags
.
Create a file in that directory, open it using this Emacs session. Make sure you are in some prog-mode
. Type M-x company-mode
.
Type fu
, then M-x company-ctags
, you'll see the candidates. They are func_01
, func_02
and func_03
.
Cancel it using C-g
. Call company-ctags
again, there will be only one candidate func_03
. Now if you complete anything like func
, func_
which starts with fu
, same thing happens.
Checkout my branch and do the same test, the problem is fixed.
anyway, I already solved the issue in fuzzy match. It's actually just one line fix.
The
company-ctags-cached-candidates
is composed of theprefix
company gives us, and therlt
, which is the candidates we hand over to company later. Sincerlt
is just a reference to the actual value, company can do anything it wants to the candidates, and that affects our cache.This shows the problem:
company-ctags
gives me the right candidates the first time, but when I want to completefunc
again, it only gives mefunc_03
. Then we printed the cache, you can see only "func_03" is left there. This is caused by company. If you insert aprint
statement in the end ofcompany-ctags--candidates
, you'll see it has all the candidates.So, we have to cleanup the cache after a completion session finishes, or actually copy the candidates when building the cache. Since the main usage of the cache is limited to current completion session, I took the former approach. Please see if the implementation is reasonable.