[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: sensible-x-terminal and x-terminal-emulator



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/



Reply to: