Multibyte characters and menu completion

[DervishD <zsh@xxxxxxxxxxxx>]

	Hi all :)

I'm using compsys, and when I'm doing menu completion I usually use
"accept-and-hold" to insert some of the listed matches. This works like
a charm for me, except for one thing...

My terminal supports utf8 and I have multibyte support in my zsh-4.3.4,
but if some of the characters have a code point greater than U+00FF, the
character is correctly printed but after having inserted the matches I
want with "accept-and-hold", some spaces are written at the end, one for
every extra columnt that zsh thinks the chars occupy. For example, "ñ"
is U+00F1, and it's 0xc3 0xb1 in utf8. It is written as ONE glyph and
zsh thinks that it is one column worth of space while writing. That's
OK.

But if the character code point is greater than U+00FF, weird things
happen. For example, I have a file named U+8336 (kanji for "tea")
followed by U+306e (hiragana "no") followed by U+5473 (kanji for
odor/smell) and zsh prints the name correctly (well, since I'm in a text
mode terminal, it uses three instances of my "unknown character" glyph,
but thinks that each letter is three glyphs wide, putting the cursor six
spaces after the file name once it is completed:

    I expected this, where "X" is my unknown character glyph and the
underscore is the cursor:

	XXX _

	But I get this instead:

	XXX       _

Since this happens in Vim too and it works on a terminal emulator under
X, I don't think that zsh is the culprit, of course, but I'm asking here
just to know if this is a known issue and if the problem relies on my
curses OR in the Linux virtual console. Or maybe it's a zsh problem (I
doubt it, but...) that happens to be present in vim, too, since I
haven't tested many other programs with this.

Any idea? Thanks a lot in advance :))))

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
We are waiting for 13 Feb 2009 23:31:30 +0000 ...