coc-lua nvim bugs

[poetaman]

This issue is to get your input on the bugs I recently filed on coc-lua:

Keeps on trying to get access to contacts, reminders, photos: josa42/coc-lua#58

Disable prompt asking for more files: Preloaded files has reached upper limit: josa42/coc-lua#59

[sumneko]

Please see https://github.com/sumneko/lua-language-server/wiki/Why-scanning-home-folder%3F

[oblitum]

Reading that docs I think that maybe coc.nvim author should take in consideration whether current behavior of coc.nvim is correct or not, fwiw I'm facing the same issue with coc-lua (I can't open my init.lua from ~ without triggering whole home scan), but have also hit the same with other language servers in the past, like pylsp and bash-language-server.

cc @chemzqm @fannheyward

[chemzqm]

current behavior of coc.nvim is correct or not,

What behavior di you mean?

[oblitum]

@chemzqm according to the linked wiki page:

According to the provisions of the LSP, the client will provide the server with the uri of the folder to be scanned (field rootUri). If you only opened a single file, then the uri should be null.

A common situation is that some clients or users misunderstand the meaning of rootUri and set this field to the uri of home, the root directory of the client, the root directory of this extension, etc. In this case, the extension will faithfully scan the file according to the provided uri.

My assessment is that coc.nvim does act like the last paragraph describes, but it seems it shouldn't according to the whole explanation.

I'm actually not sure which behavior is precisely correct, as I'm not a LSP developer, but I just wanted to point out the conflicting information and behavior.

What I know is that when using coc.nvim with some language servers it may well cause the servers to scan the whole home directory (if it's under git) if you open a file like nvim .config/nvim/init.lua. I've seen this home scan happening with many servers, not only with lua-language-server, but also with bash language server and pyls. And this is what now I'm not sure is expected to happen or a bug in coc root resolve implementation.

What I did to fix that for bash language server was to set 'ignoredRootPaths': ['~'], because I use the bash language server with raw language server conf, but for example, I don't have the same option with coc-lua, which is a extension, this option is not available, and even if it were available, I'm not sure it would be the right solution because I'd still want coc completion inside init.lua, just not have the whole folder scanned. 'ignoredRootPaths': ['~'] avoids the scan, but also stops coc entirely.

Currently I have to cd inside ~/.config/nvim/ and do nvim init.lua to avoid the problem. Another workaround is to "Got around this by adding all the folders in my home directory to .gitignore file".

[oblitum]

hi @chemzqm, I saw you provided a fix at neoclide/coc.nvim@7904a9e, and while that seems nice to have at first, I think I should point out that the issue stated here seems more generic than just for the home folder (which is a hard-coded solution):

According to the provisions of the LSP, the client will provide the server with the uri of the folder to be scanned (field rootUri). If you only opened a single file, then the uri should be null.

The specification link provides:

	/**
	 * The rootUri of the workspace. Is null if no
	 * folder is open. If both `rootPath` and `rootUri` are set
	 * `rootUri` wins.
	 *
	 * @deprecated in favour of `workspaceFolders`
	 */
	rootUri: DocumentUri | null;

and

	/**
	 * The workspace folders configured in the client when the server starts.
	 * This property is only available if the client supports workspace folders.
	 * It can be `null` if the client supports workspace folders but none are
	 * configured.
	 *
	 * @since 3.6.0
	 */
	workspaceFolders?: WorkspaceFolder[] | null;

As @sumneko points in their wikipage "If you only opened a single file, then the uri should be null" seems true information. The spec states about having to configure or open a workspace folder for a given project, for it to actually have one, otherwise it should be null. So some more generic solution would implement null workspace for any file opened alone (not sure how that should be done in vim under coc root resolve semantics).

The hard-coded home folder fix may have solved the problem for the home folder, but the problem still persists for any other large directory.

[chemzqm]

There's no open workspace folder concept with vim, unless you build something on top of it.
The extension could specify ignoredRootPaths of clientOptions

[oblitum]

@chemzqm ok, guess that's the best that can be done.

[oblitum]

@chemzqm notice that the side-effect of the current fix is not having coc working for any file that's open from home folder (which may be even more unexpected for another audience of users). I have already mentioned this at "'ignoredRootPaths': ['~'] avoids the scan, but also stops coc entirely" above. It would be best to have coc-lua working (like when I cd into ~/.config/nvim first and do nvim init.lua from there), but not having home as "rootUri" and scanned entirely, which I dunno how to do under coc/vim semantics.

[chemzqm]

You should make use of rootPatterns https://github.com/neoclide/coc.nvim/wiki/Using-workspaceFolders

[poetaman]

@chemzqm Is there a way to get around the second issue I pointed out in my ticket description? Here's a link: josa42/coc-lua#59. Every time I open a .lua file, that annoying prompt shows up...

[chemzqm]

coc-lua could implement option to disable that or provide not shown again option and save result to workspaceState.

[oblitum]

FYI, coc.nvim got this fixed as expected on neoclide/coc.nvim#3102 / neoclide/coc.nvim@39c14a3. Besides that, I highly recommend coc-sumneko-lua over coc-lua (coc-lua's author is very unresponsive and the extension is plagued with issues).