having trouble configuring priority
goolord opened this issue · comments
no matter what i set the priority to, I'm unable to set tabnine's completions to be a lower priority than nvim-lsp's completions.
these lines of code are suspicious:
compe-tabnine/lua/compe_tabnine/init.lua
Line 204 in e27296a
Van you share your compe conf?
https://github.com/goolord/dotfiles/blob/master/home/.config/nvim/lua/plugins/completion.lua
changing tabnine = true;
to tabnine = { priority = 0 }
or tabnine = { priority = 99999 }
seems to have no effect
Since I've been running into this as of late, I'll look into it some a more little later today.
I can confirm that the source isn't ignoring the priority. I set it to 900, and put a print(item['priority'])
after the item priority is set. It was printing out numbers like 900.012.
So it's somewhere else that it breaks.
Ok, so I'm not gonna make a PR to fix this since I don't really know if I should (or if there will be side-effects), but I do know why things are broken: https://github.com/tzachar/compe-tabnine/blob/main/lua/compe_tabnine/init.lua#L200
local item = {
word = result.new_prefix;
user_data = result;
filter_text = old_prefix; -- commenting out this line seems to fix things
}
To explain:
First of all, the problem seems to be that compe never actually gets to the point where it compares the priorities of nvim_lsp and tabnine. It actually ends up deciding that here: https://github.com/hrsh7th/nvim-compe/blob/master/lua/compe/matcher.lua#L278-L280
if item1.match.prefix ~= item2.match.prefix then
return item1.match.prefix
end
Going off of the print statements I put in that file, tabnine's match.prefix
is reliably getting set to true, while nvim_lsp's ends up being nil (which is falsey).
With this source, compe ends up setting that value for us. That's done here: https://github.com/hrsh7th/nvim-compe/blob/master/lua/compe/matcher.lua#L91-L99
Matcher.analyze = function(input, word, match)
-- Exact
if input == word then
match.exact = true
match.prefix = true
match.fuzzy = false
match.score = 1
return match
end
-- I don't think it's possible for us to get past here right now.
-- at least, in this case it isn't.
end
And that function gets called here: https://github.com/hrsh7th/nvim-compe/blob/master/lua/compe/matcher.lua#L13-L28
for i, item in ipairs(items) do
local word = item.original_word
if #input > 0 then
if item.filter_text and #item.filter_text > 0 then
if Character.match(string.byte(input, 1), string.byte(item.filter_text, 1)) then
word = item.filter_text
end
end
end
if #word >= #input then
item.match = Matcher.analyze(input, word, item.match or {})
item.match.index = i
if item.match.score >= 1 then
table.insert(matches, item)
end
end
end
This looks like it's mostly a side-effect of this change to compe: hrsh7th/nvim-compe@6988c33
Which was unfortunately made about half a day after ab4bd13.
So... that's unfortunate.
I referenced the issue on hrsh7th/nvim-compe@6988c339 . Lets see if we can push this forward.
Maybe the solution would be to remove filter_text
from the completion items, but I need to further understand how its used by core compe.
@hrsh7th fixed the issue in hrsh7th/nvim-compe@e2f1cab