Closed jdrouhard closed 3 years ago
Interesting, I want to understand the use case better, is there a reason why fzf.fzf('cd directory && <command-here>')
would not suffice for this?
That relies on the spawned process being a shell of some sort which is normally not the case (if launching FZF directly). Vim.loop (uv) supports changing the directory the process is spawned from and seems like the better choice than using a shell to hack around it. I could try it out anyway to see if I could make it work that way but I think having the option here would be a great addition!
I see. Currently a shell is used anyways, just to make the user interface easier for string arguments to fzf.fzf()
. But, I think this matters more for inputs that are not strings, then the cwd working directory is hard to change. Therefore, I'll take more detailed look at this soon, and then merge the feature in!
I envision adding a config option like fzf_binary
, maybe fzf_cwd
, and using that when it's provided.
I think that would work! The normal fzf plugin actually has its own pushd/popd implementation it uses to call :lcd
before and after the call to execute()
. I haven't looked too closely but it looks like there's code to allow the callback to change the directory so there's intelligence in popd
to only do so if the directory wasn't changed.
I think it's cleaner to just spawn the process from the loop in the appropriate directory so we don't even have to fiddle with vim's cwd at all. Benefits of the lower level libuv access!
I apologize for not using this commit, I was exploring the problem space and ended up implementing the feature independently. I used a pretty similar approach to what you used. I've updated the documentation too, try searching for fzf_cwd
and cmd.cwd
.
Hope this fixes the issue!
Not a problem at all, my PR was just an idea anyway. Thanks for the fast turnaround on this!
This is more of an idea than a ready-to-merge PR. I assume anything that would be merged would need additional tweaks or consideration for the actual API for the options dictionary.
What do you think of providing an non-breaking way to configure the working directory when spawning the fzf process? Specifically, this could be useful for providers that want to start fzf from the root of a project directory even when the current directory is in a nested directory somewhere.
The one use case that immediately comes to mind is a
git ls-files
provider which could be more useful it is run from the root of the git repository. fzf.vim does it this way but currently there's no way to spawn fzf anywhere other than nvim's cwd.Using this POC and a couple tweaks to fzf-lua's git providers, I was able to get all git files in the repo even when I was in a nested directory.