nvim_command hangs when in 'f' mode

[mkeeter]

• nvim --version: NVIM v0.4.4, Build type: Release, LuaJIT 2.0.5
• vim -u DEFAULTS (version: ) behaves differently? N/A, this is an RPC issue
• Operating system/version: macOS 10.13
• Terminal name/version: iTerm 2, Build 3.3.12beta3, but this is not terminal-dependent
• $TERM: xterm-256color, but this is not terminal-dependent

Steps to reproduce using nvim -u NORC

NVIM_LISTEN_ADDRESS=/tmp/nvim nvim -u NORC

In the Neovim window, press f to enter find mode, but do not type a second character.

In a separate Python shell, with pynvim installed:

from pynvim import attach
nvim = attach('socket', path='/tmp/nvim')
nvim.command('echo "HI"')

Actual behaviour

This will hang the Python shell until you Ctrl-C it, or type another character in the Neovim TUI.

I provided reproduction steps using the Python API, but this is particularly problematic when building a UI that embeds Neovim: it means that you can't ever use blocking nvim_command calls, because they will deadlock if an f search is pending.

Expected behaviour

nvim_command is executed, HI appears in the status line, and the Python shell does not block.

[jamessan]

nvim_get_mode() can be used to determine if nvim is blocking.

See also :help api-fast.

[mkeeter]

Thanks, this lets me work around the issue!

It still seems fundamentally awkward – for example, does this mean it's impossible to resize a window while waiting for the character after f?

[bfredl]

well, you don't need to block the process just because you are waiting for a responce from neovim. In the case of pynvim it uses two threads (because noone has written the "glue" to integrate glib eventloop with asyncio in a single thread), but you could also use whatever async/coroutine abstraction of your language (assuming zig in you case :).

[justinmk]

Is this really a bug or an enhancement? It is expected Nvim in a "pending" state is blocking (except for :help api-fast RPC requests). We did have plans to make Nvim non-blocking under more scenarios.

related #7142

[mkeeter]

I have no real opinion on whether this should be classified as a bug or an enhancement, just found it to be a surprising footgun when writing a GUI!

Also, I just noticed that Vim and Neovim differ, at least in their TUIs: in Vim, if I type f then resize the window, it clears the pending find and resizes right away; in Neovim, it leaves the f staged and doesn't redraw.

[justinmk]

in Vim, if I type f then resize the window, it clears the pending find and resizes right away; in Neovim, it leaves the f staged and doesn't redraw.

Clearing the pending f would be disruptive because any RPC would interrupt a user's pending command. #5685

[justinmk]

This is by design.