Template loads fine in VSCode, but not in neovim

[checkraisefold]

Describe the bug I was able to get .meta/template folder to load correctly for a project using the VSCode extension, but not with neovim. https://github.com/RosaServer/RosaServerCore/tree/master/.meta/template

All globals defined by the template aren't autocompleted and give off undefined errors from diagnostics. This doesn't happen in VSCode and diagnostics and autocompletion work perfectly with the meta template. Attached are the trace level logs from VSCode and neovim, which look about the same. Can't figure out the issue here. Tried completely copying over the LSP config from VSCode to my neovim LSP config, no dice. The builtin templates seem to work fine though in my testing, so all built in lua libraries autocomplete and have fine diagnostics.

Disabling diagnostics in the LSP config on neovim removes the error messages in the screenshot, so it is the LSP reporting them and not something else.

To Reproduce Steps to reproduce the behavior:

1. Load a project with meta template in neovim with LSP installed
2. Template information should load, but it doesn't. Incomplete autocomplete/diagnostics as a result.

Expected behavior Workspace meta template information to be loaded and allow correct diagnostics and autocompletion.

Screenshots

Environment (please complete the following information):

• OS: Windows
• Client: neovim using Windows Terminal

Provide logs file_C_Users_Dev1_Desktop_development_RosaServerCore.log file_c3A_Users_Dev1_Desktop_development_RosaServerCore.log

[carsakiller]

I am not familiar with NeoVim, but can you confirm that this is path to the workspace you are working in?

C:/Users/Dev1/Desktop/development/RosaServerCore

Are you loading these meta files using workspace.library? If so, I believe you have configured this setting incorrectly.

Your config:

