[Top][All Lists]

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

Re: wide characters in perl ncurses wrapper

From: Thomas Dickey
Subject: Re: wide characters in perl ncurses wrapper
Date: Wed, 6 Jun 2007 07:10:29 -0400 (EDT)

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


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.

Martin von Gagern

Thomas E. Dickey

reply via email to

[Prev in Thread] Current Thread [Next in Thread]