Unfortunate interaction between tmux splits and nvim input/rpc calls

[expipiplus1]

If fzf.vim opens a tmux split or popup, nvim is locked until that split is dealt with.

By locked I mean:

• nvim can't process user input
• nvim can't respond to RPC calls

Specifically this impacts coc-fzf, in that it uses a python script making an RPC call to nvim to populate the fzf buffer. The rpc call over the socket hangs, and no results are shown.

Not being able to process input is not the end of the world (after all, there's a big popup in the way), but not being able to populate the input to fzf is an issue.

I would guess that it's stuck in here: https://github.com/junegunn/fzf/blob/94999101e358385f3ca67a6ec9512f549196b802/plugin/fzf.vim#L717. I honestly have no idea if this is a simple one line change, or if it would require wobbling the whole of nvim's ui loop.

To reproduce:

• run nvim with fzf.vim in a tmux session
• run let g:fzf_layout = { 'tmux': '-r50%' }
• make a call to fzf
• Observe that while the tmux split is open, nvim is frozen

To reproduce the rpc hang (untested):

• run nvim with fzf.vim in a tmux session
• run let g:fzf_layout = { 'tmux': '-r50%' }
• make a call to fzf with the buffer populated by the following python script
• observe that the fzf popup is never populated with something

from pynvim import attach
import sys
nvim = attach('socket', path=sys.argv[0])
nvim.command("echo hello")
print("something")

---

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

[expipiplus1]

Possibly behind https://github.com/junegunn/fzf.vim/issues/1295

[expipiplus1]

Ah, if I switch command here (https://github.com/junegunn/fzf/blob/94999101e358385f3ca67a6ec9512f549196b802/plugin/fzf.vim#L717) to jobstart then I get the expected contents in the fzf popup. (although obviously this doesn't allow capturing the results). jobwait([jobstart(command)]) sadly doesn't allow rpc calls to be processed while in jobwait :/ Busy waiting with 0 timeout seems to fail too.

[expipiplus1]

Ah, this seems to work, great!

  let fzf = {}
  let fzf.dict = a:dict
  let fzf.temps = a:temps
  function! fzf.on_exit(job_id, exit_status, event) dict
    call s:pushd(self.dict)
    let lines = s:collect(self.temps)
    call s:callback(self.dict, lines)
  endfunction
  call jobstart(command, fzf)
  return []