tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: curses vs non-ASCII

>> Well, it surprised me.  It is a regression as compared to 1.4T and
>> 4.0.1, each of which works exactly the way I want here, with 0x80
>> through 0xff all being treated as printables.  (Test program below.)
> Well, that would be a serious bug and I am somewhat surprised if
> netbsd-4 really behaved like that -- it doesn't match any of the
> classic character sets.

It does in my tests.  I no longer have any completely stock 4.0.1
systems, but I did just now check, and none of my local patches affect
lib/libcurses, lib/libc/citrus, or lib/libc/locale.  I have only a few
patches that affect lib/libc at all; none of them look likely to be
relevant here.  (Five touch lib/libc only for manpages,  One adds
_malloc_options.  One spiffs up setmode(3).  Four hack on glob(3).  And
that is the whole list.)

>> However, I do have reason to think mbrtowc is part of the
>> precipitate here; specifically, by default, the 5.2 curses not only
>> drops the non-ASCII octet, but sometimes eats the following octet as
>> well.  Even without any setlocale().
> Test case, please.


I know I saw cases where one ASCII-range character was disappearing,
and it looked to me as though it was always happening immediately
following a non-ASCII character.  But I can't make it happen in a test
program, and I no longer have the source for the version I saw it in.
I'll have to experiment and see if I can recreate it.  If I can build a
test case I'll post it.

>>>> ([...] what I want, which is the 0x80-0x9f octets also being
>>>> treated as single-octet printables.)
>>> But they are not printable in ISO 8859-1, they are control
>>> characters.
>> What I'm trying to use here is a superset of 8859-1, one in which
>> 0x80 through 0xff are all printable - [...]
> I still don't get why you wouold want that. They have no graphical
> representation.

Maybe on your system they don't.  They do on mine, at least with the
correct terminal emulator and configuration.  (One of the simplest
examples I can cite for such things puts line-drawing glyphs in (some
of) those positions.)  The interface I'm trying to build will not, of
course, be usable when displaying somewhere that lacks the expected
graphical representations for the characters it tries to display;
that's known and accepted.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Home | Main Index | Thread Index | Old Index