bug-ncurses
[Top][All Lists]
Advanced

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

Re: form_driver and wide-char


From: Brian Tan
Subject: Re: form_driver and wide-char
Date: Thu, 07 Dec 2006 20:45:42 -0500
User-agent: Thunderbird 1.5.0.8 (Windows/20061025)

Thomas Dickey wrote:
On Thu, Dec 07, 2006 at 11:24:41AM -0500, Brian Tan wrote:
limited success with form_driver() and mbs using getch. Some chars went through correctly into field buffer, while others get clobbered. However, screen update is always garbled. Attached sample program and test data.

I can see two problems.

One is a known limitation (something that could be improved but make it
slower).  ncurses's addch only handles wide characters properly if it's
continuing to update the same cell in a given window.

That's usually not a problem, since most applications complete a wide
character before moving the current position.

Printing the bytes individually in the window as they're read will
cause it to be confused, since the current position changes.

Your test program doesn't happen to be affected, since the form is
in one window, and you're printing bytes to stdscr - but it's something
to watch out for.


The other is something that can be fixed in the test program - moving the
setlocale call before initscr.  Just doing that makes your program work -
for me.

I thought the problem was locale problem. I had setlocale() before initscr() in another test program and it worked. Too much messing around to test out scenarios. :( My bad.
# export LANG=en_US.UTF-8
# gcc -O2 -g testform.c -o testform -lncursesw -lformw
# testform <testform.txt

Char that went through: ??? e5a5bd
Char went bad: ??? e99988

Also field buffer advanced incorrectly after widechar. (gap between '???' and 'a')

Thomas Dickey wrote:
1. field_buffer(); it does not return mbs correctly. For example, wchar 0x597d -> mbs e5a5bd written with set_field_buffer(), screen form updates and shows ?????? " (with trailing space due to strlen=3, I think) but field_buffer() returns c3a5c2a5c2bd, making further wchar entry not possible, unless I keep track of field buffer independently.
This is probably the best place to focus on right now.
The two (I think) are independent
2. form_driver; for not accepting wchar or mbs :)
It's supposed to do the latter - but it's likely that you're better able to see problems. I tested it by select/paste from the UTF-8 scripts in
the dialog package, combined with editing from the keyboard.  At the same
time, my test program would set/get from the field buffer, so I could see mismatches.

So - going back to testing this area, along with some sample data (and locale information from you) would help to reproduce the problem and focus on what's going wrong.

thanks

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.






--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.





reply via email to

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