After a rename, the node loses selection

[opsidjflksdf]

Description

After you rename a (selected) node (file or folder) such that it changes its position in the current sorting order, the selection stays with the same number index within the tree (thus a different file/folder ending up being selected), instead of moving together with the node that was renamed.

In rename-file.lua, function fn(), there is code to update the selection:
find_file(utils.path_remove_trailing(new_file_path))
but the new_file_path variable only contains the filename or part of it (depending on the rename option chosen), rather than the entire path, even if relative.
rename() itself is called with
M.rename(node, prepend .. new_file_path .. append)
I tested and doing something like the following instead (calling find_file() with the same destination path that rename() was called with), fixes the issue (selection properly moves with the renamed node):

local new_full_file_path = prepend .. new_file_path .. append
M.rename(node, new_full_file_path )
[...]
find_file(utils.path_remove_trailing(new_full_file_path))

Could this be implemented? I wanted to run it by you rather than create a pull request in case there might be other considerations here. Thanks!

Neovim version

NVIM v0.10.2
Build type: Release
LuaJIT 2.1.1713484068
Run "nvim -V1 -v" for more info

Operating system and version

Windows 10

Windows variant

Native Windows

nvim-tree version

1.7.1 and latest master both have the issue

Clean room replication

nvim-tree with any file hierarchy

Steps to reproduce

In the nvim-tree window, set the selection on a node - file or folder, and then rename it with shortcut e or r. Selection doesn't move with the renamed item.

Expected behavior

Selection should move with the renamed item.

Actual behavior

Selection doesn't move with the renamed item.

[alex-courtis]

Not able to replicate on linux/alacritty.

It sounds likely a windows issue, due to the path difficulties in that OS.

nvim-tree team have no access to nor expertise with windows. Please do create the PR.

Please ensure changes are behind the windows feature flags

• utils.is_wsl (WSL) or
• utils.is_windows powershell?
  See wiki: OS Feature Flags

[opsidjflksdf]

Thanks for looking at it!
I can definitely create the PR guarded by OS flags.
Could you by any chance test (in Linux) with a file that's deeper in the hierarchy (rather than an immediate child of root), and possibly a file that has an extension, and rename with 'e' (basename). If, as it appears to be the case regardless of the OS, find_file() is called with just the new basename or filename, rather than the full path, even if find_file() somehow manages to find the file, you're bound to have at least some misbehavior where it will select a file under a different directory if you happen to have one similarly named in the hierarchy.

[alex-courtis]

Great find!

The highlighting issues occur for r and e but not u or <c-R>

This may not be OS specific.

[opsidjflksdf]

Ok, great, thanks for confirming!
I created the pull request with the code fix across all OS's, feel free to modify as fit.
Pull request:
#2974