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? :-)

> For instance assembling multibyte/multicolumn characters can be a
> problem

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 
handle.

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

Ruibiao