Tomohiro KUBOTA wrote on 2001-01-27 02:27 UTC:
> and found that my strong opinion (so strong that I wrote CJK people
> would fall into panic if compatibility is abandoned) was confirmed. All
> softwares which I used on these terminals in my life must be based on
> the same policy because they worked well on the terminals.
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. I'm in favour of a tabula rasa approach. Let's discuss calmly
all alternative design decisions equally and then compare their relative
merits. Backwards compatibility seems less relevant here than say
programmer convenience and clean semantics and should not be quoted
immediately to exclude potentially nicer alternatives.
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. I
don't like the idea of a backspace followed by a graphical character
creating a broken left-half-ideograph on the screen. So what where the
reasons for EUC folks to prevent this nice semantics in the first place?
> When does a user have a chance to use kernel-builtin line editor?
Each time a process reads from stdin without reconfiguring the tty,
which is quite frequent in my daily usage of the Unix environment (e.g.,
rcs ci asking for a revision comment, etc.).
Markus
--
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/lists/
