search

tpope / vim-unimpaired

unimpaired.vim: Pairs of handy bracket mappings
https://www.vim.org/scripts/script.php?script_id=1590
3.31k stars 205 forks source link

[f and ]f traverse subdirectories (.git included), is this intended behaviour? #227

Closed ferdinandyb closed 2 years ago

ferdinandyb commented 2 years ago

Based on the documentation I expected [f and ]f to only operate on the current directory non-recursively, but it actually enters subdirectories as well, including for example the hidden .git directory. Although I might expect that some people would want it to traverse subdirs, I don't think anyone wants it to do so with hidden directories, and certainly not .git. Is this a bug or a feature? If the latter, would it be possible to have a "don't touch hidden dirs" option? Thanks!

tpope commented 2 years ago

It's intended. Not only can you descend into a hidden directory, you can also ascend from one, and forbidding the former raises questions about the latter. Admittedly .git is an extremely unfortunate place to land, but it seems like a weird thing to come up in practice. Are you starting with ]f outside of the repository and descending into it?

ferdinandyb commented 2 years ago

I tested this now with a minimal vimrc to make sure it's not a plugin like rooter having side effects. I go into a root folder of a git repo, open up vim and start pressing ]f (it is a small repo with only 4 files). The first hit is actually .git/COMMIT_EDITMSG and it cycles through files in .git. If I start cycling back with [f after .git/COMMIT_EDITMSG it actually exists the directory and opens a file in the parent directory of where I initially opened vim. I never actually hit any of the files I would have actually wanted to open (i.e. any of the 4 files in the original folder).

I also tried this now in a larger repo which had hidden files and after cycling through the hidden files ]f descended straight into .git and cycling backwards again exited the original folder and started going through the files of another child of the parent of the directory I originally opened vim in, so it seems pretty consistent to me and not so much an edge case.

Admittedly, if you already have a file open somewhere in the "middle" then this not a huge issue if you don't want to move much, but it does makes it in practice impossible to reach a hidden file that is earlier in the alphabet then g, and reach anything after .git if you start on a hidden file before g. I also find it very surprising that I can reach a file that is not in or below the current path (I think I actually find it strange to go down in the tree as well, but I think going "outside" from the cwd might be stranger for even more people. Tbh I actually half expected this command to loop around and start from the first file in the repo once it reached the last, but that is probably not entirely logical).