If this bug is going to be marked wontfix, I think a justification is in order. Enabling "eightBitInput" (which Henning has correctly noted is a misnomer) by default clashes with non-7bit characters, making it unreasonable for any application using a terminal to attempt to treat octets with the 8th bit set as meta keys. Not only does the default value of this setting cause problems for users who need non-7bit characters; a multitude of applications (most notably IRC clients but also others) fail to interpret bit 8 as meta, causing an endless stream of new user hassles and support questions. These applications are behaving correctly in supporting an internationalized/multilingual environment; "fixing" them to accept bit 8 as meta would be a major step backwards.
Another related bug is the default setting of utf8Title to false, which causes xterm to disregard the locale's text encoding and treat window title strings arbitrarily as Latin-1. Like "eightBitInput", this resource is also misnamed. It should be named "Leave my title string alone!" as the man page explains that setting it to true merely causes xterm to skip the munging. With UTF-8 as the default text encoding starting with Etch, xterm's active hostility towards non-ASCII-only locales really needs to be treated as the bug it is, and fixed. I would prefer to see it fixed upstream as well, but at the very least Debian should fix it, by adding the following the the app-defaults file: XTerm*eightBitInput: false XTerm*utf8Title: true The man page should also be patched accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]