On Thu, May 12, 2011 at 04:08:24PM +0000, Alan Mackenzie wrote:
> I suspect the font I'm using is lacking support for the line graphics,
> and the driver for the screen is helpfully outputting an ASCII
> representation of the 3 UTF-8 bytes which code up the line graphic code.

If your environment is indeed properly set up as UTF-8, that should
not ever happen.  The console driver should recognize that its font
has no glyph for the UTF-8 character which it is trying to print, and
print a diamond instead.  The behavior you are seeing is that the
console is treating this as three separate ASCII characters.

> I decoded M-b~T~T to 0xe29494 -> 0x2514.  I found a Unicode decoder, and
> it does indeed say that 0x2514 is the appropriate line glyph.

Those two behaviors are consistent with this:

> Indeed, my mutt is linking with libncurses.so.  I also have a
> libncursesw.so on my system.  How do I persuade mutt to build with
> ncursesw?  There doesn't seem to be a flag in Gentoo's configuration to
> force this.  Maybe I should ask on the Gentoo mailing list.

I guess it depends how you're installing Mutt.  If you have the
ncursesw *devel* bits installed, IIRC mutt will notice them when you
configure it (i.e. manual compile).  Gentoo's software management is
pretty unique, and I have no experience with it, but if you're using
emerge then I would expect the same thing *should* be true.  So the
key is to make sure that you have the development portion of the
ncursesw library installed.  There are probably gentoo savvy people
here, but you may get a faster response by asking on their list
instead.

> > If your system is actually recent then telling us what it is and how
> > you converted it may provide some useful clues as to what's missing.
> 
> Up to date Gentoo.  

Can't help here either, for the same reason.

> Does mutt use the environment variables like LANG and LC_.... to
> determine how to output stuff?

Yes, absolutely.  [Generally you want to set LANG properly and let the
LC_* vars inherit from it.]  In the past though, you did have to do
things to tell the kernel that you wanted to use a UTF-8 console.
That seems to have changed, as I don't need to do this on either my
Fedora or Ubuntu installs...  But I haven't built a custom kernel
since the 2.4 days; so I can't say whether there's some required
configuration option in the kernel config stuff that you may need to
enable to make it work properly.  But there's a fairly easy test for
this:  If you have a file lying around which contains umlauts or other
diacritic characters and which you're sure is encoded using UTF-8,
just cat it on the console.  If it displays properly, or if you see
diamonds in positions where non-8-bit UTF-8 characters should be, then
your console is fine.

Probably fixing mutt's build will make it work properly, I would guess.

> A very great deal, thanks!

No problem.  I went through all this long ago when the software was
still poor and the docs were poorer, so I feel your pain.  You have it
relatively easy now. ;-)

-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.

Attachment: pgpZdZxifstZK.pgp
Description: PGP signature

Reply via email to