Re: Using mc via telnet

Hi Pavel,

You have given this much more thought than I have, but here are some 
comments that might be useful.

On 20 Sep 2001, at 22:01, Pavel Roskin wrote:
Yes.  "Learn Keys" is just a cheap substitute to making the keys work as
they are described in terminfo and/or termcap.

I don't call it "cheap"!  I call it an EXCELLENT feature!!!
I wish more applications would follow this route.

Incidentally, I have been thinking about it.  It is clear for me that the
terminfo standard doesn't solve all problems present in termcap.  What MC
actually does is an attempt to work around deficiencies of the terminfo
standards, not just "bugs" in the terminfo database.

I'm looking from the terminal emulator developers side and unix is kind of 
foreign to me.  We are experiencing endless problems with our users 
connecting to various applications on various unix types, and there are 
almost always problems with key definitions.
I agree with you 111%! We need a better standard/protocol to link key 
mappings to unix applications.  Some kind of automated protocol to do 
what MC's LearnKeys does, but would also work for applications relying on 
termcap or terminfo (as far as is possible in those databases).
(Is it possible to modify or expand the termcap or terminfo definitions?)
It should also offer a manual LearnKeys mode to allow legacy terminal 
emulators (or telnets not supporting the new protocol) to register their 
The terminfo relies solely on the TERM variable, which is actually not so
reliable.  On my pretty standard RedHat 7.1, both xterm and rxvt set
TERM=xterm by default.  And yet F1 sends "\eOP" on xterm and "\e[11~" on

That means either xterm or rxvt does not adhere to the standard. (Which 
standard? OK - I get the point)
If you want to share the "Learn Keys" code with other applications, it
means establishing a standard.  For a standard to succeed, it must be very
good (or you should have influence of software vendors, which is not the

Is there a way to make proposals to the Linux dev teams?

I think that "Learn Keys" is not sufficient for even MC itself.  Run MC in
xterm and try selecting text in the editor with Shift-arrows.  It doesn't
work?  Now go to "Learn Keys".  The Shift-arrows are not there.  They are
not in terminfo either.
Terminfo is good if you don't want to use your terminal to the maximum
extent possible.  But if you want to use any keys in any combination
allowed by your hardware, terminfo is too restrictive.

The new protocol must be openended in some sense to add key-
combinations as users require them.
I wonder, does terminfo allow one to add custom key names?

What MC is doing now is creating a "better terminfo" with support for
multiple sequences per key, new keys combinations and support for data
from the sources other than the terminal (X11 events, linux specific
Another solution would be creating a new terminal client-server protocol
and designing both the terminal (a reference terminal) and the screen
library in the same time.  I believe it's a much cleaner approach.

Yes, it is.  But much more difficult to introduce due to the incompatibility 
with legacy s/w.

The application (i.e. the screen library it's linked with) could send
request to the terminal.  Not just the name of the terminal, but the
properties - number of keys, number of screen buffers (xterm has two),
state of the modifiers.  It would be very useful to request the cursor
position, e.g. after sending some Japanese characters, that can be more
than one character wide, without the client knowing anything about
Japanese alphabet.

Functional keys could be sent in plaintext (escaped, of course), and the
level of detalization could be negotiated, e.g. the client could prefer
"Alt-Enter" over "Right Alt-Keypad Enter".

All the terminal functionality could be build into existing terminals,
e.g. rxvt.  A special sequence would just put the terminal into the new
client-server mode.

I think it's a much better idea than sharing half-baked "Learn Keys"
functionality with other applications.  It may even be easier to do than
to implement the "better terminfo" with optional support for X events and
Linux ioctl.  And yet it won't use X at all - why open another connection
if one is already open?

Pavel Roskin

Ferdi             :-)
Ferdi Louw               Internet:ferdi gpvno co za
INET web/ftp site:
Tel.   +27(12)803-6501(work)     +27(83)287-5735(cel)
       +27(12)803-4131(fax)      +27(12)80-432-68(home)
S-mail: GP van Niekerk Ondernemings, 211 Roos Street, 
        Meyerspark, 0184, Pretoria, South Africa
Private: 505 Graniet Street, Silverton, 0184, Pretoria
Do you believe in love at first sight, or should I drive by again?

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