On Fri, Feb 23, 2007 at 04:24:29PM -0800, Ben Wiley Sittler wrote: > just two cents: i did this some years back for the links and elinks > web browsers (it's the "utf-8 i/o" option available in some versions
FWIW: ELinks has since been fixed (in the development versions, not yet released but working great) to have true UTF-8 support. Proper Unicode support/m17n is still a ways off tho (bidi, line breaking, combining characters, cjk-wide behavior, UTF-8 text search, etc.). > of each) and the results are fairly mixed -- copy-n-paste fails > horribly in an app converted in this way, and i assume the same would > be true of a terminal emulator in a window system like X11. on the Well, copy-n-paste will work fine as long as the characters you want to copy/paste are in the user's selected legacy codepage. Other characters naturally are lost, but presumably the user doesn't really care about characters aside from the ones in their own language or else they'd get a better terminal.. > using luit for this sounds appealing, but in my experience luit (a) > crashes frequently and (b) is easily confused by escape sequences and > has no user interface for resetting all its iso-2022 state, so in > practice it works for only a few apps. Hmm, maybe a replacement for luit is in order then.. If I omit iso-2022 support (which IMO is a big plus) then it should just be ~100 lines of C.. I'll see if I can whip up a prototype sometime soon. > that said, it would probably be better thanthe current state of affairs. Yeah, that was the main thing I wanted to say, I suppose. Of course it would be nice if someone wants to add proper UTF-8 support, but that's a lot more work.. IMO, if there were at least minimal UTF-8 support, it might allow people with modern systems and UTF-8 locales to use these terminal emulators again, and then they might get interested in improving them to have real support... Rich -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