workspace = {
      library = {
        ["C:\\Program Files\\Neovim\\share\\nvim\\runtime\\lua"] = true,
        ["C:\\Program Files\\Neovim\\share\\nvim\\runtime\\lua\\vim\\lsp"] = true
      }

But workspace.library is an array so I think it should read:

workspace = {
      library = {
        "C:\\Program Files\\Neovim\\share\\nvim\\runtime\\lua",
        "C:\\Program Files\\Neovim\\share\\nvim\\runtime\\lua\\vim\\lsp"
      }

You may also want to add a @meta annotation to the top of your definition files as it helps prevent accidental replaces and prevents reference (not definition) finds from pointing to it.

[checkraisefold]

I am not familiar with NeoVim, but can you confirm that this is path to the workspace you are working in?

C:/Users/Dev1/Desktop/development/RosaServerCore

Are you loading these meta files using workspace.library? If so, I believe you have configured this setting incorrectly.

Your config:

workspace = {
      library = {
        ["C:\\Program Files\\Neovim\\share\\nvim\\runtime\\lua"] = true,
        ["C:\\Program Files\\Neovim\\share\\nvim\\runtime\\lua\\vim\\lsp"] = true
      }

But workspace.library is an array so I think it should read:

workspace = {
      library = {
        "C:\\Program Files\\Neovim\\share\\nvim\\runtime\\lua",
        "C:\\Program Files\\Neovim\\share\\nvim\\runtime\\lua\\vim\\lsp"
      }

You may also want to add a @meta annotation to the top of your definition files as it helps prevent accidental replaces and prevents reference (not definition) finds from pointing to it.

Yes, the workspace path is correct. I am not loading the meta files using workspace.library. I assumed the meta files in the workspace loaded without having to add the workspace itself to workpsace.library? I just tried adding the template folder to workspace.library anyway, still no dice. The workspace.library setting in the config is a default from neovim lspconfig, but I just fixed that anyway since it was wrong.

[carsakiller]

I was not aware your definition files are located in the same workspace, this should work without needing to specify workspace.library.

It does appear that your meta files are being loaded by the server:

file_c3A_Users_Dev1_Desktop_development_RosaServerCore.log: L1079-1082:

[22:27:48.557][debug][#0:script\workspace\loading.lua:97]: Preload file at: file:///c%3A/Users/Dev1/Desktop/development/RosaServerCore/.meta/template/globals.lua , size = 28.344 KB
[22:27:48.557][debug][#0:script\files.lua:389]: add ref	file:///c%3A/Users/Dev1/Desktop/development/RosaServerCore/.meta/template/globals.lua
[22:27:48.557][debug][#0:script\workspace\loading.lua:97]: Preload file at: file:///c%3A/Users/Dev1/Desktop/development/RosaServerCore/.meta/template/types.lua , size = 49.121 KB
[22:27:48.557][debug][#0:script\files.lua:389]: add ref	file:///c%3A/Users/Dev1/Desktop/development/RosaServerCore/.meta/template/types.lua

Unfortunately, I am out of ideas now 😄

[checkraisefold]

Unfortunately, I am out of ideas now 😄

Yeah this was really confusing when testing locally - it works fine in VSCode and the same errors in the screenshot I don't get with diagnostics on in VSCode, but I do in neovim. I could literally find no difference in the logs or my configuration that would cause this.

[sumneko]

Please check if this commit works

[checkraisefold]

Please check if this commit works

I am up and working, thanks so much! The log is also named correctly now, no 'c3a' in the log name, just 'C'

[clason]

This commit has introduced a regression with Neovim: if I set the root directory to . (corresponding to adding . as a workspaceFolder), I now get the following warning:

LSP[sumneko] Your workspace is set to `/`. Lua language server refused to load this directory. Please check your configuration.[learn more here](https://github.com/sumneko/lua-language-server/wiki/Why-scanning-home-folder)

Note that . is not my home directory; it is in fact the correct root of my project (which I'm starting Neovim from). It seems that the normalization falsely conflates the relative path . with /. (The warning did not appear before this commit according to git bisect.)

[checkraisefold]

Reopening for regression

[sumneko]

This commit has introduced a regression with Neovim: if I set the root directory to . (corresponding to adding . as a workspaceFolder), I now get the following warning:

rootUri and workspaceFolders[].uri should be type URI, I don't think . can be used as URI.

[clason]

That's a significant breaking change, then, as this was accepted before...

In any case, conflating . and / doesn't seem correct to me, even if . is not valid -- the latter then should give a different, helpful, error message :)

[clason]

And if I pass file://. as URI, lua-language-server reports

 workspaceFolders = <1>{ {
        name = "file://.",
        uri = "file://file://."
      } },

That can't be right :D

[sumneko]

And if I pass file://. as URI, lua-language-server reports

 workspaceFolders = <1>{ {
        name = "file://.",
        uri = "file://file://."
      } },

That can't be right :D

AFAIK, uri can not be relative, see https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#uri

[clason]

I see; that needs to be handled by Neovim then.

Still, my point about . and / stands -- if the name must be absolute, that should not lead to a misleading error message...

[sumneko]

I see; that needs to be handled by Neovim then.

Still, my point about . and / stands -- if the name must be absolute, that should not lead to a misleading error message...

I almost did not check the correctness because it was too troublesome. I just simply assume that the input is a legal URI.

[clason]

Still, would it be too much to ask for to continue supporting relative paths? It worked fine before this commit, and getting absolute paths from a terminal editor started in a given directory is difficult...

[sumneko]

I temporarily do compatible treatment, but I still recommend that you implement it in accordance with the specifications. At present, it may be because of good luck, because the function parameters of the stitching path are designed to be (folderUri, relativePath), so that the wrong URI can be retained. (In principle, the URI should not be concated. I should turn the URI into PATH then stitching them and then return back to the URI, but I am lazy.)

[clason]

Thank you, I appreciate that! I have brought up the issue with the other Neovim devs.

Still, this does not fix my issue, since . is still incorrectly treated as /, leading to the false error I mentioned.

[sumneko]

Still, this does not fix my issue, since . is still incorrectly treated as /, leading to the false error I mentioned.

Are you using . instead of file://. ?

[clason]

yes, I am passing . as the name:

    workspaceFolders = <1>{ {
        name = ".",
        uri = "file://."
      } },

[sumneko]

yes, I am passing . as the name:

    workspaceFolders = <1>{ {
        name = ".",
        uri = "file://."
      } },

I never used name, pass it by uri

EDIT: So you just passed file://. as uri before? Let me think if I can hanlde this.

[clason]

Again, the central issue is that the new check wrongly detects file://. as file:/// so that the wrong error is triggered. If that error can be avoided, things will continue to work as before.

[sumneko]

I did some tests about file://. . This uri should be converted to path / . In this case I should try to scan your root directory and cause the initialization to be unable to complete. Fortunately, my implementation is not strict enough, which causes this URI to be converted into an empty string. As an illegal path, I will not scan any files.

[clason]

This uri should be converted to path /

Why? (Honestly asking! This seems wrong to me...)

(I wouldn't trust VS Code to know -- or care -- which way is up from a standard...)

[sumneko]

This uri should be converted to path /

Why? (Honestly asking! This seems wrong to me...)

I don't know, maybe this is an unfarished behavior, because URI does not support the relative path.

file://. will parsed as scheme = 'file', authority = '.', path = ''. But path can not be empty string, I did nothing but VSCode fallback to / here.

[clason]

I see. Not surprised that VS Code doesn't believe in validation...

Thank you for your time explaining this to me!

[clason]

and for addressing this even if it's invalid! ❤️