You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Unable to use the fzf binary automatically installed through space-vim. Firstly, in layers/+tools/fzf/packages.vim, where fzf is added to the plugins list w/ MP 'junegunn/fzf', { 'dir': '~/.fzf', 'do': './install --all', 'on': [] }, the installation directory of ~/.fzf is not automatically added to the user's $PATH (at least not in my case running Fedora 32). Though this was just a minor annoyance, easily fixed by modifying one's $PATH.
The bigger problem is that this installed fzf executable appears to be busted. Since when I try to use it, it gives a segfault:
And it was able to start indexing my files when I just ran ~ $ .fzf/bin/fzf-tmux alone.
Error in :messages
Error detected while processing function fzf#vim#files[15]..<SNR>80_fzf[1]..<SNR>80_check_requirements:
line 14:
E605: Exception not caught: Failed to run "fzf --version": []
The above error is certainly caused by the FZF binary.
Diagnosis & Suggestions
After a quick search, this problem is possibly related to fzf.vim issue #915. Though it might not, since the above segfault error was displayed inside of nvim, so that user's fzf binary outside of nvim could be fully functional. I cannot be sure either way.
If it the problem is indeed caused by Neovim, then there isn't much that can be done proactively on your end. But it'll probably be good to add a warning in the fzf layer's README that this can be a potential problem.
The simplest workaround is to just install FZF using the system package manager, which in my case was just # dnf install fzf, with the binary located at /usr/bin/fzf. This version works perfectly well both inside and outside of space-vim/Neovim.
Also a minor suggestion wrt the installation target on Linux machines at least, it's usually more standard to install to either ~/bin/ or ~/.local/bin/ rather that a subdir under ~/ itself. At minimum, users should be informed that they might have to manually add ~/.fzf/ to their $PATH.
The text was updated successfully, but these errors were encountered:
fzf's install script is supposed to append the binary's path to the user's $PATH. I think it reasonable to presume that fzf's install script terminated early due to the segmentation fault, and thus didn't add the binary to the $PATH. Thus, a bug in fzf and not space-vim. And probably fixed since. So I think this issue can be closed.
The detection of a system-wide install of fzf before doing a user-specific install of fzf would make sense. A simple check in layers/+tools/fzf/packages.vim
In PR #486 I propose moving the default user install of fzf to ~/.config/fzf (per XDG spec as used within fzf's install) instead of ~/.fzf, fzf is installed to ~/.fzf for historical reasons, as said a link from PR #486. I didn't like that ~/.fzf convention either.
Environment
:version
:SpaceInfo
Problem Description
Unable to use the
fzf
binary automatically installed through space-vim. Firstly, inlayers/+tools/fzf/packages.vim
, where fzf is added to the plugins list w/MP 'junegunn/fzf', { 'dir': '~/.fzf', 'do': './install --all', 'on': [] }
, the installation directory of~/.fzf
is not automatically added to the user's$PATH
(at least not in my case running Fedora 32). Though this was just a minor annoyance, easily fixed by modifying one's$PATH
.The bigger problem is that this installed
fzf
executable appears to be busted. Since when I try to use it, it gives a segfault:Funnily enough
fzf-tmux
appears to work fine:And it was able to start indexing my files when I just ran
~ $ .fzf/bin/fzf-tmux
alone.Error in
:messages
The above error is certainly caused by the FZF binary.
Diagnosis & Suggestions
After a quick search, this problem is possibly related to fzf.vim issue #915. Though it might not, since the above segfault error was displayed inside of nvim, so that user's fzf binary outside of nvim could be fully functional. I cannot be sure either way.
If it the problem is indeed caused by Neovim, then there isn't much that can be done proactively on your end. But it'll probably be good to add a warning in the fzf layer's README that this can be a potential problem.
The simplest workaround is to just install FZF using the system package manager, which in my case was just
# dnf install fzf
, with the binary located at/usr/bin/fzf
. This version works perfectly well both inside and outside of space-vim/Neovim.Also a minor suggestion wrt the installation target on Linux machines at least, it's usually more standard to install to either
~/bin/
or~/.local/bin/
rather that a subdir under~/
itself. At minimum, users should be informed that they might have to manually add~/.fzf/
to their$PATH
.The text was updated successfully, but these errors were encountered: