I'm working with a terminal emulator, and want to send the right key presses/escape sequences to vim, so it inteprets them as the left/right scroll wheel buttons.

64/65 works for up/down:

<ScrollWheelUp>   printf("\033[<%d;%d;%d", 64, row, col)
<ScrollWheelDown> printf("\033[<%d;%d;%d", 65, row, col)

But what does vim expect for left/right scroll wheel buttons? I've tried 66/67 and 62...

Is it a different style of sequence altogether? I might need to delve into the vim source.

I guess I could just make up a code, and then map it within vim... but I'd like to follow the standard.

Is there a way to make vim tell you what a symbol like <ScrollWheelLeft> represents?

  • Correct me if im wrong, but isnt this more terminal-dependent than vim-dependent?
    – D. Ben Knoble
    Commented Jul 28, 2018 at 14:48
  • I know very little about this - could you elaborate please? Commented Jul 29, 2018 at 4:15
  • Left/right scroll is probably not a standard button, so it's up to the terminal emulator to send a custom escape sequence. Depending on the terminal emulator it could even change, making a single configuration for Vim impossible.
    – Spidey
    Commented Jul 29, 2018 at 12:29
  • @Spidey Yes, it seems non-standard. But I recall vim responding to left/right scroll wheel presses, so it must be recieving it somehow... the GUI is hardwired (mapping MOUSE_6 and MOUSE_7 to KE_MOUSELEFT and KE_MOUSERIGHT in gui.c). And the help mentions making up your own escape sequences for xterm-mouse-wheel. So maybe that's all there is. Commented Jul 30, 2018 at 1:16

2 Answers 2


As the commenters have already pointed out, the escape sequences used can vary depending on your configuration, but these key codes can be set and queried by the :set command.

The following command will output what Vim is currently expecting your terminal to send for <ScrollWheelLeft>:

:set <ScrollWheelLeft>?

See :help terminal-options for more details.

  • Thanks, this is great to know about, but unfortunately <ScrollWheelLeft> is not set. Further, even though up/down mouse wheel scrolling does work, <ScrollWheelUp> and <ScrollWheelDown> are also not set... E846: Key code not set (I checked this with both set ttymouse=xterm and set ttymouse=sgr.) Do you find you vim outputs an escape sequence for up/down scroll wheel events? Commented Jul 31, 2018 at 5:49

The only place in vim source code where the internal int constants for left and right mouse scroll wheel events (KE_MOUSELEFT and KE_MOUSERIGHT) are set is for the GUI (gui.c). Specifically: the code for xterm never produces these events.

BTW: Out of interest, the xterm code does produce mouse scroll wheel up/down events (KE_MOUSEUP, KE_MOUSEDOWN). It is a little difficult to follow in the source, because of all the preprocessor conditionals, but for SGR DECSET 1006, I already know the code for up/down is 64/65 (hex 40/41 - does not appear in vim source). Vim adds 32 (hex 20), then later tests for => hex 60, to interpret wheel_code as a wheel_code. Finally, it produces KE_MOUSEUP or KE_MOUSEDOWN by masking for the lowest bit. (term.c:5739).

I haven't traced this up/down event for other terminal settings (e.g. set ttymouse=xterm also works), but the code looks like to handles many inputs in this section (it converts concrete mouse events into an internal standard of psuedo-mouse events, and then works with that).

It would be nice for vim to extend the standards with escape codes for left/right scroll wheel events, but it looks like it wouldn't fit neatly into the present code base (perhaps needing an extra variable).

Motivation: It's useful for vim on phones (using terminal-ide or termux) with limited screen size. Turn off onscreen keyboard to double the available screen. Then rotate device to portrait mode to increases the number of lines, and turn off line wrapping (:set nowrap) to increase the number of lines much further. Most lines will fit on the screen... but viewing long lines is where a touch screen swipe (sending a horizontal mouse scroll wheel event) comes in handy, because it doesn't require the on-screen keyboard. It's possible that over time, viewing code on smartphones may become more common.

Your Answer

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

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