help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: arrow keys in the console


From: Tyler Smith
Subject: Re: arrow keys in the console
Date: 19 May 2007 03:14:18 GMT
User-agent: slrn/0.9.8.1pl1 (Debian)

On 2007-05-19, Tim X <timx@nospam.dev.null> wrote:
> Tyler Smith <tyler.smith@mail.mcgill.ca> writes:
>
>> On Fri, May 18, 2007 at 04:00:30PM +0200, Peter Dyballa wrote:
>>> 
>>> Am 18.05.2007 um 14:16 schrieb Tyler Smith:
>>> 
>>> >echo $TERM now shows: linux. How do I find out what it should be?
>>> 
>>> tset - -Q or such can determine the right value. It also would work  
>>> to set it xterm or xterm-color. This kind of terminal is supported by  
>>> GNU Emacs. Look into lisp/term directory!
>>> 
>>
>> Thanks! Setting TERM=xterm seems to have fixed it!
>>
>
> This is likely to cause you all sorts of 'weird' issues. In particular, it 
> will
> almost certainly screw up some terminal programs, which will now think they 
> are
> running under an X terminal with all that implies re: keycodes and modifiers,
> mouse and cutting/pasting, colour mappings etc. Some programs will use the 
> TERM
> setting to work out what environment they are running under to determine what
> features to load or make available. Having this set to xterm will confuse 
> these
> programs. 
>
> The correct solution is to load the right keymap. You can even setup a keymap
> so that additional keys, like the 'windows' keys are mapped to something like
> 'super' or 'hyper', which gives you a whole new set of modifiers to take
> advantage of. You can also redefine keys, such as swapping caps lock and
> control, which some people like because its easier on the fingers etc. 
>
> Part of the reason that its a bad idea to just 'fool' the system by setting
> TERM to xterm when running under the Linux text console is because normally, X
> has a translation layer that affects the values seen by programs when a key is
> pressed. The Linux console doesn't use the same scheme (mainly because it
> pre-dates a lot of the 'extended' keyborad functionality and because much of
> that functionality has no applicability in a text console). The extent to 
> which
> any of this has any impact depends on where/how the program is geting its
> values. Any programs that use very low level functions to process keyboard
> input are likely to behave weirdly with an incorrect TERM setting. Part of 
> this
> is because the TERM setting essentially points to a database that describes 
> the
> capabilities of the terminal your running under. While there is a lot of
> similarity between the Linux console and an xterm, they are not the same - for
> one thing, you cannot resize a Linux console. You are also likely to see
> probems if you use ssh to connect to a remote server as this server will be
> told that yo are running from an X term and will assume you have X 
> capabilities etc.
>
> In short, while it may appear to be working, its likely to have subtle
> side-effects and is technically incorrect. The correct solution is to set the
> correct keymap.
>
> Tim
>

Thanks for the detailed explanation. I've tried working through
dumpkeys and loadkeys. It's a bit dense for me, but I'll keep at
it. In the meantime I'll probably spend most of my time in emacs under
X, where I get predictable behaviour from my keyboard.

Cheers,

Tyler



reply via email to

[Prev in Thread] Current Thread [Next in Thread]