Re: curses vs non-ASCII

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>>> [...] I am somewhat surprised if netbsd-4 really behaved like that
>> It does in my tests.  [...]
> Please make sure we are talking about the same things.  It seems like
> old curses simply throw whatever it got onto the screen.

That's the impression I got too.  Conveniently - at least, conveniently
for me in this particular case - that produces the behaviour I want.

> Terminals are not supposed to print something for non-printable
> characters, it is arguably a bug if they do.

However, treating them as printable in curses is probably wrong,
because after printing one curses will have an incorrect idea of the
cursor position - especially if the character printed is taken as
something akin to a control character by the terminal.

Presumably things like this are why curses grew i18n awareness, and in
general that's probably a Good Thing - but when it's this hard to get
the old behaviour back, I consider it to have gone too far.

>>>> [...], 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 [something like this happen].  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.  [...will try to reproduce it...]
> Just trying to rule out accidently setting UTF8, which would show
> this kind of behavior...

Yes, UTF-8 was the first thing I thought of when I saw the behaviour
too.  I didn't investigate in great detail; I was more concerned with
making it go away than I was with exploring the envelope of the
behaviour.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B