handle lua language server when saving init.lua

[FelipeLema]

saving init.lua will source the file to update config current neovim process. It will also trigger a re-spawn of lua language server (unless it wasn't configured/setup for editing init.lua, which is unlikely).

Eventually, after saving a few times, users will run out of memory.

I haven't tested with other language servers being opened, but I don't see why they wouldn't share this problem. Maybe print a warning that LSP will be re-spawned? Maybe a guard variable to do lspconfig[server].setup() once in current session + print warning?

[cquick01]

This seems to work for me

  local function init_lua_servers()
    for _, lsp in ipairs(servers) do
      require('lspconfig')[lsp].setup {
        on_attach = on_attach,
        capabilities = capabilities,
      }
    end
    -- Example custom configuration for lua
    --
    -- Make runtime files discoverable to the server
    local runtime_path = vim.split(package.path, ';')
    table.insert(runtime_path, 'lua/?.lua')
    table.insert(runtime_path, 'lua/?/init.lua')

    require('lspconfig').sumneko_lua.setup {
      on_attach = on_attach,
      capabilities = capabilities,
      settings = {
        Lua = {
          runtime = {
            -- Tell the language server which version of Lua you're using (most likely LuaJIT)
            version = 'LuaJIT',
            -- Setup your lua path
            path = runtime_path,
          },
          diagnostics = {
            globals = { 'vim' },
          },
          workspace = { library = vim.api.nvim_get_runtime_file('', true) },
          -- Do not send telemetry data containing a randomized but unique identifier
          telemetry = { enable = false },
        },
      },
    }
    return {}
  end

  if not _G.INIT_LUA_LOADED then
    _G.INIT_LUA_LOADED = init_lua_servers()
  end

[FelipeLema]

yup, I did the same using vim.g._some_really_long_name_for_a_guard, which does the same thing

My concern is that new users may (and this is open for discussion) run into trouble without lots of technical knowledge: should the init.lua file show how to guard the lsp_server.setup() calls or would that be too complex / techincal to include?

[jbranchaud]

The change proposed by @cquick01 in #15 (comment) seems to have resolved the Undefined global vim warning that was showing up for me all over init.lua.

I was having trouble with the lua LSP configuration specifically regarding it recognizing the vim global as a valid global. Even with the { diagnostics = { globals = { 'vim' } } } setting, I was still seeing those language server warning comes through (see screenshot).

Wrapping the lua LSP setup in a function and conditionally calling that function only once seems to have fixed this. Not sure if this is related to the original issue. I wanted to share this though because I've seen a lot of mixed results and fixes that didn't work for me on reddit:

• https://www.reddit.com/r/neovim/comments/khk335/lua_configuration_global_vim_is_undefined/
• https://www.reddit.com/r/neovim/comments/p0p0kr/solved_undefined_global_vim_error/

[FelipeLema]

@jbranchaud you may want to look at https://github.com/folke/neodev.nvim for that kind of problem

so, I'm trying to frame this issue into a simple choice of what is to be done and possible outcomes:

• do nothing: new users will run into this issue over and over and may become a common barrier ("how to quit vim"-ish). maybe it won't and people will just restart nvim after editing init.lua
• include a guard variable to load once: new users may scratch their heads more than they should about this "hack". maybe they won't even notice ("ah, so just load this function once")
• wrap lspconfig's setup() function around a guard, maybe add a notification that says "you'll need to quit nvim for xxx.setup() changes to take effect")

to me, third choice sounds hack-ish, but I know lots of people who like an editor that'll Just Work

[tjdevries]

I will hopefully have a chance to take a look at the lua dev stuff for this sometime in the next few weeks. Sorry for the delay.

[tjdevries]

No longer required after #178 , we don't do this same strategy anymore