Re: wide characters in perl ncurses wrapper

[Thomas Dickey]

On Wed, 6 Jun 2007, Martin von Gagern wrote:

> Hello!
>
> This is not exactly a bug, more a list question.
> Why are there two versions of the library, ncurses and ncursesw?
> Is there any reason not to link against ncursesw?
> What makes them binary incompatible while staying source compatible?

Some of the data structures which are necessarily visible in the header 
files are different.  Simple applications (such as this one, perhaps) 
could in principle be linked with either library.

> The other day I encountered problems with the perl wrapper around
> ncurses, being because that only uses ncurses, not ncursesw. I filed a
> report about it: http://rt.cpan.org/Ticket/Display.html?id=27335

I see...

> Now the Perl Curses dev states that there being two libraries was an
> indication that ncursesw should not be used by default. Do you agree?

probably not: programs that cannot be easily configured to work with any 
particular instance of nominally compatible libraries are in need of some 
maintenance.   Looking at Curses-1.15, for example, I note that all of the 
hints directory could be done better by an autoconf-style configure 
script which checks for features.

The perl curses wrapper doesn't go very deep, does not for instance seem 
to use any wide-character code (though I do see a few ncurses extensions 
such as wresize - but no KEY_REZIZE).

The package description indicates that the package maintainer doesn't do 
development, however.  If you have an improvement for it, he indicates 
that he will incorporate it.

(It would be nice if I had time to maintain the wrappers for perl, ruby, 
python and other languages ;-).

> It would be great if you could help clarify the matter. UTF-8 locales
> are gaining ground, and having a UTF-8 capable wrapper for curses seems
> important to me. It would be nice if this could become the default.
>
> Greetins,
> Martin von Gagern

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net