Justin M. Keyes
Justin M. Keyes
@Lyude Test the latest master. You mentioned bisecting, so I assume you can build latest HEAD. But your report mentions Nvim v0.10.2 ?
> otherwise is how I can recreate a situation with minimal nvim config where we can get neovim to pop up very large completion lists Use the `vim.lsp.server` impl from...
Oh I just realized that probably won't work because it avoids the use of msgpack-RPC. `vim.lsp.server` is a in-process Lua module.
This issue is also breaking vscode-neovim: https://github.com/vscode-neovim/vscode-neovim/issues/2407#issuecomment-2713001740
Similar report at: - https://github.com/neovim/nvim-lspconfig/issues/3853 Maybe the positionEncoding isn't getting sent somehow when `vim.lsp.config` is used? both the old and new configs specify the same `offsetEncoding`: - https://github.com/neovim/nvim-lspconfig/blob/d45702594afc661a9dfa95e96acf18c56006d4d9/lsp/clangd.lua#L78 - https://github.com/neovim/nvim-lspconfig/blob/d45702594afc661a9dfa95e96acf18c56006d4d9/lua/lspconfig/configs/clangd.lua#L71
meaning what? do we need to remove the `offsetEncoding` from the config? or something else.
so send a patch to https://github.com/neovim/nvim-lspconfig/ ?
> It can be fixed by removing the `_fast` argument. That arg only exists for loader :-} https://github.com/neovim/neovim/commit/dcdefd042840c7a6db5dce2963ac23c45a5287da however `path_resolve_dot` was the main cost, so we could try just removing...
:( we really need this. > it may start failing randomly again in the future "Randomly" because of a future mistake in the tests? What if we disabled this for...
> Since instances are created before the tests that use them, we can't use `_G._nvim_test_id` from #8519 in e.g. `test/functional/core/log_spec.lua`, since we can't know which test will use which instance....