Bug#83063: PROPOSED] enhanced x-terminal-emulator policy
Hi,
> Yes. It is also the future.
> ISO-2022 may be nice, but it is not the future.
Please note that not all terms I proposed are related to ISO-2022.
It is only a part of my proposal and not the most important one.
I agree UTF-8 will be more important than ISO-2022 in future.
However, I insist that locale (LC_CTYPE)-sensibility is more
important than UTF-8 support, since UTF-8 should be used via
UTF-8 locale (LC_CTYPE=foo_bar.UTF8).
I want to explain other terms. Your proposal means at most
30 points for combining character. I think it is not fair to
give such high points for combining character (vital for Thai
people) while no points for doublewidth (vital for CJK) nor
bidi (vital for Arab/Hebrew). Thus I included doublewidth and
bidi terms. If you change your mind not to include combining
character terms, please not to include doublewidth and bidi terms.
wcwidth() is a UNIX standard and should be followed, though
so far I don't know any terminal emulators do. I included
wcwidth() term because I think it is important to promote standard.
> Policy should serve as a guideline, not a sneaky coronation of some
> particular terminal emulator as Debian's mandated default.
I fully agree with this point. Did you think I am taking such
a sneaky way? I gave 10 points for ISO-2022, just same as UTF-8.
Since xterm already supports UTF-8, it is not likely that kterm
becomes default. I mentioned a few particular terminal emulaters
such as xterm, kterm, and jfbterm in my proposal only because I
wanted to say that my proposal is not a vaporware and that
ISO-2022 is an encoding in real use.
---
Tomohiro KUBOTA <kubota@debian.org>
http://surfchem0.riken.go.jp/~kubota/
"Introduction to I18N"
http://www.debian.org/doc/manuals/intro-i18n/
Reply to: