Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!haven.umd.edu!umd5.umd.edu!roissy.umd.edu!mark From: mark@roissy.umd.edu (Mark Sienkiewicz) Newsgroups: comp.os.386bsd.questions Subject: Re: XTerm/Key code problems Date: 12 May 1993 14:18:27 GMT Organization: University of Maryland Lines: 66 Message-ID: <1sr0vj$cba@umd5.umd.edu> References: <9313210.1124@mulga.cs.mu.OZ.AU> NNTP-Posting-Host: roissy.umd.edu In article <9313210.1124@mulga.cs.mu.OZ.AU> summer@ee.mu.OZ.AU (Mark Summerfield) writes: >The arrow keys generate events correctly (tested with xev), but for some >reason, xterm seems to be sending pc3 (console) style escape sequences instead >of xterm (or vt100) ones, e.g.: > >Press: right arrow Sends: ^[[C Instead of: ^[OC >Press: left arrow Sends: ^[[D Instead of: ^[OD There are _two_ sets of escape codes sent by arrow keys. There is also an escape sequence that tells the terminal (xterm, vt100, whatever) which kind of escape codes to send. Normally, vi (or other curses applications) are supposed to send the "is" termcap string when they start up. This initializes the terminal, including setting the keypad mode. I've seen cases where the application doesn't send this string, and also where this string doesn't contain the code to set the keypad mode. >This doesn't bother tcsh in the slightest for some reason, but it does bother It probably recognizes the not-application-keypad-mode escape sequences. >are not erased by ^U, for example. Running Kermit in an Xterm is fine >(which is what I'm doing here) -- key codes reach the remote host correctly >translated such that I can have the terminal type set to xterm, and it all >works OK. The termcap entry for xterm on this host is standard (and >identical to that on the 386bsd machine). This makes me suspect that it is the vi clone failing to send the initialization string. When you run kermit, the other computer sends it and your xterm sets itself into application-keypad-mode. If this is what is really happening, you can do one of two things: fix elvis or change your termcap entry to show :ku=\E[A:kd=\E[B: etc.. >I'm really confused about how all the key translations, tty operations and >termcap features are supposed to work together. I can think of plenty of >workarounds (changing my xterm termcap entry, changing the xterm key >translations through the X resources), but I shouldn't have to do this. >I just don't understand why it doesn't work! Well, you've got my initial guess why it doesn't work, but let me give you a bit of background: As far as any program you run is concerned, xterm is a terminal. Key translations don't have anything to do with it. Think of them as a way to move the keys around the keyboard, and don't change them until you get more familiar with what is going on. Termcap is just a way to describe your terminal. It's pretty weak as far as function keys go, and it doesn't magically make function keys work--it makes function keys work for an application that wants to work real hard at it. The reason for this is that there are so _many_ different terminal types that you can't even _know_ what the function keys on them are. Many terminals have arrow keys, but they usually have lots of other stuff too. I've used terminals that have function keys F1 through F20 (twenty). I bet there aren't many programs that expect F20 to do anything. :) So some more general advice is this: Don't use the arrow keys. If you learn to use vi or emacs, you don't _need_ the arrow keys or function keys and it won't bother you when they don't work. My experience is they usually don't. Good luck, Mark S.