FZF plugin sometimes not responding to typing #927

bsander · 2020-01-08T14:01:42Z

I have read through https://github.com/junegunn/fzf.vim/blob/master/README.md
I have read through https://github.com/junegunn/fzf/blob/master/README-VIM.md
I have read through the manual page of fzf (man fzf)
I have searched through the existing issues

Sometimes after opening FZF with the Files or Rg command, fzf is not responding to anything I type. Pressing Escape generates a keycode instead, and I have to C-c to exit the buffer. Retrying the same command immediately after usually results in FZF functioning perfectly fine. But apart from that, this issue appears to happen quite randomly.

Don't know what other relevant info I can provide at this stage, please let me know 🙂

The text was updated successfully, but these errors were encountered:

junegunn · 2020-01-09T07:09:50Z

I haven't had the issue. Is it reproducible with the minimal config shown in the issue template?

daogilvie · 2020-01-21T19:01:17Z

Hi @junegunn; thanks for maintaining fzf and this plugin, I'm really enjoying using them both!
That said, unfortunately I am experiencing the same issue as bsander, but it is not random — it happens to me in pretty much every invocation of Rg and Ag, but not of Files.

This does happen with the minimal config. I am on Catalina 10.15.2, using NVIM v0.4.3. There are no error messages in :messages, and I can't see anything that looks obvious when I run with -V9 logging (but I don't really know what I would be looking for).

Please let me know how I can help narrow this down.

Addendum

2 things:

If I type some characters and press enter, the results are reloaded with matches, but my cursor also moves down a row and I can no longer delete the characters I just typed no matter how hard I try.
It seems to be happening when it completes enumerating the files for the initial search. I tried all of the variations of the Rg command you suggest in the documentation, including https://github.com/junegunn/fzf.vim#example-advanced-ripgrep-integration, but nothing has made any difference.
It doesn't matter if I call Rg with or without arguments — once the initial list of results is complete. If I do the command on big folder trees, though, I am indeed able to use keyboard inputs as expected whilst it is still collecting results together.

Addendum 2

~~Seems to be working fine after restarting laptop a couple of times and downloading latest update via plug (thank you for that also) as of 15 minutes ago. Will update this issue if I see it again.~~

daogilvie · 2020-01-23T12:05:16Z

It keeps recurring. If you think of any useful information for debugging, let me know.

xp-bar · 2020-01-23T14:52:30Z

I've been having this problem for a while - haven't been able to find any information out there on it - this is actually the first issue I've found.

My setup is basically:

alacritty @ 0.4.0
tmux @ 3.0a
neovim @ 0.4.2

nvim install info

NVIM v0.4.2 Build type: Release LuaJIT 2.0.5 Compilation: /usr/local/Homebrew/Library/Homebrew/shims/mac/super/clang -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNDEBUG -DMIN_LOG_LEVEL=3 -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -I/tmp/neovim-20190916-88369-176iaxs/neovim-0.4.2/build/config -I/tmp/neovim-20190916-88369-176iaxs/neovim-0.4.2/src -I/usr/local/include -I/tmp/neovim-20190916-88369-176iaxs/neovim-0.4.2/deps-build/include -I/usr/local/opt/gettext/include -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include -I/tmp/neovim-20190916-88369-176iaxs/neovim-0.4.2/build/src/nvim/auto -I/tmp/neovim-20190916-88369-176iaxs/neovim-0.4.2/build/include Compiled by brew@Mojave-2.local Features: +acl +iconv +tui See ":help feature-compile" system vimrc file: "$VIM/sysinit.vim" fall-back for $VIM: "/usr/local/Cellar/neovim/0.4.2/share/nvim"

Run :checkhealth for more info

it seems all the fzf.vim commands randomly stop accepting input - even though the command is clearly running / not frozen (the file number is ticking up, neovim itself isn't frozen). The cli command will also sometimes hang in the same manner - but no prompt appears (vs. in nvim, where the files list shows up fine, but it doesn't accept any input)

When using tmux, I have noticed is that closing out that (tmux) window completely seems to solve the issue - but opening and closing neovim within the same (tmux) window / split doesn't seem to resolve the issue.

heliostatic · 2020-01-29T21:43:20Z

I have the same setup as you @xp-bar -- tmux definitely exacerbates the issue, as I have a 100% repro with rg / fzf#vim#grep in tmux.

heliostatic · 2020-01-29T21:49:38Z

@junegunn I have a consistent repro with the minimal vimrc:

Edit: Better recording

heliostatic · 2020-01-30T14:35:52Z

Update: I was too impatient -- the file actually does open after ~40 seconds.

heliostatic · 2020-01-30T14:53:49Z

Last update I think:
No repro under iTerm. Just Alacritty + Tmux for me. I'll file a bug in the Alacritty repo.

heliostatic · 2020-01-30T20:13:25Z

Hmm, I can now repro under Terminal.app and iTerm, no tmux session.

Here's a debug log showing the issue: debug.txt

I used the minimal .vimrc but added verbose logging level 12:

set nocompatible hidden laststatus=2

set verbose=12
set verbosefile=debug.txt

if !filereadable('/tmp/plug.vim')
  silent !curl --insecure -fLo /tmp/plug.vim
    \ https://raw.githubusercontent.com/junegunn/vim-plug/master/plug.vim
endif

source /tmp/plug.vim
call plug#begin('/tmp/plugged')
Plug 'junegunn/fzf', { 'do': './install --bin' }
Plug 'junegunn/fzf.vim'
call plug#end()

autocmd VimEnter * PlugClean! | PlugUpdate --sync

sethfowler · 2020-01-31T20:27:22Z

It's unsurprising, since it's based on neovim, but FWIW I experience this issue frequently with VimR v0.31.0-337 as well.

daogilvie · 2020-02-03T16:39:04Z

Update

I have found that leaving the Rg results buffer open for 30s then closing with Ctrl-C does then make it work as expected (i.e responds to input as expected). It also then works straight away in new Vim sessions and terminals after doing this. ~~I will try to have a look in some more detailed logs and see what might be happening.~~ At a loss. I will unsubscribe from this issue as I'm no longer being affected by it without a workaround.

xp-bar · 2020-02-04T14:30:02Z

^ I still have this issue occasionally (about once a day, closing tmux window resolves it), so I'll do what I can to post any relevant info here

Speaking of relevant info, I have no idea where to start - haven't ever debugged anything like this before. Any specific log files I should be watching / submitting?

Revert the change introduced in #552. It seems that the startup time difference between bash and fish is not much of an issue now. > time bash -c 'date' Thu Feb 13 21:15:03 KST 2020 real 0m0.008s user 0m0.003s sys 0m0.003s > time fish -c 'date' Thu Feb 13 21:15:05 KST 2020 real 0m0.014s user 0m0.007s sys 0m0.006s When we explicitly *pipe* $FZF_DEFAULT_COMMAND instead of making fzf internally start the process ($FZF_DEFAULT_COMMAND | fzf), fzf may hang if the input process doesn't quickly process SIGPIPE and abort. Also, fzf#vim#grep temporarily swaps $FZF_DEFAULT_COMMAND instead of setting 'sink' so fzf can kill the default command on 'reload'. junegunn/fzf.vim#927 However, because of the "pipe conversion", the trick wasn't working as expected. https://github.com/junegunn/fzf.vim/blob/467c3277884240f7b5430f8f4d600e3415c38f3b/autoload/fzf/vim.vim#L720-L726 We can go even further and always set $FZF_DEFAULT_COMMAND instead of piping source command.

junegunn · 2020-02-13T12:22:09Z

Hi, please test if junegunn/fzf@5e1db9f fixes the issue.

heliostatic · 2020-02-13T14:20:39Z

Hi, please test if junegunn/fzf@5e1db9f fixes the issue.

Just installed from master and it appears the issue is resolved by junegunn/fzf@5e1db9f

heliostatic mentioned this issue Jan 30, 2020

Slow file operation in tmux session on macOS alacritty/alacritty#3267

Closed

junegunn closed this as completed Feb 14, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

FZF plugin sometimes not responding to typing #927

FZF plugin sometimes not responding to typing #927

bsander commented Jan 8, 2020

junegunn commented Jan 9, 2020

daogilvie commented Jan 21, 2020 •

edited

Loading

daogilvie commented Jan 23, 2020

xp-bar commented Jan 23, 2020

heliostatic commented Jan 29, 2020

heliostatic commented Jan 29, 2020 •

edited

Loading

heliostatic commented Jan 30, 2020

heliostatic commented Jan 30, 2020

heliostatic commented Jan 30, 2020

sethfowler commented Jan 31, 2020

daogilvie commented Feb 3, 2020 •

edited

Loading

xp-bar commented Feb 4, 2020

junegunn commented Feb 13, 2020

heliostatic commented Feb 13, 2020

FZF plugin sometimes not responding to typing #927

FZF plugin sometimes not responding to typing #927

Comments

bsander commented Jan 8, 2020

junegunn commented Jan 9, 2020

daogilvie commented Jan 21, 2020 • edited Loading

Addendum

Addendum 2

daogilvie commented Jan 23, 2020

xp-bar commented Jan 23, 2020

heliostatic commented Jan 29, 2020

heliostatic commented Jan 29, 2020 • edited Loading

heliostatic commented Jan 30, 2020

heliostatic commented Jan 30, 2020

heliostatic commented Jan 30, 2020

sethfowler commented Jan 31, 2020

daogilvie commented Feb 3, 2020 • edited Loading

Update

xp-bar commented Feb 4, 2020

junegunn commented Feb 13, 2020

heliostatic commented Feb 13, 2020

daogilvie commented Jan 21, 2020 •

edited

Loading

heliostatic commented Jan 29, 2020 •

edited

Loading

daogilvie commented Feb 3, 2020 •

edited

Loading