What values for `Lua.runtime.path` and `Lua.workspace.library`?

[HiPhish]

Hello, Neovim user here.

I want to set the Lua language server up for various types of projects with different settings. My problem right now is that I don't know what values to set for Lua.runtime.path and for Lua.workspace.library.

Let's say I want to write a Lua package, and I want to use dependencies from Luarocks. I somehow need to tell the server where to find my installed rocks. Here is what I have (the configuration is in Lua as well):

Lua = {
	runtime = {
		version = 'Lua 5.3',
		path = {"?.lua", "?/init.lua", "?/?.lua"}
	},
	workspace = {
		library = {
			["/home/hiphish/.luarocks/share/lua/5.3/"] = true,
			["/usr/share/lua/5.3/"] = true,
		}
	},
}

To my understanding this should be right, but I am not getting any completion suggestions for require're (from the lpeg rock). Similarly, if I have local re = require're', I don't get completion suggestions for re.. Do I need to adjust the Lua.runtime.path?

Background: I want to get hard-coded settings right first. The next step would be to programmatically generate these settings. Neovim can be configured in Lua, and the built-in LSP client is essentially a Lua library. I can probe the current directory for specific files (like *.rockspec or init.vim) and generate the appropriate settings on the fly. But to this end I must understand the server settings first.

I hope this explanation makes sense and you can help me understand the settings.

PS: The server cannot load definitions from C modules like lpeg, right?

[sumneko]

As far as I know, the confiiguration feature is broken in latest Neovim client.
You can see many related issues here: https://github.com/neovim/nvim-lspconfig/issues

You could find the description of settings in wiki: https://github.com/sumneko/lua-language-server/wiki/Setting-without-VSCode

Currently, it is not supported to analyze the interface directly from C module

[HiPhish]

As far as I know, the confiiguration feature is broken in latest Neovim client.

Where are you getting that idea? Also, the repo is not the client, it's just the default configurations for various servers.

Anyway, I have a different set of settings for configuring Neovim, and I do get completion suggestions with those settings, albeit wrong ones. I wanted to figure it out first for a simple use-case (Luarocks packages), then try something more complex (Neovim configuration).

You could find the description of settings in wiki

Thank you, but I already know about that page and the schema. I still don't understand what those two settings do, and why we need two of them in the first place.

For example, for Lua.runtime.path the description only says "package.path". If I want to use a Luarocks package on the shell I first enter eval $(luarocks path) to set the environment variables, then in Lua the value of packag.path contains the extra paths. Do I put that value in the Lua.runtime.path field? Do I first have to split it along the ;?

Here are my second attempt at settings, as evaluated by the client and sent to the server:

Lua = {
	completion = {
		callSnippet = "Both",
	},
	runtime = {
		path = {
			"?.lua",
			"?/init.lua",
			"?/?.lua",
			"/home/hiphish/.luarocks/share/lua/5.3/?.lua",
			"/home/hiphish/.luarocks/share/lua/5.3/?/init.lua",
			"/usr/share/5.3/?.lua",
			"/usr/share/lua/5.3/?/init.lua"
		},
		version = "Lua 5.3",
	},
	workspace = {
		library = {
			["/home/hiphish/.luarocks/share/lua/5.3"] = true,
			["/usr/share/lua/5.3"] = true,
		},
		maxPreload = 1000,
		preloadFileSize = 1000,
	},
}

Anything missing?

[sumneko]

workspace.library determines which directories go back to collect extra Lua files, which are used to intelligently sense and share global variables.
runtime.path is only used for require. For the moment, I allow extra directories in front of path, that means xxx.lua can be both linked to script/xxx.lua in your workspace and linked to /usr/share/5.3/xxx.lua in your library.

[HiPhish]

workspace.library determines which directories go back to collect extra Lua files, which are used to intelligently sense and share global variables.

OK, now I understand it.

runtime.path is only used for require. For the moment, I allow extra directories in front of path, that means xxx.lua can be both linked to script/xxx.lua in your workspace and linked to /usr/share/5.3/xxx.lua in your library.

Then it appears the feature is not working properly. I have the following file:

-- saved as ~/.luarocks/share/lua/5.3/hello.lua
local M = {}

--- Say hello to someone
function M.hello(name)
	print('Hello ' .. name)
end

--- Greet a person
function greet(name)
	print('Greetings, ' .. name)
end

return M

My settings are the same as above. I create a new Lua file and start writing the following:

local hello = require'hel

If I understand correctly, I should now get auto completion suggestions for hello, right? Furthermore, even if I complete the name by hand, the members of the hello object are only suggested in the most generic way, no type and no docstring is show. It works fine for the global greet however. See the attached screenshots.

The fact that the global is picked up properly means that the settings are getting passed properly to the server. So it looks like a server-side problem to me. The "/home/hiphish/.luarocks/share/lua/5.3/?.lua" pattern is one of the members of runtime.path, so my hello.lua file should get picked up on.

EDIT Forgot the screenshots

EDIT2

The completion of hello.hello is not from the server, it is from Neovim, it suggested a piece of text that already occurs in the buffer. It looked to me like the hello member function was being completed because the two names happen to be the same. If I had a local function howdy, then hello.howdy would not get suggested.

[sumneko]

Maybe it is a bug of the version before refactoring.
Please help me to check is it works well in refactoring version by changing the starting way of the server to load main-beta.lua instead of main.lua.

[HiPhish]

....

Yes, it does partially. Hovering for example works, but now completion doesn't work at all anymore, not even for keywords or global.

[sumneko]

Thanks for your test.
I should not fix the bug in old version, because I intend to replace the old version with the refactoring version in a week.
At present, I pay more attention to refactoring bugs, especially in non VSCode clients or non Windows platforms.
Would you please show me the log in EXTENSION/log ?

[HiPhish]

I have attached the logs:

• file_home_hiphish_Desktop.log
• service.log

I should not fix the bug in old version, because I intend to replace the old version with the refactoring version in a week.

Makes sense.

[sumneko]

Please manually apply the fix commit to help me test whether the repair is successful. (You can replace these two files directly)

The problem is that the client you are using doesn't support dynamic registration completion, and I didn't check the client's capability in the refactoring version.

I changed it to static register completion , which will result in setting of completion.enable is invalid in your client.

[HiPhish]

Now completion is working again. I still don't get suggestions when completing a module name (e.g. in require'he), but I also noticed that require is documented as a field instead of a function.

[HiPhish]

I just re-built the server completely and require is now shown as a function again. Is completion of modules names even supposed to work? If it is not, then it would mean all my issues in this thread are solved.

BTW, it would really make it much easier to follow the project if your commit messages were in English. Your English is pretty good from what I have seen in this thread, no need to hide it :)

[sumneko]

BTW, it would really make it much easier to follow the project if your commit messages were in English.

OK, I will try it.

Your English is pretty good from what I have seen in this thread, no need to hide it :)

Thanks to the translation software.

I just re-built the server completely and require is now shown as a function again. Is completion of modules names even supposed to work? If it is not, then it would mean all my issues in this thread are solved.

It should be worked like this. If not, I'll have a further check.

[HiPhish]

Yes, that completion is missing, see the attached screenshot.

OK, I will try it.

Thank you

Thanks to the translation software.

That's some really impressive translation software you are using then.