Alain, Sorry to take so long replying. I've not had time to sit down with PuTTY until now. Alain Bench wrote: > On Friday, May 5, 2006 at 20:19:32 -0400, Todd Zullinger wrote: > >> Damn you Alain. You would ask for details and probably have me >> demonstrate that it's just a PEBKAC. :) > > Could look promising, but I'm never happy before I can shout an > humiliating « RTFM! ». ;-) Well, I'll see what I can do to accommodate your twisted needs in exchange for some enlightenment. >> the thread tree isn't displayed correctly > > The precise way it fails may help pointing to the cause. Could you > please describe the non-correctness? You mean "it don't work" isn't enough information for you? Sheesh. :) The (mis-)behavior I was seeing was either square boxes or strange symbols instead of the thread tree characters. Honestly, the defaults weren't working for me when I setup up the putty connection to my home server ages ago and I've apparently carried over some broken configuration in the putty updates I've done since then. I started with a fresh configuration and found that the thread tree problem is gone now. That's better than an RTFM for you to toss back at me. > ACS should work in all those charsets (better avoid the unsure "Use > font encoding"), with just a specificity in the way it's done in > UTF-8. Specificity that should *normally* be transparent to the > user though... I must admit my ignorance here. What's ACS referring to in this context? >> I'm not sure which [fonts], if any, include the proper glyphs to do >> the line drawing. > > Most if not all, AFAICS. "Lucida Console 1.60" for sure. The default > "Courier New" also. I'd been using Lucida for a long time and only recently tried using the Bitstream Vera Sans Mono ttf which I knew worked well under linux. Oddly, the Bitstream font displays square boxes while Lucida does work well. Probably more misconfiguration on my part. But no big deal, it's better to not rely on a non-standard font in the first place. > OK: ACS should just work, out of the box, in mostly default > settings. Let's checklist a working setup and what can have an > influence: > > PuTTY full defaults but the auto-exported TERM: > > · Font "Courier New", default. > · Translation "ISO-8859-1", default. > · "Use Unicode line drawing code points", default. > · Connection -> Data -> Terminal-type string: "putty". > > Accessing the home machine: > > · printf "\033(B\033)0\016tnu\017" gives TV-antenna-like lines? Yep. > · Ncurses version and date (tic -V)? ncurses 5.4.20050122 > · TERM=putty? True. > · export LANG=en_US, everything else not set. > > In Mutt verify: > > · :set ?charset ==> iso-8859-1 Yessir. > · :set ?ascii_chars ahum, sorry ;-) Understandable. It never hurts to be sure. And yes, it's unset. > If it works, then do the same with translation "UTF-8", and > LANG=en_US.UTF-8. Verify $charset took "utf-8" automagically. Do > printf "\xE2\x94\x9C\xE2\x94\xBC\xE2\x94\xA4" for the TV antenna. Worked there as well. Damn it, I spent too much time trying to change the settings I'd carried over from older putty setups and somehow never just pulled in a default config since updating. That seems to solve the mutt issues. I still have some issues with ncmpc (line drawing characters are wrong using UTF-8, but work with ISO8859-1), one of the other I tried using from putty. But in testing with a few other ncurses apps it seems that it must be an ncmpc bug or a something that requires a little special treatment to make work in a UTF-8 environment. As mutt is the primary thing I'd use via putty from the road, it's very nice to know that it does work. Thanks for your help Alain! You may now gloat, point, laugh, or whatever you wish at my ignorance. ;-) -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== Ambition is a poor excuse for not having enough sense to be lazy.
Attachment:
pgpuoLnOXo1ib.pgp
Description: PGP signature