search

cloudhead / neovim-fuzzy

Minimalistic fuzzy file finding for neovim
BSD 3-Clause "New" or "Revised" License
111 stars 17 forks source link

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

Open bbatha opened 8 years ago

bbatha commented 8 years ago

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.

cloudhead commented 8 years ago

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

bbatha commented 8 years ago

I am in a git repo

On Wednesday, October 26, 2016, Alexis Sellier notifications@github.com 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 .

tssm commented 8 years ago

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.

cloudhead commented 8 years ago

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.

tssm commented 7 years ago

@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.

bbatha commented 7 years ago

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.

cloudhead commented 7 years ago

@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.

tssm commented 7 years ago

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).

bbatha commented 7 years ago

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.

cloudhead commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

tssm commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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

cloudhead commented 7 years ago

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!

tssm commented 7 years ago

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 commented 7 years ago

@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?

bbatha commented 7 years ago

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.

cloudhead commented 7 years ago

@tssm great, will see if I can reproduce!

cloudhead commented 7 years ago

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.

tssm commented 7 years ago

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

silenc3r commented 7 years ago

I can reproduce this behavior with vim-signify enabled.

tssm commented 7 years ago

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

cloudhead commented 7 years ago

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

tssm commented 7 years ago

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

tssm commented 6 years ago

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

cloudhead commented 6 years ago

I'll close this for now.

smarquez1 commented 5 years ago

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

IvRRimum commented 3 years ago

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 :(

cloudhead commented 3 years ago

I'm guessing that the problem is caused by the use of the lcd command (local change dir). If we found a way to not use that command, the problem should go away.