Subject: Re: [Summer of Code]Wide character support for curses
To: Thomas Dickey <email@example.com>
From: Ruibiao Qiu <firstname.lastname@example.org>
Date: 06/26/2005 16:50:59
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? :-)
> For instance assembling multibyte/multicolumn characters can be a
Thanks for pointing this out. waddch() definitely must be rewritten
carefully. It is currently just a wrapper of waddbyte().
>> I did look into the input routines, but I thought there is no major changes
>> needed there. It uses getchar() to get input characters from input, does
> not getchar(), but getch()
I meant that getchar() is ultimately called inside wgetch() (or inkey() to be
more precise). Sorry about the confusion.
> true - but it also has to know about some of the internals of waddch()
> (or the latter has to be smarter), since the intermediate display as
> bytes are accumulated and painted won't be complete.
Indeed, the multi-column character on the edges of a screen is tricky to
> 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
> 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.