Subject: Re: [Summer of Code]Wide character support for curses
To: Ruibiao Qiu <ruibiao@arl.wustl.edu>
From: Thomas Dickey <dickey@radix.net>
List: tech-userlevel
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.

no problem.
 
> 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).
	http://invisible-island.net/dialog/

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

no problem.

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