BUG: opening up a file via Neotree results in gopls not honoring the package environment (on Windows)

[burgr033]

Did you check docs and existing issues?

• I have read all the docs.
• I have searched the existing issues.
• I have searched the existing discussions.

Neovim Version (nvim -v)

v0.9.5

Operating System / Version

Windows 11

Describe the Bug

When I open up a go file through neotree on windows, gopls (the go language server) doesn't work properly because it thinks it's not inside the package environment.

This only happens on Windows. I tried reproducing it on Arch and Debian.

Screenshots, Traceback

Steps to Reproduce

1. go mod init test123 -- init a new go project inside the repro enviornment.
2. create a main.go file with

package main
func main(){}

4. nvim -u init.lua -- open up neovim
5. :Neotree -- open up Neotree
6. select the file via Neotree and press return key

file should open now with a package warning through gopls along the lines of
No packages found for open file C:\\_workspace\temp\nvim_test\main.go

Expected Behavior

File should be opened and the package environment should be recognized

(If you open the file without Neotree e.g. with netrw or via command line; everything is working as expected)

Your Configuration

-- DO NOT change the paths and don't remove the colorscheme
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "cache" }) do
        vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
        vim.fn.system({ "git", "clone", "--filter=blob:none", "https://github.com/folke/lazy.nvim.git", lazypath })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
        "folke/tokyonight.nvim",
        "neovim/nvim-lspconfig",
        "williamboman/mason.nvim",
        "williamboman/mason-lspconfig.nvim",
        "neovim/nvim-lspconfig",
        -- add any other plugins here
}

local neotree_config = {
        "nvim-neo-tree/neo-tree.nvim",
        dependencies = { "MunifTanjim/nui.nvim", "nvim-tree/nvim-web-devicons", "nvim-lua/plenary.nvim" },
        cmd = { "Neotree" },
        keys = {
                { "<Leader>e", "<Cmd>Neotree<CR>" }, -- change or remove this line if relevant.
        },
        opts = {
                -- Your config here
                -- ...
        },
}

table.insert(plugins, neotree_config)
require("lazy").setup(plugins, {
        root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")
-- add anything else here

require("mason").setup()
require("mason-lspconfig").setup({
        ensure_installed = { "gopls" },
})
require("lspconfig").gopls.setup({})

[pysan3]

Looks like neo-tree opens the file with C:\\... whereas netrw opens with C:/.... So the number of slashes and front/back slash are the difference.

TBH language server must be able to parse both (or any) path style but gopls might not be clever enough.

@burgr033 Could you test if gopls works when you open the file with :e C:\... (single back slash). Please type out the whole path manually. I want to be sure the problem is slash type or because of the double slash right after C:.

@cseickel Do you think we should use / when passing the path to :e, :vs etc? FYI I use / for all vim commands in the rewrite.

[burgr033]

Thanks for your reply! The slash seems to be the problem.

:e C:\_workspace\temp\nvim_test\main.go --> everything works correctly
:e C:\\_workspace\temp\nvim_test\main.go --> does not work correctly

[pysan3]

@burgr033 Thanks for testing.

BTW do you remember when you started seeing this issue? I suspect it started recently after this PR was merged which adds an additional backslash when dirname starts with a punctuation.

• fix: improve path escaping for commands on Windows #1353

So the reason is that _workspace starts with punctuation and a second backslash is added to escape _ in windows.

The PR was required when path contains several punctuation C:\(foo)\[bar], but looks like it backlashed on a _.

If this is the case, I can fix it right away and FYI we will be using pathlib.nvim which will eliminate all these kind of problems in the future.

Just out of curiosity, why on earth did you start the name with _?

[burgr033]

Oh wow, I haven't thought about the _ haha. Thank you for the quick PR / Fix!

BTW do you remember when you started seeing this issue?

I started learning go a few weeks ago. So I couldn't really tell if this persisted longer.

Just out of curiosity, why on earth did you start the name with _?

It's some stupid legacy muscle memory stuff I picked up from my old work. I started it, because it's easier to find in the explorer, is always at the top of the folder list, when sorted by name, and it's really easy to cd autocomplete.

[pysan3]

Oh wow, I haven't thought about the _ haha. Thank you for the quick PR / Fix!

I don't have a quick access to Windows so it might take a while. Sorry but please be patient...

BTW do you remember when you started seeing this issue?

I started learning go a few weeks ago. So I couldn't really tell if this persisted longer.

👍

Just out of curiosity, why on earth did you start the name with _?

It's some stupid legacy muscle memory stuff I picked up from my old work. I started it, because it's easier to find in the explorer, is always at the top of the folder list, when sorted by name, and it's really easy to cd autocomplete.

NGL this is quite interesting. I use fuzzy finder (fzf) nowadays so I don't need to sort in any means but I'll remember this trick. I used 00- but it was kinda awkward...

[cseickel]

@cseickel Do you think we should use / when passing the path to :e, :vs etc? FYI I use / for all vim commands in the rewrite.

Hopefully there is one true form that all windows related tools agree on. Whatever that is we should ensure all paths are run through a class/function to coerce them into that standard form.

I can't tell you how sick I am of Windows path issues! If it were only on me then I would officially not support Windows. As it is I just accept PRs that seem reasonable and I totally rely on actual Windows users to determine what works.

[pysan3]

@cseickel Do you think we should use / when passing the path to :e, :vs etc? FYI I use / for all vim commands in the rewrite.

Hopefully there is one true form that all windows related tools agree on. Whatever that is we should ensure all paths are run through a class/function to coerce them into that standard form.

Good news, that is literally pathlib.nvim lol.
You have self:tostring() -> C:\(foo)\[bar], self:cmd_string() -> C:/(foo)/[bar], self:shell_string() -> 'C:/(foo)/[bar]' which will export the path object into strings that always work for each cases without any compromises.

I can't tell you how sick I am of Windows path issues! If it were only on me then I would officially not support Windows.

LOL me too.

Well all issues should be resolved once we fully migrate to pathlib ;)

[burgr033]

If this is too much of an edge case, I can live with renaming my folder tbh.

[pysan3]

No no this is clearly an issue. It's just that we have been dealing with Windows paths problem for so long and I have to launch a VM everytime to even just replicate the issue.

I've asked @bwpge to look into the issue #1353 (comment) so it should be fixed soon.

[pysan3]

@burgr033 Could you help us out?

#1353 (comment)

[burgr033]

Sure. I could look into it tonight or tomorrow.

[bwpge]

I'll take a look as well. Appreciate the detailed reporting on this issue :)

[bwpge]

I was able to reproduce the issue with gopls (thanks for the good repro steps). I have a tentatively working solution with the _workspace style path, so just wanted to communicate in case @burgr033 was working on anything and avoid duplicate work.

I'm just going to need to brute force inspect every Xworkspace directory and make sure the solution handles all cases for valid NTFS symbols in the path.

[burgr033]

I haven't gotten to do anything, so all good! Great that you have found a solution!

[bwpge]

@burgr033 if you maybe have some time this weekend, could you be a second pair of eyes on #1388 and see if it fixes your issue without any other problems?

You should be able to just drop-in replace your plugin spec with my fork (bwpge/neo-tree.nvim) and run :Lazy update neo-tree.nvim, but you may have to also change the branch to main if you're using v3.x.