Fix `lsp.buf_request_all` about null-ls.nvim HOT 9 CLOSED

OK, thanks!

No, I think it's fine for now. Thanks for your work on this plugin 👍

from null-ls.nvim.

$ sw_vers

ProductName:	macOS
ProductVersion:	11.4
BuildVersion:	20F71

$ brew info neovim

neovim: stable 0.5.0 (bottled), HEAD
Ambitious Vim-fork focused on extensibility and agility
https://neovim.io/
/usr/local/Cellar/neovim/HEAD-a8c3d50 (1,542 files, 21.2MB) *
  Built from source on 2021-07-23 at 07:34:09
/usr/local/Cellar/neovim/0.5.0 (1,543 files, 21.2MB)
  Poured from bottle on 2021-07-03 at 06:37:06
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/neovim.rb
License: Apache-2.0
==> Dependencies
Build: cmake, luarocks, pkg-config
Required: gettext, libtermkey, libuv, libvterm, luajit-openresty, luv, msgpack, tree-sitter, unibilium
==> Options
--HEAD
    Install HEAD version
==> Analytics
install: 37,677 (30 days), 80,698 (90 days), 276,835 (365 days)
install-on-request: 37,558 (30 days), 80,505 (90 days), 276,080 (365 days)
build-error: 0 (30 days)

:LspInfo

Configured servers: tsserver, rust_analyzer, clangd, jsonls, cssls, sumneko_lua
Neovim logs at: /Users/niko.steinhoff/.cache/nvim/lsp.log

1 client(s) attached to this buffer: null-ls

  Client: null-ls (id 1)
  	root:      /Users/niko.steinhoff/dev/s2/mofa
  	filetypes: 
  	cmd:       nvim --headless -u NONE -c set rtp+=/Users/niko.steinhoff/dev/dotfiles/3rd/pack/external/opt/null-ls.nvim -c lua require'null-ls'.start_server()

:lua vim.lsp.buf.code_action()

E5108: Error executing lua ...r/neovim/HEAD-a8c3d50/share/nvim/runtime/lua/vim/lsp.lua:1321: bad argument #1 to 'pairs' (table expected, got nil)

null-ls config (@ commit 56d4b76):

local config = {
    sources = {
        null_ls.builtins.formatting.prettier,
    },
}

null_ls.setup(config)

following the instructions from CONFIG.md and BUILTINS.md

CONFIG.md

Once installed, the minimal config required to enable null-ls is as follows:

require("null-ls").setup {}

BUILTINS.md

You can then register sources by passing a sources list into your setup
function:

local null_ls = require("null-ls")

-- register any number of sources simultaneously
local sources = {
    null_ls.builtins.formatting.prettier,
    null_ls.builtins.diagnostics.write_good,
    null_ls.builtins.code_actions.gitsigns,
}

null_ls.setup {sources = sources}

from null-ls.nvim.

I'll try updating to the latest version of null-ls after work to see if the error persists and possibly push a fix. No rush!

from null-ls.nvim.

Thank you for the detail! I believe that the specific error you are seeing is fixed on the latest version of null-ls. However, following the same steps on the latest commit triggers another, semi-related error which (if I'm correct) may be on Neovim's side:

E5108: Error executing lua /usr/local/share/nvim/runtime/lua/vim/lsp.lua:1318: table index is nil

I think this is caused by the fact that if no clients can handle a given request, buf_request calls the callback without a client ID, which throws an error when _sync_handler tries to use nil as an index.

I was able to replicate this with both tsserver and lua-language-server (without null-ls enabled) by setting client.resolved_capabilities.code_action = false in on_attach, so unless I'm way off track, we're running into a separate issue inside the same function, which is a real coincidence. I'll look into this a bit more and try to verify that I'm not wrong before opening a Neovim issue.

from null-ls.nvim.

With the latest version of null-ls I get:

E5108: Error executing lua ...r/neovim/HEAD-a8c3d50/share/nvim/runtime/lua/vim/lsp.lua:1327: table index is nil

New config:

null_ls.config({
    sources = {
        null_ls.builtins.formatting.prettier,
    },
})

lspconfig["null-ls"].setup({
    on_attach = on_attach
})

from null-ls.nvim.

Right. I think this issue will whenever buf_request_all is called in a buffer that's attached to an LSP server that can't handle code actions. I'm going to verify that efm and diagnostic-ls have the same problem, then open up a Neovim issue.

For now, is this behavior specifically causing you problems? From what I can tell the issue doesn't happen if at least one LSP server actually can handle code actions.

from null-ls.nvim.

Good to know! I opened up a Neovim issue, so I'll plan on closing this once we've gotten it fixed.

from null-ls.nvim.

We're still working on the Neovim issue, but since isn't a null-ls issue (and doesn't break anything, strictly speaking) I'm going to close this.

from null-ls.nvim.

Can you all test this? neovim/neovim#15926

Having trouble reproducing your original issue

from null-ls.nvim.