[mini.completion] Fuzzy matching with blink.cmp algorithm

[abeldekat]

mini_completion_blinked.mp4

Init.lua

---@diagnostic disable: undefined-global
local function setup_deps(path_to_site)
  local mini_path = path_to_site .. "pack/deps/start/mini.nvim"
  if not vim.uv.fs_stat(mini_path) then
    vim.cmd('echo "Installing `mini.nvim`" | redraw')
    vim.fn.system({ "git", "clone", "--filter=blob:none", "https://github.com/echasnovski/mini.nvim", mini_path })
    vim.cmd("packadd mini.nvim | helptags ALL")
    vim.cmd('echo "Installed `mini.nvim`" | redraw')
  end
  require("mini.deps").setup({ path = { package = path_to_site } })
end
setup_deps(vim.fn.stdpath("data") .. "/site/")

local function setup_mini_autocompletion()
  require("mini.snippets").setup() -- only using lsp snippets...
  require("mini.completion").setup({ lsp_completion = { auto_setup = false, source_func = "omnifunc" } })
end

local function custom_on_attach(bufnr) vim.bo[bufnr].omnifunc = "v:lua.MiniCompletion.completefunc_lsp" end

vim.o.completeopt = "menuone,noselect,fuzzy"
vim.o.shortmess = "CFOSWaco"
vim.g.mapleader = " "
MiniDeps.now(function()
  require("mini.notify").setup()

  setup_mini_autocompletion()

  MiniDeps.add("neovim/nvim-lspconfig")
  vim.api.nvim_create_autocmd("LspAttach", {
    group = vim.api.nvim_create_augroup("my.lsp", {}),
    callback = function(args) custom_on_attach(args.buf) end,
  })
  vim.lsp.enable("rust_analyzer")
end)

Example code(rust)

trait State {}

struct Dummy<State> {
    d1: u32,
    // d2:
}

fn main() {
    println!("Hello world!");
}

Sometimes, using provided fuzzy matching does not result in optimal code completion.
In the video above, I am adding PhantomData<State> to the line containing // d2:.

As demonstrated, I need to type State completely before it shows at the top of the completion list. Apparently, State is a word used often inside core rust libraries ...)

The fuzzy-matching part of blink.cmp uses a frecency and proximity bonus. As such, State becomes first in the completion list when I type S.

I want to keep using mini.completion and wrote some code to bridge mini with blink.cmp. The core idea is to override process_items, providing a custom function for opts.filtersort.

I am using blink's fuzzy in the following way:

-- ...
if Util.mini_completion_fuzzy_provider == "blink" then
  require("ak.mini.completion_blinked").setup()
  opts.lsp_completion.process_items = function(items, base)
    local opts = { filtersort = CompletionBlinked.fuzzy }
    return MiniCompletion.default_process_items(items, base, opts)
  end
end
require("mini.completion").setup(opts)
-- ...

[echasnovski]

Sometimes, using provided fuzzy matching does not result in optimal code completion. In the video above, I am adding PhantomData<State> to the line containing // d2:.

As demonstrated, I need to type State completely before it shows at the top of the completion list. Apparently, State is a word used often inside core rust libraries ...)

Yes, this is because there is a high bonus in built-in Vim's fuzzy matching for camel case word start. It also seems to favor matches at the end and not the start.

This was addressed in neovim/neovim#32953, which unfortunately is a Neovim>=0.12 only. So filtersort with vim.fn.matchfuzzy(items, base, { camelcase = false }) should behave more reasonable here. So something like this:

local lsp_get_filterword = function(x) return x.filterText or x.label end
local filtersort = function(items, base)
  if base == '' then return vim.deepcopy(items) end
  return vim.fn.matchfuzzy(items, base, { text_cb = lsp_get_filterword, camelcase = false })
end
local process_opts = { filtersort = filtersort }
local process_items = function(items, base) return MiniCompletion.default_process_items(items, base, process_opts) end
require('mini.completion').setup({ lsp_completion = { process_items = process_items } })

The problem with using this as default is because it will work only if LSP server always returns isIncomplete = true, in which case process_items will be responsible for filtering and sorting after each key press. Some (most?) servers might return isIncomplete = false when there all possible candidates are returned. In this case built-in fuzzy matching takes over and it will sort similar to camelcase = true, which will be not quite intuitive.

Unfortunately, currently there is no way to tweak built-in fuzzy completion behavior (beyond just enabling that). Maybe @glepnir can help with that 👀?

[glepnir]

vim/vim@9d2b727 This commit implements a new algorithm. Continuous matches from the beginning with more than three scores will exceed the camelback. But I finally withdrew this default behavior. Recently I'm thinking that maybe I should add it back. Emm, what is the effect of isInComplete? This means that the current result is incomplete. Subsequent input will still send a completion request and get the result. So you can get the current prefix and then fuzzy it with the new result?

[echasnovski]

vim/vim@9d2b727 This commit implements a new algorithm. Continuous matches from the beginning with more than three scores will exceed the camelback. But I finally withdrew this default behavior. Recently I'm thinking that maybe I should add it back.

I was thinking more about the possible ways for the user to control fuzzy matching in the "true" ins-completion-menu. For example, with 'completeopt=menuone,fuzzy' pressing <C-n> will still have high preference for camel case at the end instead of start. And as far as I understand, there is no way for user to control that, right?

Emm, what is the effect of isInComplete? This means that the current result is incomplete. Subsequent input will still send a completion request and get the result. So you can get the current prefix and then fuzzy it with the new result?

That's more a 'mini.completion' thing. For isIncomplete = true it is possible to adjust camelcase = false behavior after the next key press, because indeed fuzzy matching will eventually go through vim.fn.matchfuzzy(). But for isIncomplete = false the next key press will use built-in fuzzy matching (as this is more performant and less code in 'mini.completion') which can not be adjusted to have camelcase = false like behavior.

[glepnir]

yes. builds the match array, fuzzy sorts by score. there is no way to control the fuzzy behavior here. But I added cot+=nosort before. If the result returned by lsp is sorted by sort text, the result of fuzzy will not be sorted here and the original order will be used.

[echasnovski]

But I added cot+=nosort before. If the result returned by lsp is sorted by sort text, the result of fuzzy will not be sorted here and the original order will be used.

Oh, hmm... That's actually a good idea that I didn't of before. Thanks! I'll experiment a bit.