Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Currently GNU screen will botch up certain keystrokes, for example CTRL pressed in combination with the arrow keys, so that eg when in vim insert mode, CTRL-PGUp will Uppercase the next/current word (or something like that). I'd like for it to work pretty much transparently, so that the functionality is the same as when it's not running (with the obvious exception of CTRL-a control sequences)... is this possible?

Also — and I suspect this is more or less a separate issue — I'd like for the scrollwheel to scroll back in the session log rather than cycling through the history as it does now. Doable? Or perhaps it could be set to emulate a much larger screen size that the terminal app that it's running under could keep that text in its session log. either way the goal would be to be able to use the mouse wheel and/or shift-up-arrow to scroll back in the session log.

share|improve this question
    
What are you running Screen in? This will completely determine what effect the scroll wheel, Ctrl-<button>, etc. has. –  Teddy Dec 19 '09 at 17:34
    
It seems to be the same behaviour in various terminal apps: konsole, gnome-terminal, roxterm. –  intuited Dec 20 '09 at 5:07

3 Answers 3

You can change the default keystrokes in screen, but you will encounter the same kind of problems, just with other keystrokes. Byobu makes it easier to setup the basic keystrokes for screen. In byobu, the cycling back in session log with the mouse wheel is activated, too, so you could either use it or see how it's set in /usr/share/byobu/profiles/common.

share|improve this answer
    
What's the underlying issue with this? Why does a key combo like CTRL-PgUp not work the same when vim is running under screen as when it is? Is screen thinking that part of the keycode sequence is a screen command key? Byobu sounds neat but I'm not sure I get what it is.. I gather that it lets you switch between profiles which basically consist of a screenrc .. but what sort of thing would you designate a particular profile for? I guess I'm asking how you use this app. –  intuited Dec 21 '09 at 0:19
    
Byobu was formerly known as screen-profiles, and this is what it is. It's a wrapper around screen which helps you configure it must more easily, because screen is very hard to configure properly. –  ℝaphink Dec 21 '09 at 7:21

For scrollwheel, you want this in your ~/.screenrc:

# scrollback by inhibiting switching to terminal emulator's alternate screen
termcapinfo xterm*|rxvt*|kterm*|Eterm*|putty ti@:te@
# then turn on alternate windows within screen
altscreen on

For the cursor key stuff, this depends on how accurate your terminal emulation is, for the claimed terminal type in the window where you invoke screen, so it can do its mapping properly. Many terminal emulators claim, via $TERM, to be "xterm". But they're not and they don't emulate nearly enough of xterm to rightly claim that. Often, dropping down to claiming something like vt220 has been enough to improve things for me, but I don't recall the situation with screen -- I just use xterm itself. There are various torture tests you can run to see how bad your terminal emulator is at pretending to be xterm when it isn't.

To fix things up after-the-fact, use the bindkey screen command. It's documented in screen(1), and if you use ^A: (or whatever you map screen's escape to, if not ^A (I use ^])) then you can type ^A:bindkey -d to see the current map.

share|improve this answer
    
hmm.. even running xterm I get the same issues with CTRL-PgUp, when running under screen. Though your mention of $TERM clued me in a bit: Something in screen's config -- I guess it is the default, it's not listed in /etc/screenrc -- sets TERM=screen for screen sessions. If, after starting screen, I set TERM=xterm and then do $(tput init), this seem to work 'normally', at least with CTRL-combos. Presumably screen sets TERM=screen for a reason... any idea what the downside of changing it back to xterm would be? –  intuited Dec 21 '09 at 14:08
    
hmm.. there were paragraphs in that..... ....Also I don't think it's a conflict with ^A. At a command prompt, typing CTRL-PgUp will always -- under any permutation of screen/whichever terminal emulator/whichever TERM value -- cause 5~ to be printed. In Vim, normally (non-screen or re-tput\ init-ed) these characters are magically translated into a :tabprev command, however it seems that under screen they just get interpreted the same way as at the command prompt: upon closer inspection I realized that it's actually case-shifting the next 5 characters. –  intuited Dec 21 '09 at 14:14
    
Wow.. not only is that directive pretty obscure but it broke detection of my terminal width. Guess I'll stick it out with 'copy mode' scrolling for now. –  intuited Dec 22 '09 at 2:01

Not ideal, but you can put this in your .vimrc as an immediate fix:

nmap <ESC>[5;5~ <C-PageUp>
nmap <ESC>[6;5~ <C-PageDown>

Sourced from this bug report.

Alternatively, you can tell vim to change its recognition of PgUp/PgDn:

set t_kN=<ESC>[6;*~
set t_kP=<ESC>[5;*~

The former is nicer, in ways, because it means your PgUp/PgDn still work outside of screen.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.