jcanseco / .dotfiles Goto Github PK

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)

Reproduction Steps

1. Open vim in tmux
2. :set paste
3. Enter insert mode
4. Make vim lose focus (e.g. by switching to another window)
5. Go back to vim

Note that <F24><F25> has been inserted onto vim.

Findings

The issue seems to be caused by the vim-tmux-focus-events plugin.

The plugin sets <F24> and <F25> equal to <Esc>[O and <Esc>[I, respectively (source). This is the main way by which the plugin intercepts signals from tmux when vim loses and gains focus. The plugin then handles the signals by defining mappings for <F24> and <F25>.

The problem is that all mappings are disabled in paste mode, so <F24> and <F25> ends up being inserted with nothing to handle them.

It appears that zgen is no longer actively maintained as of 2019.

We should consider migrating to zgenom which appears to be the spiritual successor to zgen:

• It's a fork of zgen.
• It appears to offer a simple migration path.
• It appears to be mostly backwards compatible with zgen (meaning our .zshrc file needs only minimal changes).
• It appears to offer the same simple experience and high performance.
• It contains fixes to unresolved zgen issues.

The last point, in particular, would allow us to remove our reliance on our fork of zgen which only exists to contain fixes to unresolved zgen issues.