On 4/10/06, Aaron Griffin <[EMAIL PROTECTED]> wrote:
> On 4/10/06, Ed Dench <[EMAIL PROTECTED]> 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
_______________________________________________
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
