Subject: Re: [Summer of Code]Wide character support for curses
To: Ruibiao Qiu <firstname.lastname@example.org>
From: Thomas Dickey <email@example.com>
Date: 06/26/2005 17:56:43
On Sun, Jun 26, 2005 at 04:50:59PM -0500, Ruibiao Qiu wrote:
> Mr. Dickey,
> Thanks for your quick response.
> On Sun, 26 Jun 2005, Thomas Dickey wrote:
> >actually ncurses works on more platforms (with essentially the same
> >functionality on each).
> I guess replacing the NetBSD curses libraries entirely with ncurses (as in
> OpenBSD) is not a decision I can make :-) (But, on the other hand, Brett
> and Julian, could this be an option? :-)
( I doubt that would happen ;-)
> >Another complication which occurs to me at the moment is that most
> >applications would prefer reading a wide character.
> I will look more into some multi-column character input method applications
> (such as cxterm or xcin) to find out how they feed the encoding of wide
> characters to a terminal, and what does getchar() return. Thanks for
> bringing it up.
I'm not sure how many _curses_ applications read wide character data.
I modified dialog to do this, making it build against either narrow-
or wide-character curses. That seems to work fine in xterm (uxterm),
using cut/paste (input methods are something I've done little with).
I've also been modifying lynx to do the same (but that's not as complete -
there are lots of complicated details to keep the other configurations
> >I'm interested in the smaller- and faster-metrics...
> >I'd suggest a simple file-viewer
> >Multibyte input could be added to that (e.g., a search command using
> >winnstr to fetch data from the display). Testing it with data that has
> >nonspacing characters and data that uses double-width characters would
> >exercise the waddch() logic.
> It sounds like a good plan. Thanks.
Thomas E. Dickey