[darcs-users] blue color bug
droundy at abridgegame.org
Sat Jul 3 13:22:26 UTC 2004
On Sat, Jul 03, 2004 at 03:05:28AM +0200, Peter Firefly Lund wrote:
> I think these are the practical options in order of ease of implementation:
> 1) current behaviour
> 2) blind output
> 3) pretend everything is in UTF8 and convert to current locale
> 4) pretend everything is in 8859-1 and convert to current locale
> 5) have a per-repository setting for encoding/charset and convert to
> current locale.
> There are other options, of course: assume (but check!) that everything is
> in UTF8 (without overlong sequences), use the new Linux ioctl to ask the
> terminal whether it is in UTF8 mode or not, use a simple VT100 sequence to
> autodetect to whether the terminal is in UTF8 mode or not (I have an
> implementation of this I can dig up if somebody is interested), etc.
> In no case do I want to do any conversion of actual file/patch content.
> This is entirely for output purposes!
> ad 2) blind output is bad with binary files and some of the more insane
> Chinese/Japanese encodings (some of them use escape codes).
> /Some/ filtering/escaping seems to be necessary.
> ad 3-5) can mostly be taken care of with iconv (which can handle pretty
> much any whacky encoding/charset known to Man).
> ad 5) is probably the Right thing to do. It's just that Gabriel's "Worse
> is Better" essay keeps echoing in my mind for some reason ;)
Either 5) or perhaps some degree of auto-detection. I understand most
non-utf8 encodings aren't valid utf8, so one can at least autodetect
whether it is *not* utf8. So one could check if it appears to be utf8, and
if so try to display it correctly... and otherwise assume it's in the right
format for the current locale and hope for the best?
While I'll accept patches in this area, I'm not likely to work on it
myself, since I haven't ever used characters above 127, and don't know what
they should look like if I had some.
More information about the darcs-users