backtick metacharacter confused by scrolly wheel in vim

[Ed Dench]

I really like to use
escape ``
so that I may send the command character without using a control key.

This unfortunately breaks when I use the scroll wheel in vim.  Naturally, I
tell vim I'm using an xterm... instead of screen.  [.vimrc] ttymouse=xterm2

When I use the scroll wheel, many times it is interereted by screen as
commands, and all hell breaks lose as let loose many meta-characters /
screen commands.

AFAIK, the trouble only happens within vim and with an up scroll.  If I
have a xterm scrollback buffer I am able to scroll up and down without a
problem.  If I use control-V in vim to indicate the character pressed, some
times I get a ^[[M` output.  Notice the last character is the backtick and
that I often get different output (e.g., ^[[M.  ).

My working theory is that  screen receives a "button-4" press from a scroll
up as an escape sequence which includes "normal keys" including a backtick.
(Blame xdefaults? or X's general behavior?).

Any body else have ideas?  Any solution?   Should this really go to an X
list?

Here's more of my thought process.  I have read quite a bit, but am still
lacking, yadda... here's WHAT I THINK HAPPENS.  The remote xterm process
connects to my local x-server (xwin32). My local X server displays the
application and accepts keyboard/mouse input devices; these are relayed to
the remote process.  (Xwin32 reserves the right to make a translation, but
uses standard us.xkb and wheel as buttons).  The scroll wheel is sent as
button-4 and button-5 (as http://colas.nahaboo.net/mouse-wheel-scroll/
suggests and program xev confirms). The xterm process receives the input
and reserves the right to interpret input; and it will do so in part by
using .Xdefaults to determine how to translate an input to a command local
program.  E.g., XTerm*vt100*translations: #override\n\ <Btn5Down>:
scroll-forw(1,halfpage) \n\

The xterm process passes most input on the shell or command running.  In
most cases, the shell takes that input parses it, executes it, and echos it
to the associated tty.  In the case of screen, it acts as the command
running, and so it can take the input and pass it on however it likes.
Usually it just passes it on to the shell or process, but if a meta
character is detected it will alter screen behavior.  In addition, I think
screen does some translation on keycodes that come across like the ones
from the NUMPAD.  When vim executes with mouse=a and ttymouse=xterm2, vim
interepets <Btn4Down> as <MouseDown> and executes 3^Y (scroll up 3).  When
screen sits in-between, it normally receives and passes a button-5
(scrollwheel down), but it appears screen clobbers the scroll wheel up
<Btn4Down> by interpretting it as a command.

The main problem with this theory, is that screen operates fine when vim is
not running!


Thanks,
Ed Dench