neovim-fuzzy icon indicating copy to clipboard operation
neovim-fuzzy copied to clipboard

FuzzyOpen changes the working directory of vim to the the parent dir of the file

Open bbatha opened this issue 8 years ago • 31 comments

Opening a file is now changing the cwd of vim or fzy such that subsequent uses of FuzzyOpen only search the folder the last file was found in.

bbatha avatar Oct 20 '16 19:10 bbatha

I can't reproduce this. Are you inside a .git repo or not?

cloudhead avatar Oct 26 '16 10:10 cloudhead

I am in a git repo

On Wednesday, October 26, 2016, Alexis Sellier [email protected] wrote:

I can't reproduce this. Are you inside a .git repo or not?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/cloudhead/neovim-fuzzy/issues/10#issuecomment-256309631, or mute the thread https://github.com/notifications/unsubscribe-auth/AASZo4FsRpcCV5vtABl14UrNm8mGX6BNks5q3yw8gaJpZM4KcgYJ .

bbatha avatar Oct 26 '16 15:10 bbatha

I have encounter a weird issue that can be related: some times all the filesystem files disappear from the fuzzy list and only the open buffers remain. I have tried to isolate when it happens without luck.

tssm avatar Nov 13 '16 15:11 tssm

I've had this issue, and on my side it had to do with my /tmp dir being full. The plugin creates a temporary file there to interface with the cli.

cloudhead avatar Nov 13 '16 15:11 cloudhead

@cloudhead how is called that temporary file? I would like to help debugging this (and hopefully send a pull request). I think @bbatha problem is the same.

tssm avatar Nov 21 '16 19:11 tssm

I checked my machine, my /tmp dir has several GB free. I also set my vim's tmp dir through backupdir and directory to be a directory in my home folder, which also has a lot of space in it.

bbatha avatar Nov 21 '16 22:11 bbatha

@tssm what makes you think it's the same problem? The temp file name is always different, but you can get an idea by running:

:echom tempname()

in nvim.

cloudhead avatar Nov 22 '16 15:11 cloudhead

Just a hunch. I don't know if @bbatha has checked :pwd and/or getcwd() but in my case sometimes it seems like the working directory changed (:FuzzyOpen only shows files from src/ because I only opened files from that dir) but in fact it didn't (pwd returns the expected working dir).

tssm avatar Nov 22 '16 18:11 tssm

I'm actually seeing the same behavior as @tssm my :pwd is still the same but :FuzzyOpen acts like my pwd is in a child-folder, usually the one containing the file I last opened through :FuzzyOpen. It does not happen every time I open a file with :FuzzyOpen though.

bbatha avatar Nov 22 '16 19:11 bbatha

Can you both check if the problem exists with the noroot branch? With vimplug you can do:

Plug 'cloudhead/neovim-fuzzy', { 'branch': 'noroot' }

This branch is reset to an older commit which doesn't base your search path on whether or not you're in a git repo. I suspect that could be what is causing the problem.

cloudhead avatar Nov 23 '16 10:11 cloudhead

Also I forgot to ask, what is shown in the fuzzy open status bar? The correct search dir or the incorrect one? ie:

FuzzyOpen ~/src/neovim-fuzzy (2 files)

cloudhead avatar Nov 23 '16 11:11 cloudhead

And finally, is anyone of you using set autochdir in your vim configs?

cloudhead avatar Nov 23 '16 11:11 cloudhead

@cloudhead just installed the plug-in from the noroot branch, let's see what happens.

FuzzyOpen always show the correct search dir and I don't have autochdir on $MYVIMRC.

tssm avatar Nov 23 '16 11:11 tssm

@cloudhead same issue on noroot branch, but this time I realized that the status line is wrong: it says FuzzyOpen (23 files) so no current dir (although :pwd reports the expected dir).

tssm avatar Nov 23 '16 13:11 tssm

@cloudhead just realized that the smaller status line is part of the noroot branch.

tssm avatar Nov 23 '16 13:11 tssm

In the current master branch, the status bar shows the search root, since the search root is not necessarily your pwd, it could be for instance the git root if you're in a repo.

In the noroot branch, this feature does not exist, and hence the search root is always the pwd, so nothing is shown on the status line.

So from what I understand, the issue you're having is not related to that feature, since you're having it with the noroot branch too. That narrows things down!

cloudhead avatar Nov 23 '16 15:11 cloudhead

Yep, it occurs on noroot too. It's pretty weird: the plug-in always starts working. I think some usage pattern makes it behave badly. Any other thing that you like s to try?

tssm avatar Nov 26 '16 19:11 tssm

@cloudhead I think I found the problem (in both master and noroot): when I do a search using :grep (directly or through a plug-in) the issue appears. Normally I use Grepper for search and if I close the quick fix list Fuzzy behaves normal again. If I use :grep directly I need to restart Neovim. @bbatha can you confirm that this is the problem?

tssm avatar Nov 28 '16 12:11 tssm

I can't seem to reproduce on either branch any more. I'm wondering if one of my other plugins caused the issue.

Edit: I stand corrected I still see the issue. I did not use grep not any other grepping plugin. I'll keep an eye close eye on potential interference.

Perhaps a hacky solution is to look in a parent dir for a .git or something.

bbatha avatar Nov 28 '16 16:11 bbatha

@tssm great, will see if I can reproduce!

cloudhead avatar Nov 29 '16 01:11 cloudhead

I haven't been able to reproduce, but I've recently run into another issue, and I'm wondering if there's a chance they are related: it happens when netrw is used, for example by using :E. Looking into this at the moment.

cloudhead avatar Dec 05 '16 00:12 cloudhead

@cloudhead yeah, I have seen a similar behavior using FileBeagle (a netrw replacement) but seems to be random...

tssm avatar Dec 06 '16 11:12 tssm

I can reproduce this behavior with vim-signify enabled.

silenc3r avatar Dec 29 '16 23:12 silenc3r

I think since one of the last commits I haven't experienced this behavior again. At least not that often. Can someone else confirm?

tssm avatar Apr 16 '17 21:04 tssm

In a recent patch I fixed an issue when the quickfix list is open, so it might have been the same bug.

cloudhead avatar Apr 19 '17 13:04 cloudhead

Yeah, that's what I thought when I saw the git log. Anyone else can confirm?

tssm avatar Apr 19 '17 18:04 tssm

Playing around trying to fix #24 I realized that the behavior described by me on this issue is indeed related to the quick fix window, which was fixed long ago, so I would close this unless @bbatha and @silenc3r still experience weird behavior

tssm avatar Dec 03 '17 16:12 tssm

I'll close this for now.

cloudhead avatar Dec 03 '17 20:12 cloudhead

This recently started happening to me. I red the comments on this issue and found out that it stops happenning when I disable the vim-signify plugin. I checked out the latest changes on said plugin and found a commit that might be related: https://github.com/mhinz/vim-signify/commit/ea6db3c7df7671584df0a37a2436a919332d0b7c

smarquez1 avatar Jan 08 '19 17:01 smarquez1

This problem is present if you have Plug 'fatih/vim-go' present. If you disable it, then it doesnt change the current folder to target of your search, but the problem is that vim-gois super great problem, which i don't want to sacrifice :(

IvRRimum avatar Jun 02 '21 10:06 IvRRimum