Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!bbn!jr@bbn.com
From: jr@bbn.com (John Robinson)
Newsgroups: comp.emacs
Subject: Re: Grrr... uEmacs 3.10 doesn't work under Xenix
Keywords: uEMACS 3.10
Message-ID: <38635@bbn.COM>
Date: 13 Apr 89 17:52:01 GMT
References: <56344@yale-celray.yale.UUCP> <9313@j.cc.purdue.edu> <13576@steinmetz.ge.com> <588@ispi.UUCP> <56803@yale-celray.yale.UUCP>
Sender: news@bbn.COM
Reply-To: jr@bbn.com (John Robinson)
Organization: BBN Systems and Technologies Corporation, Cambridge MA
Lines: 68
In-reply-to: spolsky-joel@CS.YALE.EDU (Joel Spolsky)

In article <56803@yale-celray.yale.UUCP>, spolsky-joel@CS (Joel Spolsky) writes:
>In article <588@ispi.UUCP> jbayer@ispi.UUCP (Jonathan Bayer) writes:
>>In article <13576@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes:
>>>  I think we may have failed to make it clear that support for ANSI
>>>keysequences is needed in UNIX versions. Termcap support won't do it. I
>>>posted fixes for this in every version from 3.7? to 3.10beta and none of
>>>them ever got picked up.
>>
>>Why?  What is the matter with reading the termcap entry and interpreting
>>the keys according to the termcap info?  
>
>Jonathan, I'm going to have to come out against this one. TERMCAP was
>never a good solution to keyboard problems. VERY FEW terminals are
>correctly set up in standard /etc/termcap files, even if they were,
>uEmacs 3.10 wants to use non-standard termcap entries for home, end,
>pgdown, etc.  There is no question that TERMCAP is not robust enough
>or well enough support for keyboards, especially in Xenix.

[...]

>>I have been able to make version 3.10 work with all the
>>keys on my keyboard by simply installing the appropriate modification to
>>my termcap file.
>
>Humph. I don't see why every poor joe slob that wants to use
>microEmacs should have to (1) figure out that his function keys dont
>work (2) find the source to uEmacs, (3) find that obscure comment in
>tcap.c about the termcap (4) change the /etc/termcap file.

I have to vote with Jonathan and (implicitly) Dan Lawrence here.  If
ANSI is standard enough (is it?  if not, then the built-in driver was
a compromise already), then why not simply distribute the ansi termcap
entry that uemacs wants to see to everyone, preferably with the
distribution.  Then users will get their ansi support without mucking
in the source or recompiling or getting a new distribution.  Are those
really easier than getting /etc/termcap changed?  I think rather the
opposite.

If users at a site want the better termcap(s) put into their local
copy, then they can pressure their site admin.  But there is always
the workaround - set your TERMCAP variable yourself.  This is
available to every user of uemacs now, without debugging new source or
waiting for a new distribution or buthering Dan.

Jonathan, could you post your termcap here?  Along with easy
instructions on how to set up $TERMCAP...  If it isn't "ansi", maybe
also a cookbook on how to modify it toward ansi-ness if you're able.

>Essentially, as most Unix develpers have figured out, TERMCAP is NEVER a
>realiable place to look for keyboard information. Especially in Xenix
>where many users don't even set up or use the TERMCAP env. variable at all.

And the more software out that there that avoids termcap, the more it
will atrophy.  The original concept is good.  Let's debug and enhance
termcap, not every screen-oriented program individually!

>A more reasonable solution, and the one that GNU Emacs uses, is to
>make it simple and reasonable to bind functions to the ANSI sequences,
>instead of the unnecessary uEmacs step of binding to hypothetical key
>names like FN< and FN>.

It's a separable issue how easy it is to rebind control sequences.
This idea sounds good independent of what happens with termcap. The
rebinding code iss much more generally useful than an ansi driver.
--
/jr
jr@bbn.com or bbn!jr
C'mon big money!