error while require 'nvim-lsp-installer'
Acceyuriko opened this issue · 2 comments
Problem description
E5113: Error while calling lua chunk: Vim:E6100: "state" is not a valid stdpath
stack traceback:
[C]: in function 'stdpath'
.../start/nvim-lsp-installer/lua/nvim-lsp-installer/log.lua:35: in main chunk
[C]: in function 'require'
...rt/nvim-lsp-installer/lua/nvim-lsp-installer/core/fs.lua:1: in main chunk
[C]: in function 'require'
...cker/start/nvim-lsp-installer/lua/nvim-lsp-installer.lua:1: in main chunk
[C]: in function 'require'
/home/yuriko/.config/nvim/lua/yuriko/cmp.lua:8: in function 'setup'
/home/yuriko/.config/nvim/init.lua:98: in main chunk
Why do you think this is an issue with nvim-lsp-installer?
I guess the commit 2631265173cd2c9b3ffa9057b6125477b077abf8 caused this problem.
If I download installer of version 3c21304, the problem disappeared.
Neovim version (>= 0.7)
NVIM v0.8.0-dev+124-g815b65d77
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Operating system/version
Linux Acceyuriko 5.10.102.1-microsoft-standard-WSL2 #1 SMP Wed Mar 2 00:30:59 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
I've manually reviewed the Nvim LPS client log (:LspLog
) to find potential errors
- Yes
I've recently downloaded the latest plugin version of both nvim-lsp-installer and nvim-lspconfig
- Yes
Affected language servers
all
Steps to reproduce
- update nvim-lsp-installer to newest version.
- restart neovim.
Actual behavior
errors occured.
Expected behavior
require('nvim-lsp-installer') normally
LspInfo
crashed, so there is nothing
LspLog
No response
Healthcheck
crashed, so there is nothing
Screenshots or recordings
No response
Updating to latest neovim-nightly fixes this issue.
Seems like stdpath("state")
is not available in early nightlies that report version as 0.8.0.
Hello! stdpath("state")
(which I now realize really should be stdpath("log")
) was added ~18 days ago in neovim HEAD. I figured that'd be enough time for people running nightly/HEAD to have updated by (am I the only one who compiles HEAD daily 😅?). If you use latest stable 0.7.0 it won't try to use any new stdpath
!
Seeing as this is for such a minor thing (the location of a log file) I'll revert the original change, although I do really recommend following HEAD/nightly once you're on it (or simply just use latest stable).