Re: sensible-x-terminal and x-terminal-emulator
Hi,
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,
LC_CTYPE, LC_MESSAGES, LC_MONETARY, LC_NUMERIC, and LC_TIME.)
> 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>
http://surfchem0.riken.go.jp/~kubota/
Reply to: