Re: Keyboard configurability

[Jiri Mencak <spambox centrum cz>]

On Tue, Sep 24, 2002 at 12:28:26PM -0400, Pavel Roskin wrote:
> First of all, your message has date in UNIX format, not in RFC format.  
> Please fix or update your mail program.
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... 
My first posting was rejected because I didn't add "To:" field to the 
body of my email. So as to prevent another rejection, I also added 
the date field...

> slrn-0.9.7.4, file src/help.c:
> 
>    N_("  > Move to end of the article."),
>    N_("  <                  Move to beginning of the article."),
>    N_("  LEFT               Pan article to the left."),
>    N_("  RIGHT              Pan article to the right."),
>    N_("  /                  Search forward in the article."),
>    N_("  TAB                Skip beyond quoted text."),
>    N_("  g                  Skip to next digest."),
> 
> Key names and descriptions are combined into strings, and those strings
> are translated into many languages.  If somebody wants to redefine keys,
> at least the help won't change.  Doesn't sound flexible to me.
Somebody who redefines his/her own keys usually doesn't need help.
I don't use slrn that much. It probably wasn't the best example. Take 
a look at JED.

> 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~").

Here is an example taken from my `keydefs.sl':
variable Key_F1		= setkey_via_terminfo ("k1",	"^[[11~");

> In fact, I was going to do almost the opposite.  Every key will be
> considered as a combination of the input escape sequence and the keyboard
> modifier.  This would allow us to support keys like Ctrl-PgUp even on
> terminals that send the same sequence for PgUp and Ctrl-PgUp (konsole,
> gnome-terminal).  
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...).

> Unfortunately, reliance on keyboard modifiers is hard to
> eliminate if even such sinle things as Shift-Arrows are desired.
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");

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). I suppose that you can call "hardcoding" 
escape sequences in Midnight Commander what I have in mind. But in my 
opinion it is better to "hardcode" them in this way and leave 
redefinition up to users, than not being able to use effectively both 
MC and JED on the Linux console. Escape seqences of ioctls. What is 
more portable/configurable?

> 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. 

> I hope you will find time to clarify your suggestion.
I sure do. Sorry for such a long email. I hope that I clarified my 
suggestion a bit.

Regards,

Jiri