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

HiPhish · 2020-11-18T18:34:58Z

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?

The text was updated successfully, but these errors were encountered:

sumneko · 2020-11-18T18:46:59Z

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 · 2020-11-18T19:53:14Z

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 · 2020-11-19T05:38:00Z

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 · 2020-11-19T16:47:30Z

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 · 2020-11-19T16:54:39Z

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 · 2020-11-19T17:09:49Z

....

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

sumneko · 2020-11-19T17:16:18Z

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 · 2020-11-19T17:20:33Z

I have attached the logs:

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 · 2020-11-19T17:47:12Z

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 · 2020-11-19T19:04:59Z

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 · 2020-11-19T21:47:37Z

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 · 2020-11-20T01:54:00Z

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 · 2020-11-20T17:09:58Z

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.

sumneko · 2020-11-23T12:10:35Z

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

Does it works in 1.1.1 ?

HiPhish · 2020-11-23T15:23:07Z

Does it works in 1.1.1 ?

Is 1.1.1 the current master? If so, then it is not working. Log files:

sumneko · 2020-11-23T15:50:24Z

What is the content of hello.lua ?
EDIT: I found it, let me try.

sumneko · 2020-11-23T16:00:48Z

I'm a little confused. Which functions are broken?

The completion of filename in require
The completion of field in local hello
The hover of local hello

HiPhish · 2020-11-23T16:41:12Z

All three: neither the file name in require nor the fields in hello are suggested. Completion of variables and globals (even from the hello module) works fine. The type of the hello variable is not shown either.

HiPhish · 2020-11-23T16:45:08Z

By the way, these are my settings:

Lua = {
	completion = {
		callSnippet = "Both",
	},
	runtime = {
		path = {
			"/home/hiphish/.luarocks/share/lua/5.3/?.lua",
			"/home/hiphish/.luarocks/share/lua/5.3/?/init.lua",
			"/home/hiphish/.luarocks/share/lua/5.3/?.lua",
			"/home/hiphish/.luarocks/share/lua/5.3/?/init.lua",
			"/usr/share/lua/5.3/?.lua",
			"/usr/share/lua/5.3/?/init.lua",
			"/usr/share/lua/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,
	}
}

sumneko · 2020-11-24T08:04:17Z

If it works when runtime.path is default?

HiPhish · 2020-11-24T20:05:59Z

Sorry, I was mistaken. My configuration was wrong, now I am getting proper completion suggestions for the most part. There is one more issue: some suggestions for require have their first letter missing. I will open a new issue for that, this one can be closed.

- final adjustments grsSwap - also added grsSwap abbriviation - some monkey-see-monkey-do configuration - config/nvim/lua/grs/devel/tooling.lua - sumnekop_lua section, based on - LuaLS/lua-language-server#259

sumneko added the bug Something isn't working label Nov 19, 2020

sumneko added a commit that referenced this issue Nov 19, 2020

#259 客户端不支持动态注册启用自动完成时，总是启用自动完成

f29abc7

HiPhish closed this as completed Nov 24, 2020

mjlbach mentioned this issue May 22, 2021

docs: update sumenko docs to add runtime files neovim/nvim-lspconfig#929

Merged

jdhao mentioned this issue Aug 14, 2022

Lua lsp jdhao/nvim-config#62

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

HiPhish commented Nov 18, 2020

sumneko commented Nov 18, 2020 •

edited

Loading

HiPhish commented Nov 18, 2020 •

edited

Loading

sumneko commented Nov 19, 2020

HiPhish commented Nov 19, 2020 •

edited

Loading

sumneko commented Nov 19, 2020 •

edited

Loading

HiPhish commented Nov 19, 2020

sumneko commented Nov 19, 2020

HiPhish commented Nov 19, 2020

sumneko commented Nov 19, 2020 •

edited

Loading

HiPhish commented Nov 19, 2020

HiPhish commented Nov 19, 2020

sumneko commented Nov 20, 2020

HiPhish commented Nov 20, 2020

sumneko commented Nov 23, 2020

HiPhish commented Nov 23, 2020

sumneko commented Nov 23, 2020 •

edited

Loading

sumneko commented Nov 23, 2020

HiPhish commented Nov 23, 2020 •

edited

Loading

HiPhish commented Nov 23, 2020 •

edited

Loading

sumneko commented Nov 24, 2020

HiPhish commented Nov 24, 2020

What values for Lua.runtime.path and Lua.workspace.library? #259

What values for Lua.runtime.path and Lua.workspace.library? #259

Comments

HiPhish commented Nov 18, 2020

sumneko commented Nov 18, 2020 • edited Loading

HiPhish commented Nov 18, 2020 • edited Loading

sumneko commented Nov 19, 2020

HiPhish commented Nov 19, 2020 • edited Loading

sumneko commented Nov 19, 2020 • edited Loading

HiPhish commented Nov 19, 2020

sumneko commented Nov 19, 2020

HiPhish commented Nov 19, 2020

sumneko commented Nov 19, 2020 • edited Loading

HiPhish commented Nov 19, 2020

HiPhish commented Nov 19, 2020

sumneko commented Nov 20, 2020

HiPhish commented Nov 20, 2020

sumneko commented Nov 23, 2020

HiPhish commented Nov 23, 2020

sumneko commented Nov 23, 2020 • edited Loading

sumneko commented Nov 23, 2020

HiPhish commented Nov 23, 2020 • edited Loading

HiPhish commented Nov 23, 2020 • edited Loading

sumneko commented Nov 24, 2020

HiPhish commented Nov 24, 2020

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

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

sumneko commented Nov 18, 2020 •

edited

Loading

HiPhish commented Nov 18, 2020 •

edited

Loading

HiPhish commented Nov 19, 2020 •

edited

Loading

sumneko commented Nov 19, 2020 •

edited

Loading

sumneko commented Nov 19, 2020 •

edited

Loading

sumneko commented Nov 23, 2020 •

edited

Loading

HiPhish commented Nov 23, 2020 •

edited

Loading

HiPhish commented Nov 23, 2020 •

edited

Loading