Hi, I will resend the following mail, which is originally sent to debian-devel list, to debian-x because recent discussion is also held on debian-x.
From: Tomohiro KUBOTA <[EMAIL PROTECTED]> Subject: Re: sensible-x-terminal and x-terminal-emulator Date: Tue, 18 Jul 2000 10:44:46 +0900 > Hi, > > From: Branden Robinson <[EMAIL PROTECTED]> > Subject: Re: sensible-x-terminal and x-terminal-emulator > Date: Sun, 16 Jul 2000 00:38:30 -0500 > > > I'm not yet sure what I think of this whole "sensible-xtermemu" idea, given > > that xterm is all I've personally ever needed, but for consistency with the > > other "sensible" things, I think the only reasonable name for this > > package/program would be "sensible-x-terminal-emulator". > > At first, the fact that all you need is xterm cannot be a reason that > xterm can satisfy all people in the world. > > Xterm can display 8-bit, non-multicolumn, non-combining, left-to-right > languages only. This is true even for XFree86-4.0-xterm. Yes, I know > there is an unofficial patch for XFree86-4.0-xterm to enable multicolumn > and combining characters. However, it supports these characters only > via UTF-8. We need encodings such as EUC-JP, EUC-KR, EUC-CN, EUC-TW, > ISO-2022-JP, ISO-2022-KR, ISO-2022-CN, BIG5, Shift-JIS, CN-GB, and so on, > besides UTF-8. You need ISO-8859-1 besides UTF-8, don't you? You might > be annoyed if xterm were stop to support ISO-8859-* because it supports > UTF-8. It is same. > > # No, not the same. For example, code space of ISO-2022-INT* encoding > # is larger than UTF-8. Therefore, "convert original text from > # ISO-2022-INT* into UTF-8 -> edit it -> reconvert into ISO-2022-INT*" > # way cannot be done. > > We don't _shift into_ UTF-8. UTF-8 should be one of many encodings > which Debian supports (in LOCALE framework). However, I could not find > any intension of Xterm (or XFree86 web site) to support encodings > which I listed above. > > And more, hanterm has alphabet-hangul (Korean character) translation > mechanism to input Korean using keyboard. xiterm+thai has similar > Thai input mechanism. Will xterm integrate these mechanisms? > (Though Korean can be input using 'ami' package via XIM protocol.) > > > > I hope not. Instead of all this furious forking of terminal emulators, I > > would hope that people would contribute to improving xterm. It is actively > > maintained upstream by Thomas Dickey, and he is quite diligently working at > > improving it, with support for variable-width fonts, and so forth. Maybe > > people should read the upstream xterm changelog every once in a while. > > This is not 'fork'. This is a wrapper. > > > > Why don't we put our efforts towards making the standard, reference > > implementation of a terminal emulator fit for as many locales as possible? > > That program would be xterm. > > I admit your way is better. However, do you really think xterm is the > nearest to the ideal? Xterm only supports 8-bit encoding and UTF-8 (now > without multicolumn and combining characters). On the other hand, kterm > supports various encodings based on ISO-2022 (including ISO-8859-*. You > know, ISO-8859-* are also based on ISO-2022 and can be regarded as subsets > of ISO-2022). Rxvt supports a few multibyte encodings (though the > supported encoding must be specified on compile). And more, kterm and > rxvt supports international input via XIM protocol. > (XIM support is vitally important for CJK people). > > I am trying to read the source code of rxvt. However, I have to study > X11 programming first. (I don't know whether kterm is a living project > now...) > > Time is a problem. We need an X terminal emulator with multi-language > support NOW. On the other hand, though Xterm might be going to > support every encodings in the world, it would be in future. > > # However, if it is likely that multi-language xterm which can display, > # input, and copy-paste all encodings, at least, which Debian locales and > # locale-* packages support will be in time for Debian Woody, I will > # withdraw sensible-x-terminal-emulator. > > > > sensible-editor or sensible-pager at all. Instead it looks to me like you > > are hard-coding in all kinds of locale-specific assumptions about what > > terminal emulator program should be used. That way lies madness. > > Asian people have to do many mess of locale-specific configurations > before using Linux. I bought many books on such configuraions. > Don't you think this way lies much larger madness? I'd like to stop > this madness ASAP. Or Debian would be defeated by other 'Japanese- > localized' distributions which we don't need to read these books to > use. > > Ok, I can design a way to avoid hard-coding. It will have a configuration > file in /etc directory. All X terminal emulators which supports special > language like multibyte, combining, right-to-left, and up-to-down > languages will install its /etc item. sensible-x-terminal-emulator > will check the configuration file (or directory). How about this idea? > (Though this way needs more Debian Policy.) > > --- > Tomohiro KUBOTA <[EMAIL PROTECTED]> > http://surfchem0.riken.go.jp/~kubota/ > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
