bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problems with Cyrillic encoding


From: Kenichi Handa
Subject: Re: Problems with Cyrillic encoding
Date: Tue, 18 Feb 2003 21:27:48 +0900 (JST)
User-agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.2.92 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI)

In article <address@hidden>, Claus Tondering <address@hidden> writes:
> In GNU Emacs 21.2.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
[...]
> I can type Russian (Cyrillic) letters in two ways:

> * If I select a Russian keyboard and type Russian letters, they get
>   into the Emacs buffer with character values in the range
>   0x51450-0x5146f (for the lower case letters).

>   Calling the the built-in Lisp function
>   find-coding-systems-region-internal on these characters returns
>   mule-utf-8 as a possible encoding.

> * If I use a Latin keyboard and set the input method to
>   cyrillic-jcuken, the Russian letters are inserted into the Emacs
>   buffer as characts with values in the range 0xe50-0xe6f (for the
>   lower case letters).

>   Calling find-coding-systems-region-internal on these characters does
>   *not* return mule-utf-8 as a possible encoding.

> This has bad consequences when I try to use Russian characters in
> email and Gnus, because UTF-8 is not chosen as a valid encoding in the
> last case.

Please try the latest pretest version 21.2.95 available at
<ftp://alpha.gnu.org/gnu/emacs/pretest/>.

With this version, both kind of Russian characters
(0x51450-0x5146f and 0xe50-0xe6f) can be encoded by both
utf-8 and iso-8859-5.

But, I don't know why characters of the range
0x51450-0x5146f is input by a Russian keyboard.

As something about X's keysym handling is changed, the
behaviour of the pretest version may be different from 21.2.

---
Ken'ichi HANDA
address@hidden





reply via email to

[Prev in Thread] Current Thread [Next in Thread]