Re: curses vs non-ASCII

[Brett Lymn <blymn%internode.on.net@localhost>]

OK, I have just caught up with this thread and I do find it a little
disconcerting that you claim things are not being looked after when you
didn't get a response for a few days.  I have limited access to my
private emails during the week and at the moment a thing called A Life
is taking precedence to NetBSD hacking so responses are a bit tardier
than they have been in the past.

On Thu, Nov 19, 2015 at 06:12:08PM -0500, Mouse wrote:
> >>> [...] 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.
>

Correct which works fine when you ASSuME that every character thrown at
the screen results in the cursor moving one character cell.  This
totally fails in a couple of cases, one where there are non-spacing
characters which are intended to add diacritical marks to another
character and when the character thrown takes up two (or more) cells on
the screen.  Cursor addressing goes up the wazzoo in these cases.

For the record the HAVE_WCHAR knob was not intended to permit a full
system build with a curses not having wide character support.  The
intention of it was to permit a smaller (both code and memory footprint)
version of curses for constrained situations.  I am not entirely sure
where that would be, I recall initial thinking was sysinst but that
doesn't seem like such a good idea since we would lose the ability to
support wide chars there.  Maybe it should just be removed as an option.

> 
> 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.
> 

Partially, it was done to support multi-cell characters as well.  I
think your difficulty came from being in the C locale but then expecting
8bit characters to work.  As was noted, this isn't really the fault of
libcurses, but more the fact that you were fighting the locale system
and losing.

> >> 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.
> 

At a guess I would say that you have stumbled across a character
sequence that happens to be valid multibyte character but I haven't
looked closely.  What does mbrtowc(3) do with that sequence?

-- 
Brett Lymn
Let go, or be dragged - Zen proverb.