kickstart.nvim
kickstart.nvim copied to clipboard
handle lua language server when saving init.lua
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?
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
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?
The change proposed by @cquick01 in https://github.com/nvim-lua/kickstart.nvim/issues/15#issuecomment-1281353797 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/
@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
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.