Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

If I use the following .emacs file, I am able to go to the beginning/end of the current line using the home/end keys as I would expect.

(keyboard-translate ?\C-h ?\C-?)

(add-to-list 'load-path "/home/sam/programs/go/go/misc/emacs/" t)
(require 'go-mode-load)

(global-set-key [kp-home]  'beginning-of-line) ; [Home]
(global-set-key [home]     'beginning-of-line) ; [Home]

(global-set-key [kp-end]  'end-of-line) ; [End]
(global-set-key [end]     'end-of-line) ; [End]

However, if I open up a screen session it does not function like this (the [home] key still brings me to the beginning of the buffer for some reason).

Here is my .screenrc file if anyone can spot anything funky in there:

term xterm
defutf8 on
defflow off
startup_message off

# terminfo and termcap for nice 256 color terminal
# allow bold colors - necessary for some reason
attrcolor b ".I"

# tell screen how to set colors. AB = background, AF=foreground
termcapinfo xterm 'Co#256:AB=\E[48;5;%dm:AF=\E[38;5;%dm'

#use bash as the default login shell
defshell -bash

EDIT: Apparently, using M-x describe-key (as nschum suggested) says that [begin] is getting triggered when I press the home key on my keyboard when running emacs inside screen. When I run emacs outside of screen describe-key refers to [home] as expected. It looks like the "defutf8 on" is the only keyboard-related entry in my .screenrc - is there anything else in there that might be causing issues?

share|improve this question
What does M-x describe-key say? – nschum Jun 27 '11 at 16:48

When you run a program in screen, the screen program can (and will) do this:

  • screen has its own terminal description. It tries to map (convert) the underlying terminal's key sequences into that.
  • The conversion is not complete. As a workaround, screen looks for customized terminal descriptions starting with screen.$TERM. ncurses provides some useful ones.
  • screen filters out (ignores) some key sequences which do not fit into its notion of how input should be done.

Most likely, your problem is in the first case. If you do

infocmp xterm screen

(presuming that you are using the most-often suggested value for TERM, whether or not you are using xterm), you may notice a few lines like this:

kend: '\E[4~', '\EOF'.
khome: '\E[1~', '\EOH'.

The last column is the sequence (\E is the escape character) which screen will send to your program when it receives the middle column from xterm, etc.

The problem with the .screenrc is that it overrides the $TERM value to xterm, confusing screen:

term xterm

You would suppose that the conversion would be complete, but testing shows that it is not. This sort of problem is why ncurses provides customized entries. For example, this entry from ncurses database is the one which takes effect on my machine given that .screenrc setting (because "xterm" is aliased to "xterm-new"):

screen.xterm-xfree86|screen.xterm-new|screen customized for modern xterm,
        bce@, bw,
        invis@, kIC@, kNXT@, kPRV@, meml@, memu@,
        E3@, use=screen+italics, use=screen+fkeys, use=xterm-new,

you may notice the use=screen+fkeys. That says in effect: go ahead and use the keys that screen will use, since it is the simplest workaround. Now there is a subtle problem: screen+fkeys looks like this:

screen+fkeys|function-keys according to screen,
        kend=\E[4~, kf1=\EOP, kf2=\EOQ, kf3=\EOR, kf4=\EOS, kfnd@,
        khome=\E[1~, kslt@,

because (in testing screen), it sent those keys rather than what was in the outer $TERM terminal description. The inner $TERM is set to xterm, but screen uses this intermediate entry when it conveys special keys such as home/end to your session.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .