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 _______________________________________________ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users
