3

Is is possible to use <ScrollWheelUp> and <ScrollWheelDown> while the auto-complete popup is open? I tried using the map

inoremap <expr> <ScrollWheelUp> pumvisible() ? "<Up>" : "<Esc><ScrollWheelUp>"
inoremap <expr> <ScrollWheelDown> pumvisible() ? "<Down>" : "<Esc><ScrollWheelDown>"

or alternatively,

inoremap <expr> <ScrollWheelUp> pumvisible() ? "<C-p>" : "<Esc><ScrollWheelUp>"
inoremap <expr> <ScrollWheelDown> pumvisible() ? "<C-n>" : "<Esc><ScrollWheelDown>"

which is supposed to conditionally change the insert-mode behavior of the scroll wheel, but instead some weird random text like [<65;20;15M] is inserted when I use the scroll wheel on an open popup menu with either of the above maps.

0

1 Answer 1

5
+50

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.

3
  • Thanks! Turns out the problem was I had been using the map inoremap <expr> <Esc> pumvisible() ? "<C-e"> : "<Esc>", which would keep insert-mode on upon pressing escape if the popup was visible. Surprisingly, even the simple remap inoremap <Esc> <Esc>l (preserve cursor location) causes the above scrollwheel mapping to fail. Do you have any idea why insert-mode <Esc> mapping would prohibit my above remap?
    – Luke Davis
    Feb 18, 2017 at 5:09
  • 1
    @LukeDavis I added some speculation to the post.
    – Tommy A
    Feb 18, 2017 at 7:03
  • Past Me: "Do you have any idea why insert-mode <Esc> mapping would prohibit my above remap?". I figured out the answer to this question 1 year later in this thread. Yay, I guess. @TommyA I think I skimmed your answer at the time/it went over my head, but now I understand.
    – Luke Davis
    Feb 6, 2018 at 3:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.