* Martijn van Oosterhout <[EMAIL PROTECTED]> [2008-09-23 11:34:49 CEST]:
> On Mon, Sep 22, 2008 at 03:06:46PM +0200, Gerfried Fuchs wrote:
> > Compiled pal with libncursesw5 so that pal -m doesn't spit out strange
> > characters at me. Now I noticed one weirdness: The cursor position seem
> > to be calculated directly by byte amount instead of character amount -
> > which makes the cursor move two characters for every 8bit characters
> > instead of just one.
>
> Really, I see this:
>
> /* returns the length of the next word */
> static gint pal_output_wordlen(gchar* string)
> {
> gchar* p = string;
> int i=0;
> while(*p != ' ' && *p != '\0')
> {
> p = g_utf8_next_char(p);
> i++;
> }
>
> return i;
> }
Hmm, that's strange then ...
> Which counts the number of characters, not bytes. Also wrong, but
> doesn't appear to be what you're seeing. Can you provide an example?
When you start pal -m using an utf8 locale and have entries which
aren't in plain ASCII you already have them displayed wrongly (like,
M-CM-< instead of a german umlaut u = ΓΌ). When you link against
libncursesw5 this gets displayed properly again.
When you then press tab to go to the next entry, type e for edit, you
have the New description: line infront of you, and the current text. Add
an 8bit character, and the cursor will move not one character but two to
the right. When you move the cursor back with the arrow key it jumps two
characters instead of only one.
Hope that helps you to reproduce it. It works like this with any utf8
locale, and using LC_ALL=C makes it look like it's proper, but one is
able to delete half of the utf8 umlaut and even being able to produce a
b0rked entry.
So long. :)
Rhonda
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
