I don't use fzf
and use Vim instead of neovim. So I couldn't reproduce your scenario. Also I was not able to reproduce what @dedowsdi described in his comment.(See end of answer.)
But some general stuff around autocmd
and feedkeys
:
Assume we open Vim with three new files in split windows:
vim -O a.txt b.txt c.txt
Vim will open with three windows like this:
+--------------+--------------+--------------+
| 1 | 2 | 3 |
| a.txt | b.txt | c.txt |
| | | |
+--------------+--------------+--------------+
Move to window 2 and execute :au BufEnter <buffer> :call feedkeys('ab.txt', 'n')
and to window 3 and execute :au BufEnter <buffer> :call feedkeys('ac.txt', 'n')
then back to window 1.
We now want to move to window 3 using two times <C-W>l
. To avoid delays with manual input we use:
:normal ^Wl^Wl
(Note: ^W
is entered as <C-V><C-W>
.)
So the input queue is <C-W>l<C-W>l
.
The first <C-W>l
is consumed and the second window is activated. The autocmd kicks in and calls feedkeys
.
Now the input queue is: <C-W>lab.txt
Now the other <C-W>l
is consumed and the third window is activated. Again the autocmd kicks in and calls feedkeys
.
Now the input queue is ab.txtac.txt
.
This is processed and appends the text b.txtac.txt
to the first line and leaves you in insert mode.
Conclusion:
Using feedkeys
is tricky. You should exactly know where you are and what is happening around you. Combined with an autocmd
this is even more tricky.
While your usage of autocmd
is correct from a technical point of view, the combination with feedkeys
might result in unexpected behavior.
Now a test based on the comment from @dedowski (using Vim):
Add an autocmd to 1, move to 3, open a help window, in your case, it
should take full width. exit help window by q, you should see
autocmd of 1 and 3 applied to 3.
Open Vim with three new files:
vim -O a.txt b.txt c.txt
we get:
+--------------+--------------+--------------+
| 1 | 2 | 3 |
| a.txt | b.txt | c.txt |
| | | |
+--------------+--------------+--------------+
Change to the window showing c.txt
and then open help with :help
and we get:
+--------------+--------------+--------------+
| help |
|-----------------------------+--------------|
| 1 | 2 | 3 |
| a.txt | b.txt | c.txt |
+--------------+--------------+--------------+
Now execute:
:autocmd BufEnter * echomsg 'BufEnter ' . expand('%')
Then close the help window using :q
and Vim will print
BufEnter a.txt
BufEnter c.txt
(You might need :messages
to see both echos.)
Well -- that is unexpected.
.
feedkeys
are queued for processing, it doesn't have to be applied to the buffer that triggeredBufEnter
. What really weird here is whyBufEnter
was triggered on1
while your cursor rest on2
after you cancelfzf
. The problem can be reproduced by quitting any side window that takes full width or height.i
to the feedkeys mode? Like:au BufEnter <buffer> :call feedkeys('ahola', 'ni')
.feedkeys()
. In general I wouldn't recommend using this unless you know that you really need it. (as mentioned before, it is queued for processing, so it might not do what you want or when you want it).norm
in a terminal mode.