Keyboard configurability

[Pavel Roskin]

> I do apologise. Thanks for your advice. I updated my brain and will 
> keep this in mind next time I do `telnet mail.gnome.org 25'. I 
> usually don't do this. It is just a precausion against spammers not 
> to reveal my real email address I'm now revealing now... 

He who fears something gives it power over him.
        - Arab Proverb

> > What are terminal strings?  I don't understand your suggestion.  I hope
> > you don't mean hardcoding input escape sequences for all terminals.
> Sorry. Bad terminology on my part. I mean escape sequences. What I had 
> in mind was to use similar system to handle keyboard as JED. JED uses 
> S-Lang function setkey_via_terminfo() to recognise keys. Basically, 
> setkey_via_terminfo() checks your terminal database. If it finds an 
> escape sequence corresponding to a capability code (e.g. "k1") in your 
> terminal database, it uses it. If it doesn't, it uses the `hardcoded'
> (e.g. "^[[11~").

That's how mc works, except that "Learn Keys" is limited to most common 
key combinations, which should be fixed.

> I don't use konsole and gnome-terminal. I use xterm and my escape 
> sequences for Ctrl-PgUp and PgUp have to be different for a window 
> where I run JED, and have to be the same for a window where I run 
> MC (because of ioctls...).

First of all, a little correction - ioctls are used on Linux console.  
Under X, the modifiers are read using XQueryPointer() function, and only
if X support is enabled (--with-tm-x-support).

> Of course Shift-Arrows are desired. 
> 
> variable Key_Shift_Up	= setkey_via_terminfo ("", "\e[a");
> variable Key_Shift_Down	= setkey_via_terminfo ("", "\e[b");
> variable Key_Shift_Right= setkey_via_terminfo ("%i", "\e[c");
> variable Key_Shift_Left	= setkey_via_terminfo ("#4", "\e[d");

. From my .mc/ini:

[terminal:rxvt]
left=\e[d
right=\e[c
up=\e[a
down=\e[b

I added this by hand.  Those definition don't override definitions for
arrows without shift.  There is no need to make sequences of Shift-Left
and Left keys the same.  You can have more than one sequence for the same
key.

As a side note, perhaps it better to reverse the strings to indicate that
it's the sequence that is unique, not the key:

"\e[D"=left   # Left
"\e[d"=left   # rxvt Shift-Left
"\e[2D"=left  # xterm Shift-Left

> What is my problem? X is fine. I can assign different escape sequences 
> to keys to an X terminal I run MC in and JED in. However, you can't do 
> that on a Linux console. You assign escape sequence to all of your 
> Linux terminals. Then, you get conflicts between programmes that use 
> ioctls to get keyboard modifiers (e.g. MC) and programmes that rely on 
> escape sequences (e.g. JED).

This trick should work on the console too.  I know, it's not intuitive.

> > On the other hand, rxvt and xterm already distinguish those keys, so maybe
> > we can simply extend the "Learn Keys" dialog and make it more reliable (so
> > that nobody could e.g. assign the same sequence to PgUp and Ctrl-PgUp).
> You hit the nail on the head here. That would be nice. I just don't 
> like those ioctls for judging whether a modifier was pressed. 

You are confusing two issues here.  ioctls are useful because without them
users would be forced to redefine their keymaps.  It may be OK for you,
but not for an average user, who has no time to tweak every program.

On the other hand, using ioctls are the sole means to tell Shift-Left from
Left is wrong.  I'd rather have this in my .mc/ini:

[terminal:rxvt]
shift-left=\e[d
shift-right=\e[c
shift-up=\e[a
shift-down=\e[b

I think I'll add it if it's not very hard.  As for the GUI, I don't know.  
There are too many little nuances that are hard to represent on screen
without confusing some users.

I even remember a user reporting that the keypad plus cannot be learned 
even though it worked already!

If I put those shifted keys to mc.lib, power-users like you will find
them, and they will work at least on some popular terminals by default, 
even without X support.  That should be a good first step.

-- 
Regards,
Pavel Roskin