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

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

[Van Ly]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; format=flowed; charset=GB2312, Size: 377 bytes --]


Hello,

The character entered by typing "C-x 8 RET 794a" for µp is incapable 
of being entered using the chinese-ctlaub input method.

At the following website, the Sidney Lau "Cant. Scheme" has "Canton. 
Syllables" for typing in µp using

* bang
* paang

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

-- 
vl

[-- Attachment #2: bug-gnu-emacs report --]
[-- Type: text/plain, Size: 4207 bytes --]

In GNU Emacs 28.1 (build 1, aarch64--linux-gnu, X toolkit, cairo version 1.16.0)
 of 2022-04-07 built on charlie
Repository revision: 5a223c7f2ef4c31abbd46367b6ea83cd19d30aa7
Repository branch: HEAD
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)

Configured using:
 'configure --without-all --prefix=/usr/X/Applications/emacs-28.1
 --build=aarch64--linux-gnu --host=aarch64--linux-gnu
 --with-x-toolkit=lucid --without-xft --with-harfbuzz --with-cairo
 --without-compress-install --without-pop --without-mailutils
 --with-zlib --with-native-compilation --with-libotf --with-gnutls
 --with-threads build_alias=aarch64--linux-gnu
 host_alias=aarch64--linux-gnu'

Configured features:
CAIRO FREETYPE GMP GNUTLS HARFBUZZ LIBOTF NATIVE_COMP PDUMPER SECCOMP
THREADS X11 XIM LUCID ZLIB

Important settings:
  value of $LC_ALL: en_AU.UTF-8
  value of $LANG: en_AU.UTF-8
  locale-coding-system: utf-8-unix

Major mode: LaTeX

Minor modes in effect:
  shell-dirtrack-mode: t
  electric-pair-mode: t
  pixel-scroll-mode: t
  icomplete-vertical-mode: t
  icomplete-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  visual-line-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny rfc822 mml mml-sec epa
epg rfc6068 epg-config gnus-util rmail rmail-loaddefs mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
descr-text eieio-opt speedbar ezimage dframe find-func shortdoc
image-mode exif pcmpl-unix format-spec tex-mode latexenc cus-edit
cus-start wid-edit help-fns radix-tree files-x face-remap quail view
shell pcomplete rect macros time-date misearch multi-isearch tabify comp
comp-cstr warnings rx cl-extra help-mode imenu man make-mode dired-aux
dired dired-loaddefs bookmark mule-util jka-compr info elec-pair
display-line-numbers vc-git diff-mode vc-dispatcher gemini-mode derived
time-stamp dot-mode edmacro kmacro slime compile text-property-search
etags fileloop generator xref project arc-mode archive-mode noutline
outline easy-mmode pp comint ansi-color ring hyperspec thingatpt
browse-url url url-proxy url-privacy url-expand url-methods url-history
url-cookie url-domsuf url-util url-parse auth-source cl-seq eieio
eieio-core eieio-loaddefs password-cache json subr-x map seq byte-opt
bytecomp byte-compile cconv url-vars mailcap modus-operandi-theme
modus-themes cl-macs gv pcase pixel-scroll icomplete cl-loaddefs cl-lib
cus-load iso-transl tooltip eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads dynamic-setting
font-render-setting cairo x-toolkit x multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 409032 43123)
 (symbols 48 31932 1)
 (strings 32 170228 5387)
 (string-bytes 1 4427583)
 (vectors 16 44378)
 (vector-slots 8 2034816 129066)
 (floats 8 232 1506)
 (intervals 56 11083 4204)
 (buffers 992 105))

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

[Eli Zaretskii]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 904 bytes --]

> Date: Sat, 16 Apr 2022 13:05:50 +0000 (UTC)
> From: Van Ly <van.ly@sdf.org>
> 
> The character entered by typing "C-x 8 RET 794a" for µp is incapable 
> of being entered using the chinese-ctlaub input method.

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

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

But I cannot use that in my Web browser, and suspect it is some
encoding problem when you composed the message.

