Neovim opens in operator pending mode on Windows

[marchollinger]

Checklist

• I have read through the manual page (man fzf)
• I have searched through the existing issues
• For bug reports, I have checked if the bug is reproducible in the latest version of fzf

Output of fzf --version

0.67.0 (2ab923f)

OS

• Linux
• macOS
• Windows
• Etc.

Shell

• bash
• zsh
• fish

Problem / Steps to reproduce

Environment

pwsh version: PowerShell 7.5.4
Operating system: Windows 10.0.26200
Terminal emulator: Windows Terminal Version: 1.23.20211.0
Neovim vesrion: v0.11.6

I found some weird behavior when using become:nvim {} and --height. When I run this command:

fzf --bind "enter:become:vim {}" --height='100%'

Everything works as expected. Neovim opens the selected file in normal mode.

However, if I set --height to anything other than 100%, Neovim opens in operator pending mode and behaves as if I pressed y to yank. Navigating up or down then triggers a yank instead of just moving the cursor.

In the nvim cmdline, y can be seen as if I typed it in normal mode. It also outputs no previous search which is a message from leap.nvim that appears if ; is pressed without a previous search. Somehow, keystrokes are being sent to neovim after opening without me doing anything. If I use nvim --clean then the leap message is not displayed but the y keystroke is still being sent.

Does anyone know what could be causing this? This behavior only occurs in PowerShell, in zsh on Mac or WSL2 everything works fine.

[DanSM-5]

The difference between --height=100% and any other height is the renderer library used underneath. For more context on that issue see #4065 (comment)

I've experienced the exact same issue as you. It is not powershell specific but rather windows specific. At least when I tried in many shells (powershell, pwsh, cmd.exe, bash from git and even zsh using msys package) those were my findings. WSL2 is basically a linux VM and thus it is not affected by the issue.

Setting the codepage to 65001 doesn't fix the problem. This seems unrelated to the encoding but still related to the LightRenderer.
Additionally, it doesn't seem to be just the y that gets sent in neovim. I have an autocommand on VimEnter with g`" to jump to the previous cursor position in the buffer and it always get one line below (not sure if it is similar to you in your recording starting on line three when you use --height=80%). By other hand, vim behaves different. The version from git bash enters in replace mode and the native executable (the one installed with scoop) consumes the first key but I didn't identified why.

I was not able to find a solution when using a --height other than 100%. A workaround is to not use become. At least on my use cases I've always been able to get away by handling the return of fzf and using --expect. You can see my script to search in git commits for ideas. It is more verbose for the most part but you avoid the annoyances.