Open myitcv opened 4 years ago
@junegunn any thoughts on what might be going on here?
I've tried unsuccessfully to create a minimal repro in Vim alone, which suggests to me that there is something going on with fzf
.
My minimal repro with fzf
is as follows:
cd $(mktemp -d)
export HOME=$PWD
curl -fLo ~/.vim/autoload/plug.vim --create-dirs https://raw.githubusercontent.com/junegunn/vim-plug/master/plug.vim
cat <<EOD > .vimrc
call plug#begin('~/.vim/plugged')
Plug 'junegunn/fzf'
Plug 'junegunn/fzf.vim'
call plug#end()
EOD
Then open Vim and:
:PlugUpdate
Then:
:call fzf#vim#files(".")
At the prompt that then appears type
asdf<C-u>
Notice that nothing happens after the <C-u>
(whereas I would have expected the asdf
to have been erased backwards.
Then hit <BackSpace>
and notice the following at the prompt:
./asdf;5;117
i.e. the <C-u>
is incorrectly interpreted.
For the record, this is with Vim 8.2 using xterm
I can't reproduce the problem on Vim 8.2 with the minimal config on macOS. Do you have the same issue when running fzf outside Vim?
Thanks for the quick response.
I can't reproduce the problem on Vim 8.2 with the minimal config on macOS.
As I mention above, I think this is an xterm
issue, related to the recent changes around :help modifyOtherKeys
. Hence I suspect you'll need Linux to reproduce this (which should be doable via Docker?)
Do you have the same issue when running fzf outside Vim?
No, everything works fine outside of Vim.
As I mention above, the issue disappears if I set the following in my .vimrc
:
let &t_TI = ""
let &t_TE = ""
Which I think helps to confirm this as a problem in the interaction between Vim, modifyOtherKeys
and fzf
. But that's only my limited understanding and a process of elimination 😄
Incidentally, if there's any debugging I can do on my system here to help please let me know. Very happy to help.
Thanks for your workaround @myitcv ! Just wanted to add that running FZF fullscreen, e.g. :GFiles!
doesn't have this issue, which surprised me.
I confirm this is an xterm-vim issue. Here's my config if it's any help:
vimrc:
set rtp+=~/.vim/plugged/fzf,~/.vim/plugged/fzf.vim
fzf 079046863c0a9f5bc37d629bab02dccffcf329bc fzf.vim d4d36b412bdc53e8bdaf0e2714a2227f51781d68
The keybinds with Ctrl+* print escape sequences (in the form ";5;###~).
Works with rxvt-unicode (urxvt) v9.22 - released: 2016-01-23
($TERM: rxvt-unicode-256color
).
Broken both on xterm-351 and xterm-353 ($TERM: both xterm
and xterm-256color
)
EDIT: The workaround from @myitcv fixes the issue
@dkjii-g thanks for the additional data points.
Just to point out that whilst my workaround does indeed fix the immediate issue, it means that the user cannot take advantage of the benefits of :help modifyOtherKeys
. i.e. <C-[>
and <C-S-{>
are indistinguishable (for example).
I'm guessing (emphasis on the word guess there) that fzf
(or a library that it uses) does not understand how to interpret the special escape keys that are coming through when modifyOtherKeys
is turned on, in exactly the same way that bash
(and whatever library it uses) does not:
# enable modifyOtherKeys
$ echo -e "\033[>4;2m"
$ fzf
Then within fzf
typing a word, e.g. main
:
> main
then <C-W>
leaves main
untouched, when it should have deleted a word backwards.
Then hitting backspace gives
> main;5;119~\
So whether it's possible for fzf
to disable modifyOtherKeys
for the time it's using the terminal then restore the previous state perhaps?
fzf version: dceb5d09cdb0d3158a3f79e59eb3c16ffe242d6b fzf.vim version: bce6588d2422df75ca0091edac48aa9f87f163e5 Vim version:
Per https://groups.google.com/d/msg/vim_dev/d0gi0UT3bfw/aGMspiODAwAJ I'm seeing some issues using fzf with Vim version
v8.1.2194
and later.Specifically I'm seeing issues using, and within fzf. I get control sequences printed to the screen instead of the clearing the line, previous and next elements respectively.
The only setup that works for me is to disable this feature via:
Creating this issue here in order to get your expertise whilst investigating (because I can't honestly say I know much about what fzf is doing here)
cc @brammool