Buffer paths mix up when using `<Leader>b` with `autochdir` enabled

[ghost]

Command-T would loose track of buffers' working directory with autochdir flag set if you were to switch from 2 different buffers in a different directory using <Leader>b.

Steps to reproduce:

1. From shell, open a file for editing with vim vim ~/code/important/project/main.cpp
2. Open a different file from vim: :e ~/.bashrc
3. Switch buffers with <Leader>b. Notice how current buffer's working dir changes to the one of the previous focused buffer's, effectively causing vim to create an entirely new, empty buffer.

[wincent]

Thanks for the report!

            *'autochdir'* *'acd'* *'noautochdir'* *'noacd'*
'autochdir' 'acd'   boolean (default off)
            global
            {not in Vi}
            {only available when compiled with it, use
            exists("+autochdir") to check}
    When on, Vim will change the current working directory whenever you
    open a file, switch buffers, delete a buffer or open/close a window.
    It will change to the directory containing the file which was opened
    or selected.
    Note: When this option is on some plugins may not work.

Note the last line of the Vim help for 'autochdir'. Constantly changing the working directory creates un unstable environment in which it is hard for plug-ins to produce consistent behavior. I've always recommended against the use of 'autochdir' because I think there are better workflows where you anchor your working directory to the top level of the project. For example:

• Command-T itself is designed to be performant and useful even on huge repos (with a million files); there is no need to jump around directories in order to target a subset.
• There are good solutions for exploring the current directory.
• It's easy to set up mappings that do things like open files in the current directory.

I could go on...

Having said that, even though I think using 'autochdir' is a poor choice, it would be nice if Command-T could behave a little more graciously when it finds itself in that kind of environment. I'd be happy to review a PR that made it more robust against this edge case. I many also get to it myself, although I am not allocating a lot of time to Command-T right now. Adding the "bug" label in any case as the behavior is confusing and undesirable enough to warrant it.

[bradwood]

I had the same problem. The fix for me was simply to turn off autochdir as @wincent suggests.

[wincent]

Given the big rewrite for v6.0.x, I'm closing all older issues as there is unlikely to be anything significant happening on the 5-x-devel branch from here on[^patches]. Feedback issue for 6.0.x is here:

• https://github.com/wincent/command-t/issues/393

[^patches]: Patches and PRs would be welcome, but my personal efforts are going to be directed towards main.