Setting up completion + snippets fails

[gbishop]

Contributing guidelines

• I have read CODE_OF_CONDUCT.md

Module(s)

mini.completion, mini.snippets

Question

I'm trying to get snippets from LSP servers to work. I've got mini.snippets and mini.completion installed and setup. Keyword, Function, and Variable completions work but Snippet completions fail with this message:

Error detected while processing CompleteDonePre Autocommands for "*":
Error executing lua callback: ....local/share/nvim/lazy/mini.nvim/lua/mini/completion.lua:1125: at
tempt to index local 'item' (a nil value)
stack traceback:
        ....local/share/nvim/lazy/mini.nvim/lua/mini/completion.lua:1125: in function 'make_lsp_ex
tra_actions'
        ....local/share/nvim/lazy/mini.nvim/lua/mini/completion.lua:805: in function <....local/sh
are/nvim/lazy/mini.nvim/lua/mini/completion.lua:797>

I'm experimenting with completions from emmet-ls.

I'm using nvim 10.4.

Any help will be appreciated.

[echasnovski]

After looking at code, I couldn't find an obvious reason why this could happen.

Could you please post the following information:

• All relevant parts of 'mini.completion' and 'mini.snippets' setups. Like how exactly require('mini.xxx').setup() calls look.
• A setup you use to enable emmet-ls. Like a relevant require('lspconfig') call or similar.
• An example of a file and key presses that you can (reliably) reproduce the issue with emmet-ls. Like "Here is a content of a file (I presume, html), place cursor here, start insert mode, type these keys, accept this completion item".

[gbishop]

Thanks for the quick reply. I will create a minimal example.

…

On Sat, Mar 15, 2025, 16:25 Evgeni Chasnovski ***@***.***> wrote: After looking at code, I couldn't find an obvious reason why this could happen. Could you please post the following information: - All relevant parts of 'mini.completion' and 'mini.snippets' setups. Like how exactly require('mini.xxx').setup() calls look. - A setup you use to enable emmet-ls. Like a relevant require('lspconfig') call or similar. - An example of a file and key presses that you can (reliably) reproduce the issue with emmet-ls. Like "Here is a content of a file (I presume, html), place cursor here, start insert mode, type these keys, accept this completion item". — Reply to this email directly, view it on GitHub <#1681 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABQK7FMKSJMWFFY3I5ZM532USEDFAVCNFSM6AAAAABZCZY5C6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENJRGIYDCOI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[gbishop]

minitest.zip

I have attached the minimal configuration. Open a new file say "foo.html" and input mode type
ul#nav

Activate the Snippet that pops up. That gives me the error.

[abeldekat]

I can reproduce with v0.10.4. On nightly, the snippet works fine.

I don't have emmet_ls installed. So I copied the relevant code in your minitest.zip to an init.lua I used earlier:

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')
    local clone_cmd = { "git", "clone", "--filter=blob:none", "https://github.com/echasnovski/mini.nvim", mini_path }
    vim.fn.system(clone_cmd)
    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/")

vim.g.mapleader = " "
MiniDeps.now(function()
  require("mini.icons").setup()
  require("mini.snippets").setup() -- only using lsp snippets
  require("mini.completion").setup()

  MiniDeps.add("williamboman/mason.nvim")
  MiniDeps.add("williamboman/mason-lspconfig.nvim")
  MiniDeps.add("neovim/nvim-lspconfig")
  require("mason").setup()
  require("mason-lspconfig").setup({ ensure_installed = { "emmet_ls" } })

  local capabilities = vim.lsp.protocol.make_client_capabilities()
  capabilities.textDocument.completion.completionItem.snippetSupport = true
  require("lspconfig").emmet_ls.setup({
    -- on_attach = function(_, buf_id) vim.bo[buf_id].omnifunc = "v:lua.MiniCompletion.completefunc_lsp" end,
    capabilities = capabilities,
    filetypes = { "css", "html", "javascript" },
  })
end)

emmet_ls version: 0.4.2

[abeldekat]

On v0.10.4, the resolved on line 1122 is:

{
  error = {
    code = -32601,
    message = "Unhandled method completionItem/resolve",
    <metatable> = {
      __tostring = <function 1>
    }
  }
}

On nightly, that same resolved is:

{
  err = <1>{
    code = -32601,
    message = "Unhandled method completionItem/resolve",
    <metatable> = {
      __tostring = <function 1>
    }
  },
  error = <table 1>
}

As there is no err key on v0.10.4, on line 1123 the value becomes resolved.result, which is nil.

@echasnovski, shall I write a PR?

EDIT:

See lsp.lua in Neovim from this commit on 20241024:

-- The error key is deprecated and will be removed in 0.13
results[ctx.client_id] = { err = err, error = err, result = result }

[echasnovski]

EDIT:

See lsp in Neovim, from commit 1471dfc85964a9d95c216619d715bfe449d97c19 on 20241024:

-- The error key is deprecated and will be removed in 0.13
results[ctx.client_id] = { err = err, error = err, result = result }

Yeah, that seems to be the case and is documented as deprecated. One extra thing I was curious about is why 'mini.completion' uses err in the first place for similar contexts. It indeed seems to be my mistake as as far as I can see (all the way to the Neovim 0.5.1) the shape of result in buf_request_all is indeed a table from client id to { error = error, result = result }. Probably used err because it was named that way as an argument in :h lsh-handler.

@echasnovski, shall I write a PR?

Sure, if you'd like to. Please, use something like x.err or x.error in all places that it is used (there are several).

---

There is also another issue here as 'mini.completion' does attempt to see if the server supports resolving completion item. Maybe it also does that not correctly. Nope, everything is correct on 'mini.completion' part. It is just that emmet_ls has server_capabilities.completionProvider.resolveProvider = true while throwing this kind of "Unhandled method completionItem/resolve" error 🤦

---

(Also, @abeldekat, a small question: is there a reason all your commits don't link to the GitHub account? Like here, for example. This prevents you from being listed as a contributor in 'mini.nvim' repo.)

[abeldekat]

Thanks! I will submit a PR, hopefully today.

... all your commits don't link ...

I noticed that as well...)
In order to hide my email address, also from appearing in source code, I added a fake one to my ~/.gitconfig:

[user]
	name = abeldekat
	email = [email protected]

Maybe that is the problem? That said, my contributions to LazyVim are visible. I am number 18....)

EDIT:
Also, on my github homepage, there is a line "contributed to mini.nvim".

[gbishop]

This is great! Thank you both. I'm also learning about minimal configuration and using mini.deps from @abeldekat.

[echasnovski]

I noticed that as well...)
In order to hide my email address, also from appearing in source code, I added a fake one to my ~/.gitconfig:

I think adding this fake email to your GitHub profile settings (like this) will make GitHub recognize commits with that email as belonging to your account. It's just a bit confusing to see different committer and have to verify it manually.

[echasnovski]

@gbishop, this should now be resolved on latest main thanks to @abeldekat.

[gbishop]

It is working now for me. Thanks for the quick update. Inspired by your example I have upgraded to mini.deps and cleaned up my configuration.

[abeldekat]

That's great!