Fuzzy matching does not work on an arbitrary parts of the compl item

[asmodeus812]

I have had this annoying pet peeve which is regarding the way cmp would not allow us to complete fuzzy-ly words or parts of the completion item, be in at start mid or end, mostly mid and end. Here is an example:

Starting off from the list of Collections. I want to filter out all methods which are related to mapping most of which look like that {noun}{verb}Map

Writing down map, suggests max, which is wrong, there are a ton of methods from Collections which end in Map or map. Which is what i am aiming for here, the only way to resolve this is to remember how the method starts or what exact words follow each other to match it is a pain. But even that is not correct, since what i know Collections has some map methods, but i do not remember what exactly, to remind myself, I want is to see all map related methods, with whatever prefix strings they have.

Here is a preview of some map related methods

Here is my config

        completion = {
            keyword_length = 2,
        },
        snippet = {
            expand = snip_expand_body,
        },
        formatting = {
            fields = { "kind", "abbr", "menu" },
            format = function(entry, vim_item)
                vim_item.kind = string.format("%s", kind_icons[vim_item.kind])
                vim_item.menu = menu_types[entry.source.name]
                return vim_item
            end,
        },

        experimental = {
            ghost_text = false,
            native_menu = false,
        },
        sources = sources,

[jaynis]

I suffer from exactly the same problem. I played around with the following fuzzy matching options but none of them seem to enable the desired behavior which is to simply fuzzy match my input across all parts of each completion candidate:

matching = {
  disallow_fuzzy_matching = <bool>,
  disallow_fullfuzzy_matching = <bool>,
  disallow_partial_fuzzy_matching = <bool>,
  disallow_partial_matching = <bool>,
  disallow_prefix_unmatching = <bool>,
  disallow_symbol_nonprefix_matching = <bool>,
}

Did you find a solution to this @asmodeus812?

[asmodeus812]

I have been using coc for a while now, one of the primary reasons being exactly this. Coc implements a much better autocomplete, ported from vscode.

[jaynis]

I looked into this a bit further and the option we are interested in definitely seems to be disallow_prefix_unmatching which defaults to true and has to be set to false to enable the matching of arbitrary parts even if the prefix does not match. You can see this in the following test:

nvim-cmp/lua/cmp/matcher_spec.lua

Lines 86 to 89 in a110e12

	it('disallow_prefix_unmatching', function()
	assert.is.truthy(matcher.match('bar', 'foo_bar', { disallow_prefix_unmatching = true }) == 0)
	assert.is.truthy(matcher.match('bar', 'foo_bar', { disallow_prefix_unmatching = false }) >= 1)
	end)

Like you I tested this with java and even when this option is set to false I dont get the desired behavior. I tested this then again with a different programming language (golang) and it works flawlessly there. Hence, I suspect this is some kind of oddity related to java/jdtls (or a subset of language servers). I think I will try to gather some more insights about this and file a bug report afterwards.

[asmodeus812]

Doubt it is the language server, the coc-java extension does not have/does anything special with the completion items. The implementation of nvim-cmp is pretty basic compared to vscode's lsp client.

[jaynis]

After further investigations I am completely puzzled now. Even with java/jdtls the matching of arbitrary parts sometimes works and sometimes (most of the times) it simply doesnt. It even happened that I have a java object where some methods are matched and on the same object others are not with no clear to me pattern why.

[Shougo]

It may be nvim-cmp performance problem.

[yioneko]

I've investigated this and I know the reason. It is because jdtls does not support fuzzy match and defaults the max completion items to 50, so the cmp's fuzzy matching is applied after server's prefixed matching. For example, if you type Collections., jdtls sends completion response truncated to 50 items, and when you type m further, cmp knows the completion list is truncated and retriggers the completion request to jdtls for more candidates. But jdtls only does prefix matching for input m so this time cmp only receives items prefixed with m .

To resovle the problem, just remove the default truncation limit of completion item for jdtls:

require("lspconfig").jdtls.setup({
  settings = {
     java = { completion = { maxResults = 0 }}
  }
})

coc-java removes the limit by default so you do not have this problem in coc-java or vscode.

[asmodeus812]

@yioneko i had some time to test this, had all disallow_ set to false, set the maxResults to 0, still the same issue.

[yioneko]

You can provide the minimal reproduction steps for your problem. I could not look into this unless the issue can be reproduced on my side with maxResults set to 0...