From: jhallen@world.std.com (Joseph H Allen) Subject: Re: 8 bit clean implies what? Date: Sun, 7 Feb 1993 21:25:10 GMT
In article <DAVIS.93Feb6132229@pacific.mps.ohio-state.edu> davis@pacific.mps.ohio-state.edu (John E. Davis) writes:
>Hi,
>I have a few questions regarding the meaning of 8 bit clean editors.
>As I understand it, an editor which is 8 bit clean can display ALL 256
>characters on the output device. That is, the character should not be mapped
>to a displayable representation (i.e., ascii char 1 to two character sequence
>^A). So for example, if character 235 corresponds to the greek letter alpha
>on the output device, an alpha should appear when char 235 is sent. In
>addition, the editor should be able to take ANY 8 bit character form the input
>device and display it. That is, if the input device is capable of sending the
>char 235 (alpha), then the char should be deisplayed as above. Is this
>correct?
Yes. But here's another fly in the ointment: You shouldn't be so
eurocentric... there are apparently versions of vt220s which display two
successive characters as a single chinese or japanese character. So you
need to make a mode where all deletes operate on two characters... (I would
appreciate it if someone would elaborate on this more.. I still need to add
this mode to my editor JOE. I don't understand yet if the character set is
broken into half-charatcers which fit together or if the first character is
really a prefix character).
>On my PC, the char 255 do not display anything on the screen (just a space).
>255 is also -1 when converted to signed char and usually denoted end of file
>or something special like that. Is it just a coincidence that 255 displays
>nothing on my PC or is this a general feature? Should I make any assumptions
>regarding 255? I would like to reserve it for my own purposes.
Nope, can't do that. Some international character sets use 255. Originally
I tried to make all of the 'chars' in JOE 'unsigned chars' so that when a
character was returned in an 'int' the range was 0 - 255 instead of -128 -
127. That way -1 could still be an error return. The only problem is that
stupid ANSI compilers give bazillions of warnings (it's bad enough they give
warning for 'char *' being mixed with 'const char *', but char/unsigned-char
warnings are rediculous. I hate ANSI-C. I wish it would go away. (stupid
catering to the IBM PC..)). Anyway, I now use MAXINT (defined as 2^31-1 or
32767) for error returns and have characters in the range of -128 to 127.
You still need to cast them to unsigned sometimes (for table lookup), but
not very often.
I've decided that 'unsigned' as a C keyword is close to useless because of
the compatibility problems, so I now avoid it as much as possible.
>Finally, are characters with the hi bit set (>= 128) ever involved in keymaps?
>This might seem like a silly question but for my purposes, it is the most
>important question. I tend to think of keymaps as involving only 7 bit chars,
>e.g., escape map. But is any known case of a keymap where the prefix character
>has the high bit set?
True gnu-emacs keyboards are supposed to have a Meta- key, which sets the
high bit. In Linux, there is a mode which makes the ALT- key the Meta-
key...
>In case you are wondering, I am working on an editor (JED). Recently, I
>released version 0.80 which I thought to be 8 bit clean, but in retrospect, it
>is not. I hear people say ``Just treat ALL characters the same!''. However, I
>am concerned with memory usage on PCs and I would like to cut corners wherever
>I can.
:-) Software virtual memory...
> Berfore I release the next version (0.81), I want to make SURE that I
>get the 8 bit thing correct.
JED is neat. The extension language looks like reverse-polish LISP, but
without parenthasis.
--
/* jhallen@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}