vim-lsp-settings icon indicating copy to clipboard operation
vim-lsp-settings copied to clipboard

lua-language-server does not work with local install

Open xlucn opened this issue 2 years ago • 3 comments

The settings in this repo seems to require a sumneko-lua-language-server that's created by the installation script also in this repo. But normally local install of lua-language-server only provide an executable lua-language-server. For example, in Arch Linux's official repo, the package installs lua-language-server to /usr/bin, which is a shell script calling the actual executable lua-language-server somewhere else. The case is similar for other platforms. As a result, the language server is not automatically started because the executable can not be found.

Maybe the executable required should be lua-language-server to work better with local installs?

xlucn avatar Dec 08 '21 13:12 xlucn

Simple workaround:

	"sumneko-lua-language-server": {
		"cmd": ["lua-language-server"]
	},

But is it better to just work out of the box with local package installs?

xlucn avatar Dec 13 '21 09:12 xlucn

But is it better to just work out of the box with local package installs?

I think the answer would be no? If a system has an ancient luals install, vim-lsp-settings installs a new version, then regardless of your PATH it should use the vim-lsp-settings version. But the config you posted would be a good way to use a local install. It's also pretty intuitive to setup "run from PATH" whereas the opposite is not.

idbrii avatar Aug 10 '23 20:08 idbrii

@idbrii That doesn't seem to be what I am concerned:

I would like the local installed lsp to work OOTB, if I haven't installed one with vim-lsp-settings. The issue is the executable name that gets searched for is not the common lua-language-server, but with a sumneko- prefix. So by default, probably no executable will be found.

Your concern may be addressed by prioritizing the vim-lsp-settings-installed one, so that it is always used no matter whether I have installed locally with a Linux's package manager. Maybe this is the current behavior already?

xlucn avatar Aug 14 '23 02:08 xlucn