having trouble configuring priority

[goolord]

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: https://github.com/tzachar/compe-tabnine/blob/e27296ab377fed567812876bebfd74487062d518/lua/compe_tabnine/init.lua#L204

[tzachar]

Van you share your compe conf?

[goolord]

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

[BurnerWah]

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.

[BurnerWah]

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: https://github.com/hrsh7th/nvim-compe/commit/6988c339a7550ceaae726247865afb346e22b1b0 Which was unfortunately made about half a day after https://github.com/tzachar/compe-tabnine/commit/ab4bd13fed86b38eb5719b83890999bcbc8ad67b. So... that's unfortunate.

[tzachar]

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.

[tzachar]

@hrsh7th fixed the issue in hrsh7th/nvim-compe@e2f1cab