On Fri, Nov 07, 2003 at 01:11:29PM -0700, Joel Baker wrote: > [ Disclaimer: I'm part of the XSF, but I don't generally deal with ] > [ [u]xterm So this is merely my opinion. ] > > It seems to me like this is an emminently *bad* slope to start down; the > entire point of Unicode's distinguishing between the two is that they > are, in fact, different. True, if one transliterates them back to ASCII, > then they both end up being 0x002D, but it seems to me that the sanest > assumption, if someone is running UTF-8, is that they actually want UTF-8. > > If the default Unicode fonts are incomplete enough that they lack this > character, then that is probably worthy of a bug (and this one could just > be reassigned), but I fail to see why the application should be expected to > do something fundamentally antithetical to the user's stated request for > UTF-8, simply because some fonts claiming to be intended for Unicode fail > to provide a useful set of Unicode entries.
I am tempted to agree. However: 1) The Unicode tables define decompositions and alternate forms for many codepoints, so the slippery slope is at least defined. We probably need a unicode-slippery-slope shared library rather than writing this functionality into xterm directly. :) 2) I'll want to know what the upstream XTerm maintainer, Thomas Dickey, thinks. He scans the Debian xterm package bug reports periodically, so I am going to await his input. -- G. Branden Robinson | Suffer before God and ye shall be Debian GNU/Linux | redeemed. God loves us, so He [EMAIL PROTECTED] | makes us suffer Christianity. http://people.debian.org/~branden/ | -- Aaron Dunsmore
signature.asc
Description: Digital signature
