rooter_patterns child directories not working as expected

[cdalsass]

In g_rooters, I notice that

'>/Users/charlie/dev/'

Where I'd like to match the folder /Users/charlie/dev/project1, /Users/charlie/dev/project2 etc.

Does not work properly.

Looks like an easy fix, and will provide a PR - assuming I'm understanding the configuration properly.

Is anyone else seeing this?

[airblade]

What do you mean by not working properly? Please provide repro steps.

[cdalsass]

Configure vim as follows:

let g:rooter_patterns = ['>/Users/chucky/projects' ]

Setup a few projects.

 mkdir -p /Users/chucky/projects/project1
 mkdir -p /Users/chucky/projects/project2
 echo "test" > /Users/chucky/projects/project1/test.txt
 echo "test" > /Users/chucky/projects/project2/test.txt

open vim and edit project1/test.txt. Type ":pwd". Plugin doesn't switch to /Users/chucky/projects/project1/, as expected. Similarly, edit project2/test.txt. Does not correctly switch to project2.

NVIM v0.9.0 https://github.com/airblade/vim-rooter.git version 1353fa47ee3a81083c284e28ff4f7d92655d7c9e

[cdalsass]

@airblade let me know if my understanding is correct. Also, it would be great to refresh NerdTree when switching projects, as I've missed the console a few times and been confused. (I can include that too).

[airblade]

Thank you for the example – it's much easier to debug something concrete.

And your understanding of the pattern '>/some/dir' is correct.

Plugin doesn't switch to /Users/chucky/projects/project1/ ... Does not correctly switch to project2.

It does for me.

I wonder what differs between your setup and mine? You mentioned NerdTree; if you uninstall that, does your example start behaving as expected?

[cdalsass]

Even after uninstall of Nerdtree, the issue is there. Switching back to my branch does resolve it.

[kevincojean]

Same issue here.

Using:

VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Dec 20 2023 23:29:50)
Included patches: 1-2181

Reproducable steps:

• create the following file structure on your Desktop directory.

notes-dir
├── dir_file.txt
└── subdir
    └── subdir_file.txt

• Create a test vimrc file on your desktop named vim-rooter-vimrc with the contents:

let g:plug_home = expand('~/Desktop/vim-rooter-plug-home-test')
call system('mkdir -p ' . g:plug_home)

call plug#begin(plug_home)
Plug 'airblade/vim-rooter', { 'commit': '51402fb77c4d6ae94994e37dc7ca13bec8f4afcc'}
call plug#end()
packloadall

" let g:rooter_cd_cmd = 'cd'
let g:rooter_cd_cmd = 'lcd'
let g:rooter_resolve_links = 0
let g:rooter_silent_chdir = 0
let g:rooter_patterns = [">" . $HOME . "/Desktop/notes-dir"]

• cd ~/Desktop/notes-dir/subdir
• vim -Nu ~/Desktop/vim-rooter-vimrc -c PlugUpdate
• vim -Nu ~/Desktop/vim-rooter-vimrc subdir_file.txt
• execute :echo getcwd()

I get $HOME/Desktop/notes-dirs/subdir instead of $HOME/Desktop/notes-dirs.

[airblade]

@kevincojean I get $HOME/Desktop/notes-dir/subdir too, but that's correct.

Your pattern says the root directory has $HOME/Desktop/notes-dir as its direct parent, which in this makes the root $HOME/Desktop/notes-dir/subdir.

If you want to specify that notes-dir is the root, use =notes-dir.

[airblade]

Looking at the code, I now remember that a rooter pattern is supposed to be a directory name, not a full path – unless it is a (relative) glob.

@cdalsass If you change your pattern to >dev/ or >projects/, does that work for you?

@kevincojean If you change your pattern to =notes-dir, does that work?

[kevincojean]

Hello, thank you for the answer :)

If you want to specify that notes-dir is the root, use =notes-dir.

Alright, this does work!

@kevincojean If you change your pattern to =notes-dir, does that work?

It does!

Thank you :)

[kevincojean]

You solution using "=dir_name" works, but what if my dir name is quite generic?
If I want to disambiguate, how to do so?

For instance:

let g:rooter_patterns = [ "=notes",  "=" . $HOME . "/Documents/notes"]

I'd rather use the latter option (if it worked), as any project could possibly have a subdirectory named 'notes' which I wouldn't want to be the project root.

[airblade]

I've never actually had this problem in practice. I always just treat the git repo I'm in as the root.

The solution would be to change the code to accept full paths. I'm happy to do this though I can't guarantee when.

[kevincojean]

Thanks for the answer