Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!leah!rpi!crdgw1!sungod!davidsen
From: davidsen@sungod.crd.ge.com (ody)
Newsgroups: comp.emacs
Subject: Re: MicroEMACS 3.10 bugs, fixes and a MAJOR improvement to file completion
Keywords: uEMACS 3.10
Message-ID: <1699@crdgw1.crd.ge.com>
Date: 16 Aug 89 13:32:33 GMT
References: <234@insyte.UUCP> <9847@j.cc.purdue.edu> <1675@crdgw1.crd.ge.com> <9852@j.cc.purdue.edu>
Sender: news@crdgw1.crd.ge.com
Reply-To: davidsen@crdos1.UUCP (bill davidsen)
Organization: General Electric Corp. R&D, Schenectady, NY
Lines: 25

In article <9852@j.cc.purdue.edu> nwd@j.cc.purdue.edu (Daniel Lawrence) writes:

| 	How about a comprimise here....  let the TCAP module scan for the
| termcap entries, and if a particular escape sequence is not in the termcap,
| use some standard translation rule... perhaps mapping it into the ALT area?
| Then the termcap keys will always be bound to the standard, machine
| independant bindings, and all the unusual  sequences generated on some
| TTYs can still be used.

  I'm not sure that's compromise, since all parties get everything they
ever wanted, but I like it! That's the perfect solution. I assume that
if I don't add any functions to the termcap everything will come
through, allowing use of my existing macro file, then I can gradually
add function key defs to my termcap after the macro files are updated.

| 
| 			Daniel Lawrence  voice: (317) 742-5153
| 					  arpa:	dan@midas.mgmt.purdue.edu
| 				The Programmer's Room 
| 				Fido: 1:201/10 - (317) 742-5533


	bill davidsen		(davidsen@crdos1.crd.GE.COM)
  {uunet | philabs}!crdgw1!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me