> At the following website, the Sidney Lau "Cant. Scheme" has "Canton. 
> Syllables" for typing in µp using
> 
> * bang
> * paang

We don't have the U+794A character in CTLau-b5.html, neither under
BANG nor in PAANG, which I suppose is why you cannot insert that
character.  If there is an updated version of that file or the
equivalent data somewhere, we could perhaps use it.

Thanks.

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

[Lars Ingebrigtsen]

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?  It came across fine in Gnus:

----
The character entered by typing "C-x 8 RET 794a" for 祊 is incapable
of being entered using the chinese-ctlaub input method.

At the following website, the Sidney Lau "Cant. Scheme" has
"Canton. Syllables" for typing in 祊 using

* bang
* paang

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


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Andreas Schwab]

On Apr 16 2022, Lars Ingebrigtsen wrote:

> The mail from Van Ly used a very odd charset -- GB2312 -- so perhaps
> rmail had difficulties with it?  It came across fine in Gnus:

That only works if you decode it with GB18030 instead of GB2312.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[Eli Zaretskii]

> 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.

> It came across fine in Gnus:
> 
> ----
> The character entered by typing "C-x 8 RET 794a" for 祊 is incapable
> of being entered using the chinese-ctlaub input method.
> 
> At the following website, the Sidney Lau "Cant. Scheme" has
> "Canton. Syllables" for typing in 祊 using
> 
> * bang
> * paang
> 
> => 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.

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

[Van Ly]

[-- Attachment #1: Type: text/plain, Size: 1583 bytes --]

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

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

[Eli Zaretskii]

> Date: Sat, 16 Apr 2022 18:00:56 +0000 (UTC)
> From: Van Ly <van.ly@sdf.org>
> cc: Lars Ingebrigtsen <larsi@gnus.org>, 54971@debbugs.gnu.org
> 
> >> => 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.

I did click on "ENG"; nothing happened.

> 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.

Feel free to submit feedback to them.  Me, I'd be happy to know where
we can find an up-to-date version of the file from which we derived
the CTLau-b5.html file we keep in our repository and from which we
produce that input method.  If you know, or can find out, please tell.

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

[Van Ly]

[-- Attachment #1: Type: text/plain, Size: 1536 bytes --]

On Sat, 16 Apr 2022, Eli Zaretskii wrote:

>> 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.
>
> I did click on "ENG"; nothing happened.
>

Maybe you need to activate the Java/Javascript and retrieve an entry 
from the database to see a change with "ENG" shown in bold font.

> Feel free to submit feedback to them.  Me, I'd be happy to know where
> we can find an up-to-date version of the file from which we derived
> the CTLau-b5.html file we keep in our repository and from which we
> produce that input method.  If you know, or can find out, please tell.

I don't know.  My guess is CTLau-b5.html widen in use from Sidney
Lau's immediate circle.

Anyway, I entered the following message on the feedback page.  And the return e-mail address I used is

* GNU Emacs Project
* 54971@debbugs.gnu.org

'''

The input method chinese-ctlaub on GNU Emacs editor is incapable of entering the Chinese character 祊 without its CTLau-b5.html file having the more up-to-date version available from the entry such as

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

There the "Cant. Scheme:Sidney Lau" for 祊 lists the "Canton. Syllables" as

* bang
* paang

Would the Admin. be willing to collaborate with the GNU Emacs Project to provide the needed file updates to keep the chinese-ctlaub input method current with your wider character repertoire?  Thanks in advance.

'''

-- 
vl

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Van Ly <van.ly@sdf.org> writes:

> On Sat, 16 Apr 2022, Eli Zaretskii wrote:
>
>>> 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.
>>
>> I did click on "ENG"; nothing happened.
>>
>
> Maybe you need to activate the Java/Javascript and retrieve an entry
> from the database to see a change with "ENG" shown in bold font.
>
>> Feel free to submit feedback to them.  Me, I'd be happy to know where
>> we can find an up-to-date version of the file from which we derived
>> the CTLau-b5.html file we keep in our repository and from which we
>> produce that input method.  If you know, or can find out, please tell.
>
> I don't know.  My guess is CTLau-b5.html widen in use from Sidney
> Lau's immediate circle.

In the meantime, you can use the chinese-py-b5 input method, which is
capable of entering that character as "beng1".  Not that such a
character is likely to be used in real life by anyone.

[Your MUA's coding system is weird, so here is that character in
Unicode: 祊.]

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

[Van Ly]

[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]

On Sun, 17 Apr 2022, Po Lu wrote:

                                If you know, or can find out, please tell.
>>
>> I don't know.  My guess is CTLau-b5.html widen in use from Sidney
>> Lau's immediate circle.
>
> In the meantime, you can use the chinese-py-b5 input method, which is
> capable of entering that character as "beng1".  Not that such a
> character is likely to be used in real life by anyone.

The character "fa3" for hair  using chinese-py-b5 input method has the
same problem in chinese-ctlaub.  That character appears in line one at
position six  in a music  video that launched  5 years ago  on Youtube
attracting 250M  views.  The  song was performed  live at  nasa's 2019
break through prize ceremony introduced  by Pierce Brosnan.  The music
video's visual design aesthetics in circulation are thematically Tesla
font typesetting the word "passengers"  in capitals and the technology
is "light  years away" which  is a translation  of the song's  name by
G.E.M..

>
> [Your MUA's coding system is weird, so here is that character in
> Unicode: 祊.]
>

I've set  my mail reader,  Alpine, to emit  UTF-8, can you  see theses
characters in Unicode?

* 祊
* 髮

-- 
vl

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Van Ly <van.ly@sdf.org> writes:

> The character "fa3" for hair  using chinese-py-b5 input method has the
> same problem in chinese-ctlaub.  That character appears in line one at
> position six  in a music  video that launched  5 years ago  on Youtube
> attracting 250M  views.  The  song was performed  live at  nasa's 2019
> break through prize ceremony introduced  by Pierce Brosnan.  The music
> video's visual design aesthetics in circulation are thematically Tesla
> font typesetting the word "passengers"  in capitals and the technology
> is "light  years away" which  is a translation  of the song's  name by
> G.E.M..

What problem do you refer to by "the same problem"?

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

[Van Ly]

On Tue, 26 Apr 2022, Po Lu wrote:

> What problem do you refer to by "the same problem"?

chinese-ctlaub is unable to enter Chinese character.

CTLau-b5.html is in need of an update to at least catchup to what 
chinese-py-b5 uses.

chinese-py-b5 is able to enter two example characters chinese-ctlaub is unable to
* One example is an old character. "beng1"
* Another example is a character in circulation in pop culture. "fa3"

The humanum mfcc database has candidate values from its Sidney Lau 
scheme to fill in CTLau-b5.html gaps.

-- 
vl

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Van Ly <van.ly@sdf.org> writes:

> chinese-ctlaub is unable to enter Chinese character.

chinese-ctlaub is a Cantonese input method, and it isn't fair to expect
it to have every character that chinese-py has (and vice versa.)

> CTLau-b5.html is in need of an update to at least catchup to what
> chinese-py-b5 uses.

chinese-py-b5 is a standard Chinese input method.  They input different
dialects of Chinese, which have different characters, pronunciations and
romanizations, so there is no way to update the chinese-ctlau(b) input
methods with the information used by any other Chinese input method.

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

[Van Ly]

On Tue, 26 Apr 2022, Po Lu wrote:

> chinese-ctlaub is a Cantonese input method, and it isn't fair to expect
> it to have every character that chinese-py has (and vice versa.)

Information in the tone and graph is lost going in the direction

   chinese-ctlaub || chinese-py-b5 > chinese-py

is how I understand things.

-- 
vl

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Van Ly <van.ly@sdf.org> writes:

> Information in the tone and graph is lost going in the direction
>
>   chinese-ctlaub || chinese-py-b5 > chinese-py
>
> is how I understand things.

I don't understand what you're talking about, but chinese-ctlaub is not
related to chinese-py at all.  Comparing them is like comparing a Dutch
keyboard to a German one.