(m)ove the current node shortcut doesn't treat filepaths as case sensitive

[kevinkowalew]

Description

• The (m)ove the current node menu shortcut doesn't treat file paths as case sensitive. This prevents the command from detecting changes to the capitalization of letters in a move command (ex: it treats ~/project/Test.go and ~/project/test.go as equivalent).

Environment

• Operating System: macOS Sonoma (14.0)
• Vim/Neovim version :version: vim 9.0.1544
• NERDTree version, found on first line of quickhelp ?: 6.10.16
• Are you using any of these NERDTree-dependent plugins?
  • Xuyuanp/nerdtree-git-plugin
  • ryanoasis/vim-devicons
  • tiagofumo/vim-nerdtree-syntax-highlight
  • scrooloose/nerdtree-project-plugin
  • PhilRunninger/nerdtree-buffer-ops
  • PhilRunninger/nerdtree-visual-selection
  • jistr/vim-nerdtree-tabs
  • Others (specify):
• Provide a minimal .vimrc file that will reproduce the issue.
  • No custom run commands needed

Steps to Reproduce the Issue

1. Create a file named test.txt
2. Open said file in vim & open NERDTREE
3. Move the file to the same path using the mm command and name it Test.txt

Current Behavior (Include screenshots where appropriate.)

• The following output is shown: NERDTREE: This destination already exists. Try again

Expected Result

• Moves the file as expected

[rzvxa]

It's not a bug! It is a platform limitation. The MacOS does not support case-sensitive file names by default. If I'm not mistaken, you can only enable it with some additional options. I'm not a Mac user so I would appreciate it if someone could validate my fact here.
https://discussions.apple.com/thread/251191099

[rzvxa]

The current implementation of this action does this by checking whether the destination file exists or not, And on platforms that do not have case sensitivity, it refuses to do this renaming Because it thinks there is already a file that exists with the input name.

I'll work on a workaround for this.
We can check if the destination path is the same as the new path with a different casing on platforms that don't support this feature. I'm not sure if it's the best approach so maybe I do something different when I start working on it.

[rzvxa]

Feel free to create a PR if you want to do it. I'll try to help you with it if you need any.

[rzvxa]

@kevinkowalew

Hello,

Good news, I've managed to find a workaround for this issue, I'm proposing a new option called g:NERDTreeCaseInsensitiveFS and by setting it to one in your config file you can fix this issue in case insensitive file systems, for example, you can do something like this:

let g:NERDTreeCaseInsensitiveFS=1

I've explained it in the documentation just use :help NERDTreeCaseInsensitiveFS to find out more about it.

I would appreciate it if you give this PR a spin, I can only confirm that it works on Windows machines(yes windows also has a case-insensitive file system).
#1375

[kevinkowalew]

Wonderful, appreciate you putting together a patch for this @rzvxa! I'm able to confirm this is working on macOS 👍

[rzvxa]

Great, Since I don't have write access to the project it would be nice if you could give it a review on the PR so the current maintainer gets a point of reference from a Mac user.

It is up to you if you want to keep this issue open until the merge or close it since PR alone can keep track of this issue(and you can always create new issues if you find anything weird with the new implementation).

[rzvxa]

Hello @kevinkowalew
Sorry to bother you, After the last time we talked I had some time so I tried to make the implementation more clear.
May I ask if you have some time to spare to give it a go? The flag's name has changed from NERDTreeCaseInsensitiveFS to NERDTreeCaseSensitiveFS and It works differently from the last time you used it.
There is the documentation for it if you want to find out more use help NERDTreeCaseSensitiveFS
But for this test, I would like you to set it to 0 or 3.
Let me know if you find any problem with it. If it works fine on macOS we can actually merge it in.

[kevinkowalew]

Hi @rzvxa, I tested both 0 and 3 on macOS this morning and it achieves the desired behavior. I'll drop a comment on ¥our PR as well to indicate that this is ready to be merged. Thanks again for your help with this issue!

[rzvxa]

@kevinkowalew
Hi, Thanks, man. Testing it is priceless it could've taken months before a Mac user would've tested it.
To be honest I've had the same problem when I'm on Windows and I used to get around it by renaming the file to something else first, So as soon as I saw your issue I thought to myself now is the time to do it.
Have a great day mate!

[kevinkowalew]

Happy to help @rzvxa. Thanks again for putting in the time to put together a patch for this!