Your examples work fine for me on Vim 7.4.1689 and Neovim.
The following didn't work at first:
Then I read the following in
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:
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:
You might see something like
<80><fd>K. The first two bytes identifies
K_SPECIAL (0x80) +
KS_EXTRA (0xfd) +
K (I assume is the scroll direction). In Vim, these are defined in
* 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.