fzf.el
fzf.el copied to clipboard
bling
fzf buffer opens and closes a window just for a few milliseconds
When I run fzf it instantly opens and closes the fzf completion window. No errors is shown in Messages. Emacs 25.1.1. fzf 20160908.806.
Same problem here. GNU Emacs 25.1.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.23) of 2016-11-18 fzf 20160908.806
Same issue. GNU Emacs 25.1.2 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9) of 2016-09-28 fzf version 0.16.2
If you just installed fzf, restart your terminal and emacs.
Doesn't fix the issue unfortunately.
can you guys try out the latest version of both fzf and fzf.el and see if you get the same behavior? i actually noticed this after merging the latest PR, and rolled it back to fix it on my computer (https://github.com/bling/fzf.el/commit/9b1744b8cf8817912164fc08d01b3d9e541d6479).
do you see instant death with both versions of how args are passed in?
Tried the latest version of fzf and fzf.el, source'd fzf and restarted Emacs, and the issue persists unfortunately.
fzf.el: 20170824.904
fzf: 0.17.0 (e89eebb)
do you see instant death with both versions of how args are passed in?
Can you elaborate on this? I'm happy to help troubleshoot.
@brycethomas can you try one version back https://github.com/bling/fzf.el/commit/86a9f0a1e8fe8bc585faf0f52826957bc9cd8115? that version has args passed in as a list instead of a string.
on my virtual machine, i see the buffer created and destroyed pretty much instantaneously, but only one version back. on latest, everything is fine.
if one version back fixes it for you, please post what version of emacs and linux/distro you're running. thanks!
Tried off the latest from git (and not melpa). There are few issues here:
- split window isn't cleared and progressively it gets shorter and refuses to split for subsequent M^x fzf command. Also the current selected file is not in picture.
- opening the file gives an error:
This is on Arch linux with Emacs-25.2
--
Thanks.
@codesoverhill i'm running arch in a VM with emacs 25.2.1 on the latest on git and i can't reproduce what you're seeing. i suspect there might be something in your .emacs. can you try again with emacs -Q so it's a clean slate? thanks.
@brycethomas can you try one version back 86a9f0a?
What version is this in MELPA? 20170824.904?
My buffer was closing immediately because fzf couldn't be found.
Here's how I solved it:
- removed the line in
.fzf.bashthat added its dir to the$PATH - instead, added a symlink to the fzf bin (located under
./bin/of wherever you put the repo) in/usr/local/bin
I was having this problem because I'm using Emacs on Mac OS and appear that there is a problem with the Mac version while getting the contents of the PATH variable.
I installed FZF via Homebrew. So my solution was add the path to /usr/local/bin manually:
(when (memq window-system '(mac ns))
(setenv "PATH" (concat (getenv "PATH") ":/usr/local/bin"))
(setq exec-path (append exec-path '("/usr/local/bin"))))
+1 @bpiel. I open GUI emacs through a desktop entry I created rather than through terminal so my emacs doesn't inherit the PATH constructed through my terminal's interactive non-login shell (which read startup files like ~/.bashrc).
When you run M-x fzf you're executing fzf in a non-interactive, non-login sh shell which will not read any configuration files. I was confused at first because running M-! fzf --version worked while M-x fzf failed, but that's because M-! uses my default shell (zsh) which still reads /etc/zshenv and ~/.zshenv even for non-interactive, non-login shells.
One thought I had was to have fzf.el use the user's default shell, or add the switch -l (for login shell behavior) to sh, as to read the ~/.profile configuration file...But idk if that'd be that helpful. Probably just better to display an error with a suggested fix.
I am using bash and I had a similar problem (fzf command not found). I just create a symlink from the fzf bin to /usr/bin and it is working
sudo ln -s ~/.fzf/bin/fzf /usr/bin/fzf
I added code that issue a user-error when fzf/executable is not found on PATH: https://github.com/bling/fzf.el/pull/88 to address that.
I don't think adding explicit logic in the package to magically appending to Emacs PATH should be done, or at least not unless it's controlled by customization. Anyway, it's always possible to modify the value of the fzf/executable user-option to place an absolute path to the executable.
