On Tue, Feb 12, 2002 at 09:54:52AM +0200, Zvi Har'El wrote:
> I am using the same Mutt 1.3.27i (2002-01-22) with utf-8, and it has even
> problems 1.2.5 didn't have. For example, when the subject includes characters
> with 2-byte utf-8 representation, its length is not calculated correctly for
> representation in the index page, and it is truncated prematurely, but when you
> step over it with the cursor is highlight also the next line with the rest of
> the subject. Refreshing the index eliminates the phenomenon. I had no problems
> with viewing the subject in the message page, both in the title and in the
> headers. I am using an external pager, less, and mutt passes it the correct
> subject. But this was also ok in 1.2.5. My configuration
Current ncurses doesn't deal with multibyte characters, so the cursor
position becomes desynchronized.
Mutt has a special case for utf-8; it sends UTF-8 line drawing characters
manually:
case M_TREE_LLCORNER:
if (option (OPTASCIICHARS))
addch ('`');
else if (Charset_is_utf8)
addstr ("\342\224\224"); /* WACS_LLCORNER */
else
addch (ACS_LLCORNER);
break;
They may have added this since 1.2.5. It helps with Debian's multibyte-
patched version of Slang, which breaks the ACS stuff in the ncurses
emulation. When compiling with real ncurses, however, it'll just
confuse it. (It'll draw the character correctly, and desync the
cursor.) I don't know what happened to line drawing characters with
ncurses in UTF-8 before this special case. Try adding "set ascii_chars"
to your .muttrc as a quick workaround. I don't know of any quick workaround
for actual subjects with non-ASCII characters (which will be represented
with two or more bytes in a UTF-8 locale).
You shouldn't be having any problem if you're in a simple 8-bit locale,
displaying subjects with UTF-8 in them; I've never seen any problems
like that, though.
A warning about using slang as ncurses in general: it's not perfect.
It'll break meta-characters in Mutt and most other apps. (This is
fixed; the fix isn't released yet.) There are probably other glitches.
(Note that the above special case isn't actually wrong; if the ncurses
in use is locale-aware, it should be able to handle it. However, if the
ncurses in use is locale-aware and does ACS properly, it's also
completely unnecessary--it should go away once multibyte ncurses is
stable.)
--
Glenn Maynard
--
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
