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

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


From: Robert Bihlmeyer <robbe@orcus.priv.at>
Subject: Re: sensible-x-terminal and x-terminal-emulator
Date: 24 Jun 2000 11:28:05 +0200

> Tomohiro KUBOTA <kubota@surfchem0.riken.go.jp> writes:
> > My version of sensible-x-terminal check $XTERMINAL environmental
> > variable.
> Are the l18n envvars not sufficient? One of the argument against
> sensible-x-terminal seems to be the reluctance to add
> yet-another-environment-variable.

Thank you for testing and comments.

I think a user who sets $XTERMINAL naturally knows which terminal
can display his/her native language.  Thus $XTERMINAL overrides
locale-sensible algorithm.

Though my sensible-x-terminal is essential for Asian language
speakers, it can be used for users' preference.  For example,
a user may prefer rxvt and an other user of the same machine 
may prefer eterm.

> > And more, it checks LC_CTYPE locale and invokes proper
> > X terminal emulator for multibyte languages (CJK) and combining 
> > character languages (Thai).
> Does LANG work, too?

Yes, of course.  LC_CTYPE is one of locale categories.
To determine LC_CTYPE locale category, setlocale() checks
LC_ALL, LC_CTYPE, and LANG variables.  LC_ALL overrides 
other two and LC_CTYPE overrides LANG.

Be careful that LC_CTYPE I wrote in the citation is not
a name of environmental variable but a name of locale category.
(This is why I wrote "LC_CTYPE locale".)

(For your interest: there are locale categories of LC_COLLATE, 

> I did not get your code to work quite properly. If I set LC_CTYPE to
> something, I get
> Warning: locale not supported by C library, locale unchanged
> from glibc.

Did you install locales package?  And more, you know, for example, 
LANG=de is not a correct specifiaction.  LANG=de_DE is correct.
Though gettext works for LANG=de, I think the behavior of gettext
is against standard and it can be regarded as a bug.

> > This package cannot be a solution because other softwares which 
> > invoke terminal (for example, Debian menu system) should invoke 
> > sensible-x-terminal instead of x-terminal-emulator or xterm.
> Of course. But you could work some magic until then: Just divert
> /usr/bin/x-terminal-emulator, install your s-x-t under this name (or
> symlink to it), and call the original version from s-x-t.

One problem.  s-x-t wants to fall into x-t-e if no $XTERMIAL is available
and no language-specific terminal is available.  If s-x-t calls x-t-e
and x-t-e is a link to s-x-t, it makes an infinite loop.  On the other
hand, if s-x-t is modified not to fall into x-t-e, it completely kills
/etc/alternatives mechanism.  Though we Asian people don't mind this,
European language speakers may complain...

> > The solution should be one of them:
> > 
> >  - sensible-x-terminal is included in debianutils package or
> >  - menu package and so on Depends: on sensible-x-terminal package
> >    which I am now writing.
> I don't have a problem with one of these. I would prefer a
> Unicode-clean xterm, though ...

Asian people need ISO2022-based encodings such as EUC-JP, EUC-KR,
TIS620, and so on.  I think we should support both new Unicode (or
ISO10646)-based encodings such as UCS-4 and UTF-8 and conventional 
ISO2022-based encodings such as ISO8859-*, ISO2022-*, and EUC-*.

In future I think we will have UTF-8-based locale database, for 
example, en_US.UTF-8 or ja_JP.UTF-8, in addition to ja_JP.eucJP.
Then s-x-t will need to check whole LC_CTYPE locale name, not 
the two (or five) characters of LC_CTYPE locale name... (s-x-t 
version 0.01 checks whether the top of LC_CTYPE locale name is 
"ja", "ko", "th", "zh_TW", or "zh".)

I think the best way is all X terminal emulators will be sensible
to LC_CTYPE locale and can display ASCII, ISO8859-*, ISO2022-*,
EUC-*, UTF-8, and so on.  Do someone know possibility that future xterm
will support not only ASCII, ISO8859-*, and UTF-8 but also ISO2022-*
and EUC-* ?

Tomohiro KUBOTA <kubota@debian.or.jp>

Reply to: