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

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

bug#54971: 28.1; input method chinese-ctlaub unable to enter �p


From: Van Ly
Subject: bug#54971: 28.1; input method chinese-ctlaub unable to enter �p
Date: Sat, 16 Apr 2022 18:00:56 +0000 (UTC)

On Sat, 16 Apr 2022, Eli Zaretskii wrote:

From: Lars Ingebrigtsen <larsi@gnus.org>
Cc: Van Ly <van.ly@sdf.org>,  54971@debbugs.gnu.org
Date: Sat, 16 Apr 2022 16:20:31 +0200

Eli Zaretskii <eliz@gnu.org> writes:

What is that \265 octal escape?  You use it in the URL below as well:

The mail from Van Ly used a very odd charset -- GB2312 -- so perhaps
rmail had difficulties with it?

I don't think so: the encoding of the buffer was shown correctly, and
the decoding uses the usual Emacs primitives.


I use the Pine mail reader and in it I use Gnu Emacs as an alternative editor. The layering of pico, emacs editors in the construction of the email may explain why the charset is what it is. I would expect it to be utf8.

=> https://humanum.arts.cuhk.edu.hk/Lexis/lexi-mf/search.php?word=祊
Multi-function Chinese Character Database

OK, but I don't understand what I see on that page.  And anyway, I
think the conclusion is the same: we don't have that character in the
file we use as the source for the chinese-ctlaub input method.

Some fields on the database are presented in English by clicking on "ENG" where you find it on the left navigation menu if your web browser frame is wide enough.

There is a "Suggestions" link at the bottom of the webpage

=> https://humanum.arts.cuhk.edu.hk/Lexis/lexi-mf/feedback.php Suggestions

Perhaps the Admin. there is willing to collaborate with the GNU Emacs Project and provide the needed file to keep chinese-ctlaub current with their wider repertoire of characters.

--
vl

reply via email to

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