Using mc via telnet

[Ferdi Louw]

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

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

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
> ioctl).
 
> 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?
> 
> -- 
> Regards,
> Pavel Roskin
> 


Ferdi             :-)
-----oooooOOOOOOOooooo-----
Ferdi Louw               Internet:ferdi at gpvno.co.za
INET web/ftp site: http://www.gpvno.co.za/
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
-----oooooOOOOOOOooooo-----
Do you believe in love at first sight, or should I drive by again?