williamboman/nvim-lsp-installer

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

  1. update nvim-lsp-installer to newest version.
  2. 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).