Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expected table, got string error when calling vim.lsp.buf.definition() #23

Closed
max-amsterdam opened this issue Sep 15, 2021 · 1 comment

Comments

@max-amsterdam
Copy link

Hi,

I'm running neovim NVIM v0.6.0-dev+1551-g0e22a40b6, and just updated a all of my plugins with Packer.

I am also using gopls, built-in LSP, and nvim-lspfuzzy. Previously, I would call vim.lsp.buf.definition() via a keybinding when hovering over a keyword in go. Often, there is only a single definition location, so my buffer would be moved automatically to that location. Further, if there were multiple definitions, I would get the fuzzy complete pop-up and could choose my definition.

For some reason, after upgrading, when I make a vim.lsp.buf.definition() call, I am getting the following error:

Error executing vim.schedule lua callback: vim/shared.lua:199: Expected table, got string

I also get this same error when calling vim.lsp.buf.implementation() and vim.lsp.buf.references().

I know that this is a nvim-lspfuzzy related issue, since when I disable nvim-lspfuzzy, these same function calls work as expected (except I don't get the pretty fuzzy pop-up!)

I am wondering if I am missing some configuration item here, or if this is an actual bug.

Please let me know if you would like additional information for re-producability.

@ojroques
Copy link
Owner

ojroques commented Sep 15, 2021

Hello!

See this issue: #20

Basically you're in a detached commit between 0.5 and the commit 23fe6dba1 from Neovim which has introduced breaking change to the LSP handlers.

The plugin works for Neovim 0.5 and nightly/master (and additionally for all commits after 23fe6dba1) so I suggest you update Neovim. If you can't, you should checkout the old-handlers tag. Tell me if one of these solutions works for you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants