rauletta@gmuvax2.gmu.edu (R. J. Auletta) (06/03/90)
The X11R4/Fix11 xterm manual describes a resource eightBitInput.
I have two questions. First, what exactly is the intent of this
resource. Does it cause extended characters not to be displayed
or does it strip the 8th bit so that the 7 bit code is displayed?
Secondly, is this resource implemented? A very brief scan through
the code seems to indicate that the resource has no effect on the
action of xterm.
Here is my dirty little hack. I assume there is a better place
to do the masking of the 8th bit? As there be dragons here I'm
also worried about unseen interactions and performance issues.
In the file charproc.c in the function dotext at about line
1241 add the following code to case 'B':
case 'B': /* ASCII set */
if(screen->eight_bits == 0)
{
for (s=buf; s<ptr; ++s)
*s &= 0177 ; /* Mask the 8th bit */
/* to map all characters */
/* into the range 0X00 to 0X7F */
}
break;
I also feel the default for this resource should be false.
To change this modify line 327 in charproc.c to,
{XtNeightBitInput, XtCEightBitInput, XtRBoolean, sizeof(Boolean),
XtOffset(XtermWidget, screen.eight_bits),
XtRBoolean, (caddr_t) &defaultFALSE},
^^^^^^^^^^^^^
Suggestions, comments, and the correct solution would be most appreciated.
--Rich Auletta
rauletta@gmuvax2.gmu.edurauletta@gmuvax2.gmu.edu (R. J. Auletta) (06/04/90)
In article <1545@gmuvax2.gmu.edu> rauletta@gmuvax2.gmu.edu (R. J. Auletta) writes: > >The X11R4/Fix11 xterm manual describes a resource eightBitInput. > >Here is my dirty little hack. I assume there is a better place ......Which does not handle non-printing characters correctly. A better hack for just the VT100 window is to make the following changes to charproc.c in VTparse: switch ( parsestate[ c = screen->eight_bits ? doinput() : 0x7f & doinput() ]) { case CASE_PRINT: /* printable characters */ top = bcnt > TEXT_BUF_SIZE ? TEXT_BUF_SIZE : bcnt; cp = bptr; *--bptr = c; while(top > 0 && isprint(*cp & 0x7f)) { if(screen->eight_bits == 0) *cp &= 0x7f; top--; bcnt--; cp++; } I assume a similar change could be made to the Tek window. As always suggestions, comments, or the correct solution would be greatly appreciated. BTW, has anyone noticed that when xterm is built with gcc.1.36, calling up the tek window causes a bus error? --Rich Auletta rauletta@gmuvax2.gmu.edu
mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (06/04/90)
>> The X11R4/Fix11 xterm manual describes a resource eightBitInput. >> Here is my dirty little hack. > ......Which does not handle non-printing characters correctly. Depends on your notion of "correctly". If I told it to disable 8-bitness, I would expect the 0x80 bit to be stripped from every byte coming up the pty, including nonprinting characters and those forming escape sequences. > BTW, has anyone noticed that when xterm is built with gcc.1.36, > calling up the tek window causes a bus error? This is due to calling some routine (CopyISOLatin1Lowered, I think it's called) asking it to copy into a string literal. Compile with -fwritable-strings, that's a quick patch-around. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
jberk@pretzel.sw.stratus.com (Joe Berkovitz) (06/05/90)
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 |>resource. Does it cause extended characters not to be displayed |>or does it strip the 8th bit so that the 7 bit code is displayed? |> 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). I set the resource to false because I prefer using the Meta key to hitting an ESC prefix. This is the way pre-R4 xterm behaved. |>I also feel the default for this resource should be false. I second that! Joe Berkovitz jberk@pretzel.sw.stratus.com
rauletta@gmuvax2.gmu.edu (R. J. Auletta) (06/06/90)
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