Hi, Derek. On Thu, May 12, 2011 at 11:42:39AM -0500, Derek Martin wrote: > 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). I've worked out what happened. Up until last Sunday I had the Gentoo build configuration flag "unicode" disabled. So before that I didn't have an ncursesw, only an ncurses. mutt thus linked itself with the existing ncurses. When I enabled "unicode" and rebuilt "everything", libncursesw appeared, but mutt wasn't rebuilt, due to an error in its build script. So I was still using an 8-bit mutt. I've just rebuilt mutt, and now everything works as desired, including the line graphics and non-ASCII characters in people's names. > > 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. You can configure language options in the file system section. I think that's just for non-ASCII filenames, not their contents. > 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. Done this, it is. > 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. ;-) Indeed! Thanks again. > -- > Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -- Alan Mackenzie (Nuremberg, Germany).
