Bug#215647: [patch] xterm 4.3.0-0pre1v3 i18n
Hi,
> You need to remember what xterm is. First and foremost, it's a VT100
> terminal emulator. It got a Tektronix 4014 emulator bolted onto it at
> one point, and it added support for VT 220s (and 320s and 420s as well,
> I think), but fundamentally it's still an 8-bit terminal emulator.
>
> XTerm simply was not written from the ground up to be a multi-byte,
> highly-internationalized terminal emulator. The version first of XTerm
> was written in 1984.
I don't feel this is a serious discussion.
If you really think so, many features must be removed from xterm.
For example, xterm has been supporting UTF-8 (and therefor a multibyte
software) for a long time since XFree86 4.0. Please remove the feature
(and many features which VT100 and so on don't have), if you really
think so.
> > This is the main point. IMO, "uxterm" is an evil fork and a makeshift
> > until xterm itself will be improved enough.
>
> Evil fork? Are you hearing yourself? uxterm can't be a fork because
> it's just a shell script wrapper around xterm.
Right, from technical point of view, it is a wrapper. However,
from the users' point of view who never do "cat xterm", it is a fork.
Evil fork, just like preparing another executable for Japanese support
even when unfication is possible.
> A makeshift solution? Possibly. If xterm itself renders uxterm
> obsolete, a compatibility symlink can be provided for a Debian release
> or so while people switch over to xterm.
My patch renders uxterm obsolete. However, uxterm is an always-UTF-8
version of xterm regardless of locale, xterm cannot emulate uxterm.
On the other hand, xterm is a terminal emulator which don't fully
support locale yet and should be improved.
> > Or, it is a version for people who don't know LANG variable or people
> > who just want to temporarily test UTF-8.
>
> I use uxterm and neither of those descriptions fit me.
Are you using a UTF-8 locale? Then, besides uxterm, xterm should
be in UTF-8 mode, while the font is ISO-8859-1. This conflict
will be fixed by my patch.
> > However, if we were admit uxterm as a final solution, we would have to
> > accept UTF-8 variants for all softwares. We would have to introduce
> > uls, uwc, uperl, used, ugrep, and so on so on.
>
> Ah, the slippery slope argument.
>
> I don't have time to rebut logical fallacies.
My intension is that many softwares are coming to support locale
and don't supply different executables for different encodings.
It is the way we should proceed. Your rebuttal softwares should
be considered that they don't support locale yet or they are to
be replaced by internationalized softwares in future.
> Your arguments are not persuasive, especially because they're so shrill
> and seem to betray a lack of understanding of the underlying software.
I don't understand the meaning.
> You can modify the XTerm app-defaults files on your machines as much as
> you like; that's why they're conffiles. But your reasons for filing
> this bug appear to boil down to a subjective personal dislike for typing
> "uxterm" instead of "xterm". Outright replacement of xterm with uxterm
> would cause surprising changes in behavior for some users -- at this
> point, anyway.
Please be calm.
Since uxterm was introduced into XFree86, it must not be removed.
uxterm must be an UTF-8 software regardless of locale, because it
was intended as such, even if the intension is based on wrong idea.
On app-defaults files: why peoples speaking some languages are
forced to modify app-default files while others don't need to do?
Generally, priviledged people say that there are no discrimination.
If there were some technical difficulties, it might be acceptable.
Also, your idea is against the concept of locale mechanism (no need
for users to configure other than LANG variable) which I explained
many times. Didn't you read?
> Perhaps in the future that won't be so. Maybe you should ask Thomas
> Dickey what you can do to help realize that future where uxterm no
> longer needs to exist.
Now I started this. Dickey said that my patch (you and I thought
was rejected) is "still on my to-do list" and he is "interested in
getting the idea implemented". He is seeking a better implementation
to achieve the same thing. Of course I don't cite his whole mail
and may have a bias. Please ask him by yourself if you don't trust
my citation.
---
Tomohiro KUBOTA <kubota@debian.org>
http://www.debian.or.jp/~kubota/
Reply to: