Re: sensible-x-terminal and x-terminal-emulator
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 <kubota@surfchem0.riken.go.jp>
Subject: Re: sensible-x-terminal and x-terminal-emulator
Date: Tue, 18 Jul 2000 10:44:46 +0900
> Hi,
>
> From: Branden Robinson <branden@deadbeast.net>
> 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 <kubota@debian.or.jp>
> http://surfchem0.riken.go.jp/~kubota/
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: