Your examples work fine for me on Vim 7.4.1689 and Neovim.
The following didn't work at first:
set mouse=a
Then I read the following in :h 'mouse'
Enable the use of the mouse. Only works for certain terminals
(xterm, MS-DOS, Win32 |win32-mouse|, QNX pterm, *BSD console with
sysmouse and Linux console with gpm).
I use tmux a lot, so $TERM
is set to tmux-256color
. Since Vim doesn't see xterm
in the name, I get no mouse support. With the following:
set term=xterm-256color
I was able to scroll in the popup menu with the mouse wheel.
I found an old server to test Vim 7.4.52. It exhibited the problem you mentioned about it inserting text instead of scrolling. It turns out that the issue was with an old map that I had setup:
inoremap <nowait> <esc> <esc>
Removing this map caused the mouse wheel to work correctly in insert mode and I was able to scroll through completions.
I can't tell you the exact reason this causes a problem, but I can offer some speculation. If you run:
:echo strtrans(expand("\<ScrollWheelDown>"))
You might see something like <80><fd>K
. The first two bytes identifies <ScrollWheelDown>
as K_SPECIAL
(0x80) + KS_EXTRA
(0xfd) + K
(I assume is the scroll direction). In Vim, these are defined in keymap.h
:
/*
* K_SPECIAL is the first byte of a special key code and is always followed by
* two bytes.
* The second byte can have any value. ASCII is used for normal termcap
* entries, 0x80 and higher for special keys, see below.
* The third byte is guaranteed to be between 0x02 and 0x7f.
*/
#define K_SPECIAL (0x80)
...
/*
* KS_EXTRA is used for keys that have no termcap name
* K_SPECIAL KS_EXTRA KE_xxx
*/
#define KS_EXTRA 253
<80><fd>K
is Vim's internal representation of <ScrollWheelDown>
. Your terminal is sending the mouse interactions to Vim as a CSI (\x1b[
) code. My guess is that Vim eats the \x1b
and translates it to the <esc>
map, breaking the mouse sequence and in turn, causing the remainder of the sequence to be queued as regular keyboard input.