[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs and nl_langinfo(CODESET)
- To: linux-utf8@xxxxxxxxxxxx
- Subject: Re: Emacs and nl_langinfo(CODESET)
- From: Tomohiro KUBOTA <tkubota@xxxxxxxxxxx>
- Date: Sun, 01 Jul 2001 10:23:41 +0900
- In-reply-to: In your message of "Sat, 30 Jun 2001 09:00:50 +0100 (BST)" <Pine.LNX.4.31.0106300849390.19200-100000@kern.srcf.societies.cam.ac.uk>
- Mail-reply-to: tkubota@xxxxxxxxxxx
- References: <87n16qwqny.wl@surfchem0.riken.go.jp> <Pine.LNX.4.31.0106300849390.19200-100000@kern.srcf.societies.cam.ac.uk>
- Reply-to: linux-utf8@xxxxxxxxxxxx
- Sender: owner-linux-utf8@xxxxxxxxxxxx
- User-agent: Wanderlust/1.1.1 (Purple Rain) EMY/1.13.8 (Tastes differ) FLIM/1.13.2 (Kasanui) APEL/10.2 Emacs/20.7 (i386-debian-linux-gnu) MULE/4.1 (AOI)
Hi,
At Sat, 30 Jun 2001 09:00:50 +0100 (BST),
Markus Kuhn <mgk25@xxxxxxxxx> wrote:
> If
> you press ^C in an application that spits out BIG5 in an unfortunate
> moment or truncate a string by counting bytes, then you will loose BIG5
> synchronization, and the terminal has to skip characters in the input
> stream until is finds two G0 characters in a row to be sure again where
> the next character starts. BIG5 is an example of a rather messy encoding,
> not only in that respect. ISO 2022 is far worse.
I don't understand why the current implementation of "luit"
can avoid this problem while iconv() approach cannot.
---
Tomohiro KUBOTA <kubota@xxxxxxxxxx>
http://www.debian.or.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/linux-utf8/