docs(lua_ls) Fix broken example setup when workspace_folders are not used

[mikehaertl]

Without this fix I get errors on startup and the config is not applied properly.

LSP[lua_ls]: Error ON_INIT_CALLBACK_ERROR: "[string ":lua"]:79: attempt to index field 'workspace_folders' (a nil value)"

[mikehaertl]

@glepnir Actually I wonder if the current example configuration makes much sense anymore. From https://luals.github.io/wiki/configuration/:

The language server loads its settings from one of the following sources, in order of priority:

• The file specified by --config-path.
• A .luarc.json file in the workspace.
• The configuration file sent from the LSP client (like settings.json from VS Code).

So the if at the beginning should not be required at all anymore.

And even on_init is probably not necessary: The whole config can just be passed in settings as shown here: https://luals.github.io/wiki/configuration/#neovim

What do you think?

[lewis6991]

Here's what I'm using: https://github.com/lewis6991/dotfiles/blob/main/config%2Fnvim%2Flua%2Flewis6991%2Flsp.lua#L137-L146

Basically if there's no .luarc.json which configures the - workspace then apply some default settings which include $VIMRUNTIME. You shouldn't include this unconditionally.

[mikehaertl]

You shouldn't include this unconditionally.

But according to the lua_ls documentation that shouldn't be the case: If the server finds a .luarc.json it will not use the config sent from the LSP client (neovim).

[lewis6991]

Can you confirm that?

[mikehaertl]

I'm unsure how to test it as I don't do much lua development and thus don't know what you would set in a .luarc.json. But why not trust the documentation of the LSP server in that regard?

In any case the fix as it is should already be fine as @telemachus pointed out. So if in doubt we could at least merge this change already.

[telemachus]

I just did the following (minimal) test, and it seems to confirm what @mikehaertl got from the docs.

1. Create a scratch directory with the following .luarc.json:

{
  "$schema": "https://raw.githubusercontent.com/sumneko/vscode-lua/master/setting/schema.json",
  "runtime.version": "Lua 5.4",
}

2. Put the following in my init.lua file:

lspconfig.lua_ls.setup({
    settings = {
        Lua = {
            runtime = {
                version = "LuaJIT",
            },
            workspace = {
                library = { vim.env.VIMRUNTIME },
            },
        },
    },
})

3. Edit a file in the scratch directory with the .luarc.json from 1. If I enter foo, bar = unpack({1, 2, }), I get a diagnostic for the use of unpack instead of table.unpack because the language server has read the .luarc.json file and thinks I am using Lua 5.4. If I edit the same content in a directory without the .luarc.json file, I get no warning since the server knows I'm using LuaJIT (i.e., Lua 5.1).
4. If I enter local getcwd = vim.fn.cwd into a Lua file in a directory without any .luarc.json file, I get no warning because the server loads vim.env.VIMRUNTIME. But if I enter that same line in the scratch directory with the .luarc.json file, I get a warning for Undefined global 'vim' because the server isn't aware of vim.env.VIMRUNTIME (from my LSP settings).

This isn't ironclad confirmation, but it definitely suggests that Mike is right. If there is a .luarc.json file, the server ignores settings from the LSP client. The LSP client itself doesn't seem to need to check for the .luarc.json file again.

In case this matters, I'm using lua-language-server 3.7.4 on macOS, installed via MacPorts.

[telemachus]

I was just about to submit a PR with the same fix for the same reason. (Namely, I get the following error with the current suggested configuration if I open a Lua file in a scratch directory.)

LSP[lua_ls]: Error ON_INIT_CALLBACK_ERROR: "...machus/Documents/git-repos/dotfiles/config/nvim/init.lua:311: attempt to index field 'workspace_folders' (a nil value)"

I'm not sure that I follow the discussion in the comments, but I agree that the docs should suggest a less brittle default configuration. What is the next step here?