[mini.completion] respect vim.o.complete for nvim-0.12+ ?

[rmuir]

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.

[echasnovski]

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

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:

• If the slowness is due to textDocument/definition request, then it means there is LSP attached. This also usually means that there is a regular LSP step with textDocument/completion requests from 'mini.completion'. I don't think it is common to have textDocument/completion request fail and textDocument/definition succeed (i.e. to actually get to the fallback step).
• It doesn't have to be "... have to set the already-default options for tag completion to work as a fallback.". It can be a vim.o.complete = vim.o.complete before require('mini.completion').setup(). This technically qualifies as "set before setup()" and the option value shouldn't be changed.

[rmuir]

• If the slowness is due to textDocument/definition request, then it means there is LSP attached. This also usually means that there is a regular LSP step with textDocument/completion requests from 'mini.completion'. I don't think it is common to have textDocument/completion request fail and textDocument/definition succeed (i.e. to actually get to the fallback step).

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.