[mini.completion] Weird interaction with empty complete opt

[badosu]

Contributing guidelines

• I have read CODE_OF_CONDUCT.md

Module(s)

mini.completion

Question

If I set complete empty, I have a weird interaction where in insert mode lots of literal ^Ns are inserted (equivalent to <C-v><C-n>).

Has anybody observed this? Here's my mini.completion config.

[starkmarkus]

Looking at the linked config, I think the important part is this commented section:

-- Trigger LSP completion directly to prevent buffer text fallback
-- vim.api.nvim_create_autocmd("LspAttach", {
--   callback = function(args)
--     vim.bo[args.buf].complete = "" -- disable words completion
--   end,
-- })

So the goal is not just “empty complete for no reason”, but to prevent Neovim from falling back to buffer/keyword completion and use LSP completion only.

That goal makes sense, but I suspect complete = "" is too strong. mini.completion still uses Neovim’s built-in insert-completion mechanism, with omnifunc set to v:lua.MiniCompletion.completefunc_lsp in your config. If complete is empty, / can end up in an unusual state where completion is triggered but there are no normal completion sources configured. That may explain why literal ^N characters appear.

Instead of clearing complete, I would try keeping only omni completion as the source:

vim.api.nvim_create_autocmd("LspAttach", {
  callback = function(args)
    vim.bo[args.buf].complete = "o"
  end,
})

or test it manually:

:setlocal complete=o
:verbose setlocal complete?
:verbose setlocal omnifunc?

This should keep completion routed through omnifunc / MiniCompletion.completefunc_lsp, while avoiding the buffer-word fallback sources.

So my current guess is:

• complete="" disables too much and causes the weird literal ^N behavior.
• complete=o is probably closer to what you want: LSP/omnifunc completion only.
• The follow-up check would be whether complete=o removes buffer text fallback without producing literal control characters.

If complete=o still falls back to buffer words, then the next thing to inspect would be the exact mappings / completeopt state, but I would try that before treating this as a mini.completion bug.

[badosu]

I see, so complete= would be expected to insert ^N with mini.completion.

I used o via the test suggested and it still provides buffer completion.

completeopt is menuone,noselect,fuzzy,nosort and I didn't find any insert mode mapping that could have interfered.

FWIW setting to a smaller source like k still shows ^N sometimes.

[starkmarkus]

Good point, then my previous guess was incomplete.

If complete=o still gives what looks like buffer completion, I think the more relevant part is probably mini.completion’s fallback behavior, not only the value of complete.

mini.completion is a two-stage completion system:

1. try LSP completion
2. if there are no LSP candidates, run fallback_action

and the default fallback action is:

fallback_action = ''

So even if your LSP setup is correct, when LSP returns no candidates, mini.completion can still fall back to Neovim’s built-in completion. That would explain why you still see buffer-like completion with complete=o, and also why unusual complete values like complete="" or complete=k can produce weird literal ^N behavior: the fallback is still trying to execute .

If your goal is strict LSP-only completion, I would test disabling the fallback instead of trying to control it only through complete.

Something like this is worth trying:

require('mini.completion').setup({
  lsp_completion = {
    source_func = 'omnifunc',
    auto_setup = false,
  },
  -- Disable built-in <C-n> fallback.
  fallback_action = function() end,
})

and keep the LSP attach part:

vim.api.nvim_create_autocmd('LspAttach', {
  callback = function(args)
    vim.bo[args.buf].omnifunc = 'v:lua.MiniCompletion.completefunc_lsp'
  end,
})

Then I would test with a normal-ish complete value first, not an empty one:

:setlocal complete=.,w,b,u
or even:

:setlocal complete=o
The key test is whether the issue disappears when fallback_action is disabled.

So my updated guess is:

complete="" is not the root feature you want.
The default fallback_action='' is probably what you want to avoid.
For strict LSP-only behavior, disable or replace fallback_action.

If disabling fallback_action removes both the buffer fallback and the literal ^N, then this is likely expected behavior from the current two-stage design rather than an insert-mode mapping conflict.

[badosu]

Setting fallback_action to empty func or empty string definitely fixes it and achieves my desired behavior. Thank you!

[echasnovski]

Indeed, this is working as expected because 'mini.completion' here tries two things in succession: ask LSP server(s) about completion data, perform fallback action if there is none. The default fallback action is emulating <C-n> press, which shows completion based on sources in 'complete' option. And if 'complete' is empty, pressing <C-n> indeed inserts ^N character (i.e. \14). This is the behavior without 'mini.completion'.

To disable fallback completion locally to buffer, set vim.b.minicompletion_config = { fallback_action = '' }.