Vim Scroll Wheel Problem

[Jeff Bisbee]

Love mintty, but having a problem with TERM=xterm and vim.

On my windows machine if I edit a file with vim an scroll the mouse up
I get 'a' and a newline inserted and when I scroll down I get a
'b'/newline. When I change my TERM to 'linux' the problem goes away,
but then vim does not set the filename in the title. I'm curious if
this is a bug or if there is something I can put in my
.bashrc/.inputrc/.vimrc to fix it.

Thanks, Jeff

Jeff Bisbee / jbi...@gmail.com

[Jeff Bisbee]

Correction its three a or b plus newlines per scroll wheel 'tick'

Jeff Bisbee / jbi...@gmail.com

[Andy Koppe]

Jeff Bisbee wrote:
> > Love mintty, but having a problem with TERM=xterm and vim.
>
> > On my windows machine if I edit a file with vim an scroll the mouse up
> > I get 'a' and a newline inserted and when I scroll down I get a
> > 'b'/newline.  When I change my TERM to 'linux' the problem goes away,
> > but then vim does not set the filename in the title. I'm curious if
> > this is a bug or if there is something I can put in my
> > .bashrc/.inputrc/.vimrc to fix it.

> Correction its three a or b plus newlines per scroll wheel 'tick'

This is MinTTY's feature for supporting mousewheel scrolling outside
"application mouse mode". Here's the relevant bit from the manual:

Mousewheel
In xterm mouse reporting modes, the mousewheel is treated is a
pair of
mouse buttons. However, the mousewheel can also be used for
scrolling
in applications such as less that do not support xterm mouse
reporting
but that do use the alternate screen. Under those
circumstances,
mousewheel events are encoded as follows:

line up ^[Oa
line down ^[Ob
page up ^[[1;2a
page down ^[[1;2b

The number of line up/down events sent per mousewheel notch
depends on
the relevant Windows setting on the Wheel tab of the Mouse
control
panel. Page up/down codes can be sent by holding down Shift
while
scrolling. The Windows wheel setting can also be set to always
scroll
by a whole screen at a time.


For vim, you've got three options, each shown with the
necessary .vimrc settings:

1) Enable application mouse mode:
set mouse=a

2) Add appropriate mappings for the mousewheel keycodes, e.g.:
map <Esc>Oa <C-Y>
map <Esc>Ob <C-E>
map <Esc>[1;2a <PageUp>
map <Esc>[1;2b <PageDown>
map! <Esc>Oa <C-X><C-Y>
map! <Esc>Ob <C-X><C-E>
map! <Esc>[1;2a <PageUp>
map! <Esc>[1;2b <PageDown>

(Does anyone know better mappings for insert mode? <C-X><C-Y> and <C-
X><C-E> don't allow scrolling off the current page.)

3) Just ignore the mousewheel:
map <Esc>Oa <Nop>
map <Esc>Ob <Nop>
map <Esc>[1;2a <Nop>
map <Esc>[1;2b <Nop>
map! <Esc>Oa <Nop>
map! <Esc>Ob <Nop>
map! <Esc>[1;2a <Nop>
map! <Esc>[1;2b <Nop>


So obviously 1) is the most straightforward, and it also enables other
mouse features in vim, e.g. placing the cursor and marking text. The
only disadvantage of that is that you can't select and copy stuff to
the clipboard as usual. Instead, you need to hold down Shift to
override application mouse mode.

Andy

[Jeff Bisbee]

On Tue, Aug 11, 2009 at 4:10 PM, Andy Koppe<andy....@gmail.com> wrote:
> So obviously 1) is the most straightforward, and it also enables other
> mouse features in vim, e.g. placing the cursor and marking text. The
> only disadvantage of that is that you can't select and copy stuff to
> the clipboard as usual. Instead, you need to hold down Shift to
> override application mouse mode.

You are the man. I opted for option 2. It allows me to scroll
through my buffer without borking cut and paste as you suggested. I
still have one question though. Why when I set my TERM to 'linux'
does the mouse wheel scroll the bash buffer? I actually use that
something to look a prior command's output or something. I think I do
like the vim buffer scrolling better so kudos to you for pointing out
the vimrc options, but I'd also like to understand what's going on.

-Jeff

[Andy Koppe]

On Aug 11, 9:30 pm, Jeff Bisbee wrote:
> Why when I set my TERM to 'linux'
> does the mouse wheel scroll the bash buffer?

It's because in that case vim doesn't switch to the "alternate
screen", which the Linux console doesn't support. Hence it's using the
normal screen that's also used by bash and where the mousewheel
scrolls the scrollback buffer.

(Btw, setting TERM to a value that doesn't fit your terminal generally
is not a good idea, because you'll likely get missing and incorrect
key mappings.)

Andy

[Jeff Bisbee]

On Wed, Aug 12, 2009 at 4:44 PM, Andy Koppe<andy....@gmail.com> wrote:
> It's because in that case vim doesn't switch to the "alternate
> screen", which the Linux console doesn't support. Hence it's using the
> normal screen that's also used by bash and where the mousewheel
> scrolls the scrollback buffer.

Actually, thats my original problem. Until other terminal emulations,
mintty does _not_ scrollback the buffer and thats the behavior I
expected.

I have another problem with the .vimrc approach. At work in my dev
environment it works great, but when I go to a production machine (we
have 1000s) and i have to edit a file the darn scroll

a
a
a
a
a
a
b
b
b
b
b
b

hits me again.

Under cygwin, I launch an xserver and then an xterm I don't have the
issue. I scroll back to the buffer as I would expect. So I pose the
question again, could there be a bug?

-Jeff

[Andy Koppe]

No, functions as designed. Designed by a monkey. :)

For some reason I was under the impression that xterm didn't scroll
back into the normal screen buffer when on the alternate screen, but
as you say, it actually does. I think scrolling a fullscreen app off
the screen like that instead of scrolling in the app itself is
illogical and unintuitive, but since this obviously is a matter of
preference, I better bring the PuTTY code for this that I unwisely
removed. (It's labelled "Push erased text into scrollback" there.)

And of course those 'a' and 'b's in default vim are just plain bad. So
here's what I'll do:

1. Add a default-off option: "Enable scrollback on alternate screen"
2. Make the mousewheel send standard cursor key codes when that option
is off. This way, mousewheel scrolling in less should work without any
setup. In an editor that doesn't enable application mouse mode, the
mousewheel will move the cursor, so it will only start scrolling once
it hits the edge of the screen. Not ideal, but certainly an awful lot
better than mysterious characters appearing.
3. Add control sequences for enabling and disabling the current
separate mousewheel keycodes, so that it can still be mapped to proper
scroll commands without enabling full application mouse mode.

(This might not happen for 0.5 though, 'cause I'm concentrating on
catching up with Cygwin 1.7 regarding locales and full Unicode
support.)

Thanks for making me rethink this,
Andy

[Jeff Bisbee]

Andy,

My pleasure. I was a hardcore linux guy, switched to osx
Terminal/xterm, then back to good old windows and was using
xserver/xterm. I was looking all over the place for a friendly
windows term that was easy to launch and played nice with cygwin and
ran across a blog post about mintty.

Thanks for all your hard work. you've put together a great app that I
(and other converts at work) use every day.

Jeff Bisbee / jbi...@gmail.com