Repository navigation
[mini.completion] respect vim.o.complete for nvim-0.12+ ? #2224
Description
Contributing guidelines
- I have read CONTRIBUTING.md
- I have read CODE_OF_CONDUCT.md
Module(s)
mini.completion
Description
Previously the default vim.o.complete of '.,w,b,u,t' would cause slowdowns in mini-completion, even if the user didn't use ctags.
A workaround was added to remove t unless user explicitly sets it via eb4d6bd
The source of the problem was the vim.lsp.tagfunc erroneously sending synchronous LSP requests during the insert completion, it has been fixed here: neovim/neovim#37260
Maybe the workaround could be guarded with a nvim-0.12 check? It is strange to have to set the already-default options for tag completion to work as a fallback.
Activity
echasnovski commentedon Jan 15, 2026
Thanks for the suggestion!
I am not if this specifically was the root cause, so will have to verify that Nightly doesn't have the performance issues. But even then, I think it might be reasonable to keep the behavior:
textDocument/definitionrequest, then it means there is LSP attached. This also usually means that there is a regular LSP step withtextDocument/completionrequests from 'mini.completion'. I don't think it is common to havetextDocument/completionrequest fail andtextDocument/definitionsucceed (i.e. to actually get to the fallback step).vim.o.complete = vim.o.completebeforerequire('mini.completion').setup(). This technically qualifies as "set beforesetup()" and the option value shouldn't be changed.rmuir commentedon Jan 15, 2026
FWIW, I think the case triggered fairly easily when using mini-snippets LSP for an oddball filetype (markdown file in large java repo). For my setup completion "fails" if no snippet matches for such filetypes. Then i saw a strange error about "no servers supporting textDocument/definition" and knew my answer as to why it was slow.