Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!iuvax!cica!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!uunet!pyrdc!gmu90x!gmuvax2!rauletta
From: rauletta@gmuvax2.gmu.edu (R. J. Auletta)
Newsgroups: comp.windows.x
Subject: Re: xterm/eightBitInput not implemented?
Keywords: Really on stripping the 8th bit from output characters
Message-ID: <1562@gmuvax2.gmu.edu>
Date: 5 Jun 90 22:46:43 GMT
References: <1545@gmuvax2.gmu.edu> <1461@lectroid.sw.stratus.com>
Reply-To: rauletta@gmuvax2.UUCP (R. J. Auletta)
Organization: George Mason Univ. Fairfax, Va.
Lines: 29

In article <1461@lectroid.sw.stratus.com> jberk@pretzel.sw.stratus.com (Joe Berkovitz) writes:
>In article <1545@gmuvax2.gmu.edu>, rauletta@gmuvax2.gmu.edu (R. J.
>Auletta) writes:
>|>I have two questions. First, what exactly is the intent of this
>

>Near as I can tell, the eightBitInput resource determines whether the Meta key
>modifier plus a character code
>	-- causes the 8th bit to turned on (resource = true, the default), or...
>	-- precedes the character with an ESC (resource = false).
>

Whoops! I found what I was looking for and not what I was hunting for!
...eightBitInput says it all does it not, in input.c just where
is belongs.

How about a new resource, sevenBitOutput that strips the 8th bit
before interpreting the character for display along the lines
of my previous postings? Is that a reasonable approach  for dealing
with inappropriate 8 bit characters?

I know a couple of people expressed interest in such a solution. I now 
have what "appears" to be a correct solution of the above idea and I'll
pass along the needed  modifications to those interested.

Sorry about the less than completely thought out previous postings.

--R J Auletta
  rauletta@gmuvax2.gmu.edu