[vim/vim] netrw: Can't navigate to parent folder under Windows OS (Issue #18421)
Edmond Solomon
eddaso created an issue (vim/vim#18421)Steps to reproduce
Type command :Ex
When pressing on "../" in directory listing, but nothing happens.
Expected behaviour
It should navigate to the parent folder, but it doesn't.
Version of Vim
9.1.1734+ (all versions after 9.1.1732 have this bug)
Environment
Windows 11
vim.exe or gvim.exe, doesn't matter.
Logs and stack traces
In version 9.1.1734, the following was listed as one of the changes in the vim win32 installer releases github page: runtime(netrw): Ensure netrw#fs#Dirname() always returns a trailing slash Perhaps, this is the culprit, but I don't know for sure.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Enno
Konfekt left a comment (vim/vim#18421)I can reproduce; indeed undoing #18199 that is, replacing
return netrw#fs#AbsPath(a:path) . s:slash
by
return netrw#fs#AbsPath(a:path)->fnamemodify(':h')
fixes the issue
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Enno
Konfekt left a comment (vim/vim#18421)@MiguelBarro Would you mind checking on Windows?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Enno
Konfekt left a comment (vim/vim#18421)The obvious fix would be case distinction for ssh, but maybe there's a root cause better treated than this symptom
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
MiguelBarro
MiguelBarro left a comment (vim/vim#18421)@MiguelBarro Would you mind checking on Windows?
@Konfekt
I'm not able to reproduce the issue: either pressing - or selecting ../ (on normal mode) work fine in the tree view for windows and linux.
Regarding using :e ../ (in command mode) it was broken before #18199 and remains broken afterwards.
In fact the only function modified in #18199 is never called doing :e ../.
Maybe is that the error the mysterious @eddaso so accurately pinpoints as his first github activity.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Enno
Konfekt left a comment (vim/vim#18421)tree view
Oh, I used let g:netrw_liststyle = 2
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Enno
Konfekt left a comment (vim/vim#18421)So I read the issue as hitting <CR> on .. in a netrw window, say :e ~
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
MiguelBarro
MiguelBarro left a comment (vim/vim#18421)tree view
Oh, I used
let g:netrw_liststyle = 2
@Konfekt I can not reproduced it either with that setting.
I'm afraid netrw plugin is in dire need of testing.
Maybe @eddaso can provide a minimal reproducer.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Edmond Solomon
eddaso left a comment (vim/vim#18421)I also found this post of someone else experiencing the same problem. https://vi.stackexchange.com/questions/47216/how-to-solve-the-issue-with-netrw-not-letting-go-up-the-folder.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
MiguelBarro
MiguelBarro left a comment (vim/vim#18421)@eddaso I managed to reproduce your issue without a .vimrc.
Let me look into it.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#18421)This seems to fix it:
diff --git a/runtime/pack/dist/opt/netrw/autoload/netrw/fs.vim b/runtime/pack/dist/opt/netrw/autoload/netrw/fs.vim index 2f0841500..ea3ed98ee 100644 --- a/runtime/pack/dist/opt/netrw/autoload/netrw/fs.vim +++ b/runtime/pack/dist/opt/netrw/autoload/netrw/fs.vim @@ -88,7 +88,8 @@ endfunction function netrw#fs#Dirname(path) " Keep a slash as directory recognition pattern - return netrw#fs#AbsPath(a:path) . s:slash + " Always use a forward trailing slash + return netrw#fs#AbsPath(a:path) . '/' endfunction " }}}
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
MiguelBarro
MiguelBarro left a comment (vim/vim#18421)@chrisbra it does partially.
It turns out :e ../ works fine with an empty .vimrc but stops working after replacing s:slash with /.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
MiguelBarro
MiguelBarro left a comment (vim/vim#18421)@chrisbra is right.
The problem are the regexp that function s:NetrwBrowseChgDir() uses to trim the path given by netrw#fs#Dirname() ang go up:
https://github.com/vim/vim/blob/dddde9ce123c665e27faccbcb368ca9e88ed18ed/runtime/pack/dist/opt/netrw/autoload/netrw.vim#L3972-L3979
Note both expect / as path separator. Thus, netrw#fs#Dirname() return value must be independent from shellslash value and fixed to / too.
Regarding :e ../ only works if g:netrw_keepdir=0. That's because netrw relies on BufEnter autocommands to handle :edit:
https://github.com/vim/vim/blob/dddde9ce123c665e27faccbcb368ca9e88ed18ed/runtime/pack/dist/opt/netrw/plugin/netrwPlugin.vim#L25-L33
But s:LocalBrowse() doesn't receive ../ as argument but getcwd()->fnamemodify(":h"). Thus, the plugin cannot handle this case as is hinted here:
https://github.com/vim/vim/blob/dddde9ce123c665e27faccbcb368ca9e88ed18ed/runtime/pack/dist/opt/netrw/doc/netrw.txt#L1739-L1740
Sorry for all the havoc created with #18199 I didn't notice the 'shellslash' issue.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Enno
Konfekt left a comment (vim/vim#18421)Launched a Window 11 VM; I could reproduce with Vim 9.1.1782 running vim --clean -u C:/Users/konfekt/vimfiles/viminrc +":e ." with viminrc reading
filetype plugin indent on syntax on
Reverting the change solved the issue
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.