fzf doesn't open file in normal mode (gvim/windows)

[ghost]

• Category
  • fzf binary
  • fzf-tmux script
  • Key bindings
  • Completion
  • Vim
  • Neovim
  • Etc.
• OS
  • Linux
  • Mac OS X
  • Windows
  • Windows Subsystem for Linux
  • Etc.
• Shell
  • bash
  • zsh
  • fish

Environment: gvim8 patch 1-1358 / windows 10, compiled with +terminal.

The issue: I have always press double <ESC> to exit something unclear to bring to normal mode in vim after select a file to open from fzf. Video demo.

I think terminal didn't exit properly so I asked in vim here. I try to solve the issue by searching through fzf codebase but silly me I can't find anything.

[ghost]

The same result with only fzf plugin enabled:
gvim.exe -u NONE --cmd "set nocp | set rtp+=~/vimfiles/pack/plugins/start/fzf | runtime! plugin/fzf.vim"

[junegunn]

Since gdamore/tcell#159 (#1093 (comment)) is now merged, I'll rebuild Windows binary with the updated tcell and see if it helps.

[junegunn]

I can't reproduce ending up in insert mode, but I do need to press enter again to finish fzf process.

Updating tcell to the latest didn't help

• https://github.com/junegunn/fzf-bin/releases/download/alpha/fzf-0.17.2-alpha-windows_amd64.zip

EDIT: Wait a minute, I might have missed something, let me check again.

[ghost]

It's not actually end up with insert mode but it didn't exit terminal cleanly. Right after open file I can type characters into buffer. Thanks for looking into this issue.

[junegunn]

I have confirmed that the extra-enter problem is fixed with updated tcell. You can download the following alpha binary and test it.

https://github.com/junegunn/fzf-bin/releases/download/alpha/fzf-0.17.2-alpha-windows_amd64.zip

I first built fzf with the latest revision of tcell, but it didn't even run, panicking, so I had to update only to the point where the patch is merged, and all seemed fine.

[ghost]

Thanks. Do you notice that we have a gap between opened buffer and title of it? It keeps the title !cmd.exe for a while before change it to opened file.

If I have this setup in minimal vimrc: autocmd VimEnter * silent! :History<CR>, the issue persist. Means the fix somehow happens after autocmd run.

[janlazo]

After FZF finishes execution on GVim, entering any key reverts the title to what it was before running FZF, or History in your autocmd. It's likely a lazy window update. IIRC, the Vim plugin doesn't modify titlestring or set the term_name in the Vim terminal options.

[ghost]

@janlazo : Is there a way to make it faster to update? Should I open a ticket in vim?
Can you confirm the issue still happens with this setup?
Minimal vimrc:
autocmd VimEnter * silent! :History<CR>

• Run this command in cmd under user directory:
  gvim.exe --cmd "set nocp | set rtp+=~/vimfiles/pack/plugins/start/fzf | runtime! plugin/fzf.vim"
• Open an arbitrary file then type something right after open the file. You'll see that characters put into the file. We expect it should open the file in normal mode.

[janlazo]

call term_start('cmd', {'curwin': v:true, 'term_finish': 'close'})

acts like :terminal ++close and should force the update. It works for me on 8.0.1358.
In the Vim plugin, the exit callback must be updated since ++close doesn't apply to Neovim.

If this doesn't work, try :normal and feed any hjkl movement characters. redraw!

function! fzf.on_exit(id, code, ...)
  if !has('nvim') && has('gui_running')
    redraw!
  endif
endfunction

[ghost]

Thanks, your PR fixed title update issue.
But the issue about normal mode still happens #1169 (comment)

[janlazo]

I can reproduce the normal mode issue with your autocmd but I don't know why it happens.

[ghost]

Thanks, I have to stop invoke :History at vim startup. Hope this issue be fixed soon. If possible please open the issue so someone may has solution for it.

[ghost]

The normal open issue with autocmd persist with version fzf 0.17.3.

[junegunn]

I don't have access to a Windows machine now, so I'm not sure, but does this help?

autocmd VimEnter * silent! :redraw! | History<CR>

And you mean it only happens when you trigger the command on VimEnter event?

[ghost]

Sorry but it doesn't fix the issue.
Yes, I have another map that trigger manually after vim started: nnoremap <silent> <leader>s :History<CR> and it didn't have normal issue, :History also doesn't have normal issue.

[ghost]

I've noticed something that maybe help on this. I can produce a weird behavior happens when issue commands :History or :FZF then press <C-c> two times, it will produce a message:
Type :qa! and press <Enter> to abandon all changes and exit Vim
The expected behavior should be press <C-c> one time and fall back to current buffer.