Hi,
At Sat, 27 Jan 2001 18:13:14 +0000,
Markus Kuhn <[EMAIL PROTECTED]> wrote:
> The quoted software packages are not applicable in their exact current
> EUC-hardwired form for UTF-8 processing and will have to be modified
> anyway. I see no really big binding reasons, why the semantics of
> sending a backspace to the terminal in UTF-8 mode has to be compatible
> with the (as I see it rather inconvenient) EUC practice. A panic in the
> EUC world about BS semantics of UTF-8 terminals would seem somewhat
> pointless.
Do you think
UTF-8 -> '\b' moves one _character_
All other encodings -> '\b' moves one _column_
way is better? Such inconsistent way is inconvenient both for users
and developers. This way disables consistent implementation using
wchar_t and wcwidth() based on locale. Though I agree your opinion
is a bit better from purely technological view than mine, this way is
apparently worse. Thus I forget this idea now and assume you insist
that '\b' should move one _character_ in every locales.
> Let's discuss calmly
> all alternative design decisions equally and then compare their relative
> merits.
Sure. Let's discuss calmly whether rewriting all softwares in CJK
world is possible or not. It will cancel all 'relative merits'.
Do you understand why all softwares have to be rewritten?
When an application software works on a terminal, the application
and terminal have to agree on the behavior of '\b' code. Since
any combination of applications and terminals can be used (I often
use Linux via TeraTerm, a Windows telnet software), all of them
must follow a unified policy. Because your opinion means the change
of this policy, all softwares must be rewritten. (Though I cannot
believe you don't understand this point...)
Do you rewrite all softwares? Can you access the source code of
MS-Windows (to modify behavior of MS-DOS window)? How many softwares
are there in CJK world? All of them? Re-educate all amateur and
professional developers in CJK world? It is simply impossible.
Do you think it is possible? However your opinion is superior,
it is just impossible. That's crying for moon.
> Backwards compatibility seems less relevant here than say
> programmer convenience and clean semantics and should not be quoted
> immediately to exclude potentially nicer alternatives.
Why do you think so? Why do you neglect the compatibility?
Do you understand how important this compatibility is?
This affects people not only who want to use UTF-8 but also
all people in CJK world.
> I like the idea that the terminal behaves in a useful way if the host
> simply echoes one-to-one all typed characters back, just as in ASCII.
> don't like the idea of a backspace followed by a graphical character
> creating a broken left-half-ideograph on the screen.
Even if your way is taken, modification is needed so that 'backspace'
erases not one byte but one character in the internal buffer. This
modification is needed regardless of which opinion is taken. However,
important point is that this modification is for advancement (to support
not only 8bit encodings but also multibyte encodings), worth doing, and
developers can do this anytime when they come to think their software
should support multibyte encodings (UTF-*, EUC-*, ISO-2022-*, Shift_JIS,
GB*, Big5, JOHAB, and so on).
On the other hand, modification of CJK softwares in case your opinion
is taken is not for advancement but needed just to work (otherwise the
software sucks). It is not worth doing, painful labor, and you must
do this at the same time for all softwares to migrate '\b' policy
without breaking consistency.
In summary, this is not a pure technological problem. There is
already a widely-used de-facto standard. If it were a pure
technological problem, I agree your way is a bit better. However,
your opinion breaks the compatibility for CJK world. It is just
impossible to rewrite all softwares in CJK world and thus your
opinion is impossible. We are not resident of Neverland but the
real world. Stop crying for moon.
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://surfchem0.riken.go.jp/~kubota/
"Introduction to I18N"
http://www.debian.org/doc/manuals/intro-i18n/
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/lists/
