[Top][All Lists]

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

Re: wide characters, get_wch() and form_driver() - cannot get them worki

From: Thomas Dickey
Subject: Re: wide characters, get_wch() and form_driver() - cannot get them working together.
Date: Tue, 17 Jun 2008 09:57:01 -0400 (EDT)

On Tue, 17 Jun 2008, Adam Spragg wrote:


Having more problems with ncurses and wide character support. Demo
program attached. This has been tested on Debian Unstable with their
ncurses 5.6+20080531-1 packages. I am willing to try installing the
upstream packages if anyone thinks it will make a difference. My LANG
is set to "en_GB.UTF-8", and I'm compiling it with "cc -o wide
wide.c -lformw -lncursesw"

I create a simple form, put it in the middle of the screen and allow the
user to enter characters. I put the results of get_wch() down at the
bottom of the screen, before trying to add the character to the buffer.

If I set the TRY_MULTIBYTE define at the top of the file to 0, run the
program and type "abc??" ('a', 'b', 'c', '??' (pound)) then at the point
where I call "form_driver()" with value 163 (wide character code
for '??') then I get a seg fault. I'm not really expecting this to work
as the ncurses KEY_* codes appear to start at 256, which means that any
unicode characters above that just won't work. But I think a seg fault
is a little harsh.

agree (I'll have to check it on my home machine to see what the problem is). With wide-characters, the KEY_xx codes are only real for the KEY_CODE_YES return - otherwise it's dependent on the locale settings.

If I set TRY_MULITBYTE to 1, rerun and type the same characters, the 163
is converted to a utf-8 multibyte sequence, these characters are then
sent to form_driver() one at a time. Except I get an E_UNKNOWN_COMMAND
(-8) trying to add the first byte. :( The same thing happens if I try
to paste unicode characters in from an x terminal (actually Konsole)

So, uh, how is this supposed to work?

I've looked through the ncurses-intro, ncurses-programming-howto,
hackguide and announce files, as well as the ncurses(7), get_wch(3) and
form_driver(3) man pages and can't see anything that I'm doing wrong.
There doesn't appear to be some kind of form_driver_w() or similar wide
version of the form driver that I should be using instead according to
all the documentation, and a grep of all the header files. A search of
the mailing list archives turns up the following thread:


But I couldn't quite figure out if what the resolution of that was. The
thread just kind of stopped.

The resolution was basically saying that the form library gets compiled to support wide-character mode, and that _it_ knows only about byte-at-a-time adds via addch, but that (with the limitation of not moving the cursor in the middle of the operation), should work.

Behind the scenes, most of the changes between narrow/wide flavors of the
form library are the field-buffer storage.

What the hell am I doing wrong?

Second, and this bit is more of a rant than a serious request for help,
but am I using get_wch() and its return values correctly? Does anyone
have a better way of using it than with multiple switch statements?

I realise that you're just implementing The Open Group's spec here and
aren't responsible for the API design, so I hope I'm not insulting you
when I say that it looks to me like whoever designed it was on some
serious WTF-inducing crack.

Actually Open Group hasn't done anything for form/menu/panel libraries.
Those are from SVr4 "as is", and haven't been touched by any more recent

ncurses adapts those interfaces to wide-characters in the same style as the changes between SVr4 and Open Group (technically X/Open) for the basic library's use of getch/addch.

I _could_ have added a set of wide-character flavored functions,
but so far it's been workable with the byte-at-a-time interface.

For instance, I want Ctrl+H and KEY_BACKSPACE to do exactly the same
thing, but at the moment those bits of code are more than 50 lines
apart. Similarly Ctrl+C and KEY_BREAK. Ditto '\r', '\n' and KEY_ENTER.
Why the fsck are the KEY_* codes not defined outside the usable unicode
range and a single wint_t returned from get_wch() can return any KEY_*
code or a unicode character? Srsly - wtf?!?

Well...(this is Open Group ;-) KEY_xxx values aren't really characters.

What I did in dialog was to fold the Ctrl+H, etc., into KEY_xxx values, (actually mapping to dialog's own equivalents) remembering when there's a KEY_xxx value. That gets it down to a single case statement - not for the form library, but for a similar goal.

Thomas E. Dickey

reply via email to

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