Re: backtick metacharacter confused by scrolly wheel in vim

[Aaron Griffin]

On 4/10/06, Aaron Griffin <address@hidden> wrote:
> On 4/10/06, Ed Dench <address@hidden> wrote:
> > 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?).
>
> No, terminal emulators of all kinds do not understand buttons (beyond
> the typical X workings - grabbing focus, selecting text, etc).  They
> only receive an escape code, which is well defined (the ^[[M`RC is
> defined in man console_codes and is there for X10 compatiblity).
>
> You have 2 options:
> 1) Don't use a single character - this is the problem with that
> approach.  I used to use \ as an escape character and would get all
> sorts of wonky behavior when pasting ("hello\nthere" would switch
> windows).
> 2) Force your terminal to remap the escape code.  Some may allow this.
>  It may require you to patch the source.
>
> There is no way around this.  Any change is going to be an insane
> amount of hassle.  I'd recommend switching escape keys.
>

For clarification - you mentioned that it works fine when vim is not
running - that is because your shell is not accepting mouse input...

Try the following:
echo -ne "\e[?1000H" #turn mouse reporting on
# scroll mouse
echo -ne "\e[1000L" #turn mouse reporting off
# scroll mouse