I just upgraded my local xterm to patch #264, and found that I couldn't
use <shift> with button-1 to do xterm selections any more (I alternate
between vim selection (I use 'mouse=a') and xterm-selection depending upon
what I want to achieve, like, I suspect, many others).
Unfortunately, <Shift-Btn1> is now scrolling the vim page up by a few
lines :-/
I think this is down to a 'fix' in xterm #263: "modify handling of
any-event/any-button mouse protocol; it now is active with any combination
of key-modifiers."
Oddly, <Ctrl-Btn1> on the xterm does still bring up its menu.
Before I spend ages reading xterm's button.c to see if I can work around
this, does anyone know anything about this?
I've never really looked into xterm's mouse-reporting modes in any great
detail.
FWIW, if I type ':<Ctrl-V>' in vim, then click to see what raw codes are
generated, I see:
^[[M ?? .. btn1, xterm#227 [variable ??]
^[[M ?? .. btn1, xterm#264
^[[M$?? .. btn1+shift, xterm#264
--
[n...@fnx ~]# rm -f .signature
[n...@fnx ~]# ls -l .signature
ls: .signature: No such file or directory
[n...@fnx ~]# exit
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
