BUG: opening up a file via Neotree results in gopls not honoring the package environment (on Windows) about neo-tree.nvim

[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.

[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 :)

[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.

• #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]

@burgr033 Could you help us out?

#1353 (comment)

[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.