Skip to content

Navigating to a file in the project root using fzf doesn't update the current working directory to point to the file's directory #1

@jcanseco

Description

@jcanseco

Reproduction Steps

  1. Open any git project in vim
  2. Using fzf, open a file anywhere in the project tree aside from the project root
  3. Run :pwd and note down the current working directory (cwd)
  4. Using fzf, open any file in the project root
  5. Run :pwd

Note that the cwd has not been updated; it still points to the first file's directory.

Findings

Inspection of the fzf source reveals that this is caused by a known issue.

Basically, when fzf performs a search, it first records the path to the current working directory (call this orig_dir). Then, it changes the cwd to point to the directory wherein it's supposed to perform the search (call this search_dir).

After receiving the search results, the user has the option to either open one of the resulting files or abort the search. In either case, the cwd is updated to point to the directory of the currently opened file (call this final_dir).

From here, fzf has to (due to omitted implementation constraints), restore the cwd to point to orig_dir, but doing so may not be desirable if the cwd was changed on purpose (i.e. when opening a file in a different directory). The problem is that the function responsible for deciding whether or not to restore cwd to orig_dir doesn't have enough information to make an accurate decision, and so it guesses using a simple heuristic:

if final_dir == search_dir:
    assume user aborted the search; restore cwd to orig_dir
else:
    assume user opened a file in a different directory; keep cwd equal to final_dir

Clearly, this heuristic doesn't properly handle the case where the user opens a file in the same directory as the search_dir (thus making final_dir == search_dir and incorrectly restoring cwd back to orig_dir).

Therefore, since we configured fzf to always search from the project root, opening a file in the root leads to fzf incorrectly reverting the cwd back to our original directory.

You can verify the above theory by performing the search on a different directory and trying to open a file in that directory, proving that the issue isn't just specific to project root files:

  1. Open any git project
  2. Using fzf, open a file anywhere in the project tree aside from the project root
  3. Run :pwd and note down the current working directory (cwd)
  4. Run :FZF <directory> where <directory> is the path to a directory in the project other than the cwd
  5. Open any of the files in that directory that result from the search
  6. Run :pwd

Potential Fix

Unfortunately, there is no real fix or workaround at the moment. We will just have to wait for the issue to be fixed on fzf.

Some things we already tried:

  • Replacing the lcd autocmd in vimrc with set autochdir (result: introduces other issues; lcd autocmd is needed to correctly set the cwd the first time when executing vim .)
  • Adding set autochdir in addition to the lcd autocmd (result: introduces other issues; opening the fzf window and closing it back forces the cwd to point to the project root even if you never actually opened a file to navigate there)

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions