GNU bug report logs -
#53896
28.0.91; Icomplete Vertical Mode fails to preview "C-x 8 RET 8072"
Previous Next
Reported by: Van Ly <van.ly <at> sdf.org>
Date: Wed, 9 Feb 2022 10:39:01 UTC
Severity: normal
Tags: notabug, wontfix
Found in version 28.0.91
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 53896 in the body.
You can then email your comments to 53896 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#53896
; Package
emacs
.
(Wed, 09 Feb 2022 10:39:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Van Ly <van.ly <at> sdf.org>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Wed, 09 Feb 2022 10:39:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
The vertical listing in the minibuffer in response to "insert-char" fails to preview the match for "C-x 8 RET 8072".
observed behavior
* start by "emacs -Q"
* M-x customize RET
* search "icomplete vertical"
* toggle "on" Icomplete Vertical Mode
* switch to "*scratch*" buffer
; --------------------------------
; minibuffer fails to preview 8072
; --------------------------------
* C-x 8 RET
* continue typing "80" ;; shows LINEAR A SIGN A580, A800, A801, A802, A803, A804, A805
* continue typing "807" ;; shows LINEAR A SIGN A807
* continue typing "8072" ;; shows "8072 [No matches]"
expected behavior
* start by "emacs -Q"
* M-x customize RET
* search "icomplete vertical"
* toggle "on" Icomplete Vertical Mode
* switch to "*scratch*" buffer
; ----------------------------------
; minibuffer previews match for 8072
; ----------------------------------
* C-x 8 RET
* continue typing "80" ;; shows LINEAR A SIGN A580, A800, A801, A802, A803, A804, A805
* continue typing "807" ;; shows LINEAR A SIGN A807
* continue typing "8072" ;; shows "聲 CJK IDEOGRAPH-8072"
--
vl
[bug-gnu-emacs-28.0.91.text (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#53896
; Package
emacs
.
(Wed, 09 Feb 2022 14:37:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 53896 <at> debbugs.gnu.org (full text, mbox):
tags 53896 notabug
thanks
> Date: Wed, 9 Feb 2022 10:38:29 +0000 (UTC)
> From: Van Ly <van.ly <at> sdf.org>
>
> The vertical listing in the minibuffer in response to "insert-char" fails to preview the match for "C-x 8 RET 8072".
>
> observed behavior
> * start by "emacs -Q"
> * M-x customize RET
> * search "icomplete vertical"
> * toggle "on" Icomplete Vertical Mode
> * switch to "*scratch*" buffer
> ; --------------------------------
> ; minibuffer fails to preview 8072
> ; --------------------------------
> * C-x 8 RET
> * continue typing "80" ;; shows LINEAR A SIGN A580, A800, A801, A802, A803, A804, A805
> * continue typing "807" ;; shows LINEAR A SIGN A807
> * continue typing "8072" ;; shows "8072 [No matches]"
This has nothing to do with icomplete-vertical-mode. You will see the
same with the default completion:
C-x 8 RET 8072 TAB
This shows [No match].
The reason is that we deliberately remove all the CJG IDEOGRAPH-NNNN
names from the list of character names we submit to "C-x 8 RET" as
possible completions. We do that because there are gobs of those
characters, whose names mean nothing (they are not real names), and
whose existence in the completions would just add a lot of noise.
This is a feature, not a bug.
Added tag(s) notabug.
Request was from
Eli Zaretskii <eliz <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Wed, 09 Feb 2022 14:37:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#53896
; Package
emacs
.
(Thu, 10 Feb 2022 01:59:01 GMT)
Full text and
rfc822 format available.
Message #13 received at 53896 <at> debbugs.gnu.org (full text, mbox):
On Wed, 9 Feb 2022, Eli Zaretskii wrote:
> tags 53896 notabug
> thanks
>
Thanks.
> This shows [No match].
>
> The reason is that we deliberately remove all the CJG IDEOGRAPH-NNNN
> names from the list of character names we submit to "C-x 8 RET" as
> possible completions. We do that because there are gobs of those
> characters, whose names mean nothing (they are not real names), and
> whose existence in the completions would just add a lot of noise.
>
> This is a feature, not a bug.
>
It is a blindspot for studying a human culture.
Maybe further on there can be a toggle and filter to sort the meaning
from the noise, sort of like how Grammarly uses Lisp.
--
vl
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#53896
; Package
emacs
.
(Thu, 10 Feb 2022 04:55:01 GMT)
Full text and
rfc822 format available.
Message #16 received at 53896 <at> debbugs.gnu.org (full text, mbox):
Van Ly <van.ly <at> sdf.org> writes:
> It is a blindspot for studying a human culture.
The CJK UNIFIED IDEOGRAPH-XXXX names are utterly meaningless to any
speaker of an East Asian language that uses them.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#53896
; Package
emacs
.
(Fri, 11 Feb 2022 23:12:01 GMT)
Full text and
rfc822 format available.
Message #19 received at 53896 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, 10 Feb 2022, Po Lu wrote:
>
> The CJK UNIFIED IDEOGRAPH-XXXX names are utterly meaningless to any
> speaker of an East Asian language that uses them.
>
LINEAR A SIGN A807 ; from C-x 8 RET 807
The above is utterly meaningless to me but maybe it is meaningful to
the community studying Linear A. And, maybe with time and more
information the text description will improve.
My use case sources the CJK to read from, for example
=> https://ctext.org/er-ya/shi-gu
=> https://humanum.arts.cuhk.edu.hk/Lexis/lexi-mf/search.php
maybe there remain no speakers of those signs.
; from C-x 8 RET a
The current name for "<control>" had the old name "LINE FEED (LF)".
--
vl
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#53896
; Package
emacs
.
(Sat, 12 Feb 2022 00:50:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 53896 <at> debbugs.gnu.org (full text, mbox):
Van Ly <van.ly <at> sdf.org> writes:
> LINEAR A SIGN A807 ; from C-x 8 RET 807
>
> The above is utterly meaningless to me but maybe it is meaningful to
> the community studying Linear A. And, maybe with time and more
> information the text description will improve.
I cannot speak Linear A, so I can't help you there.
> My use case sources the CJK to read from, for example
>
> => https://ctext.org/er-ya/shi-gu
> => https://humanum.arts.cuhk.edu.hk/Lexis/lexi-mf/search.php
>
> maybe there remain no speakers of those signs.
The numbers after a CJK UNIFIED IDEOGRAPH name are completely arbitrary.
They have no correspondence to the meanings of the characters at all.
> The current name for "<control>" had the old name "LINE FEED (LF)".
Now you have lost me.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#53896
; Package
emacs
.
(Sat, 12 Feb 2022 07:14:01 GMT)
Full text and
rfc822 format available.
Message #25 received at 53896 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 11 Feb 2022 23:11:13 +0000 (UTC)
> From: Van Ly <van.ly <at> sdf.org>
> cc: Eli Zaretskii <eliz <at> gnu.org>, 53896 <at> debbugs.gnu.org
>
> > The CJK UNIFIED IDEOGRAPH-XXXX names are utterly meaningless to any
> > speaker of an East Asian language that uses them.
>
> LINEAR A SIGN A807 ; from C-x 8 RET 807
>
> The above is utterly meaningless to me but maybe it is meaningful to
> the community studying Linear A.
Yes. More importantly, there are 341 of them, as opposed to almost
27,000 of CJK Ideographs. Even UnicodeData.txt doesn't include them,
but gives only the first and the last codepoints (one more evidence
that they don't have meaningful names in Unicode DB).
> My use case sources the CJK to read from, for example
>
> => https://ctext.org/er-ya/shi-gu
> => https://humanum.arts.cuhk.edu.hk/Lexis/lexi-mf/search.php
Sorry, I don't understand the relevance. Do you see any names in
those URLs, and if so, are those names in any way derived from the
Unicode character DB? I just see characters, and thus typing their
codepoints is the way to go.
The characters _are_ supported, and we do assign names to them (which
are trivially derived from their codepoints), so typing their names is
just an unnecessarily complicated way of typing their codepoint. IOW,
why not just type 8072 at "C-x 8 RET"s prompt, instead of selecting
"CJK IDEOGRAPH-8072" from a list of 27,000 candidates?
> ; from C-x 8 RET a
>
> The current name for "<control>" had the old name "LINE FEED (LF)".
I don't think I see the relevance. The 'old-name' property comes from
the Unicode DB, and we include the old names in the completion
candidates of "C-x 8 RET". But the characters that have a meaningful
old name have none of the problems the CJK Ideographs have.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#53896
; Package
emacs
.
(Sat, 12 Feb 2022 07:15:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 53896 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Sorry, I don't understand the relevance. Do you see any names in
> those URLs, and if so, are those names in any way derived from the
> Unicode character DB?
I couldn't find any, FWIW.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#53896
; Package
emacs
.
(Sun, 13 Feb 2022 13:07:01 GMT)
Full text and
rfc822 format available.
Message #31 received at 53896 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, 12 Feb 2022, Po Lu wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> Sorry, I don't understand the relevance. Do you see any names in
>> those URLs, and if so, are those names in any way derived from the
>> Unicode character DB?
>
> I couldn't find any, FWIW.
>
=> https://humanum.arts.cuhk.edu.hk/Lexis/lexi-mf/search.php?word=聲
The above link shows two handfuls of I suppose address schemes for
that sign, U+8072 in unicode.
For me, the name
* <CJK Ideograph>
* CJK IDEOGRAPH-8072
is better than "No match" and I get the majority of people who never
process any CJK will suffer performance-wise were the horde of CJK
characters to match in part on insert-char. So, an opt-in toggle and
filter improves on the situation of a blank drop.
Maybe the relevant U+8072 slab from Unihan_Readings.txt can be
included in describe-char under "Unicode data".
--
vl
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#53896
; Package
emacs
.
(Sun, 13 Feb 2022 13:15:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 53896 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 13 Feb 2022 13:06:17 +0000 (UTC)
> From: Van Ly <van.ly <at> sdf.org>
> cc: Eli Zaretskii <eliz <at> gnu.org>, 53896 <at> debbugs.gnu.org
>
> Maybe the relevant U+8072 slab from Unihan_Readings.txt can be
> included in describe-char under "Unicode data".
Which slab specifically?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#53896
; Package
emacs
.
(Sun, 13 Feb 2022 13:19:01 GMT)
Full text and
rfc822 format available.
Message #37 received at 53896 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, 13 Feb 2022, Eli Zaretskii wrote:
>> Date: Sun, 13 Feb 2022 13:06:17 +0000 (UTC)
>> From: Van Ly <van.ly <at> sdf.org>
>> cc: Eli Zaretskii <eliz <at> gnu.org>, 53896 <at> debbugs.gnu.org
>>
>> Maybe the relevant U+8072 slab from Unihan_Readings.txt can be
>> included in describe-char under "Unicode data".
>
> Which slab specifically?
>
'''
U+8072 kCantonese sing1
U+8072 kDefinition sound, voice, noise; tone; music
U+8072 kHangul 성:0E
U+8072 kHanyuPinlu shēng(2269) sheng(57)
U+8072 kHanyuPinyin 42794.040:shēng
U+8072 kJapaneseKun KOE
U+8072 kJapaneseOn SEI SHOU
U+8072 kKorean SENG
U+8072 kMandarin shēng
U+8072 kTang *shiɛng
U+8072 kVietnamese thanh
U+8072 kXHC1983 1023.021:shēng
'''
--
vl
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#53896
; Package
emacs
.
(Sun, 13 Feb 2022 13:53:01 GMT)
Full text and
rfc822 format available.
Message #40 received at 53896 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 13 Feb 2022 13:18:21 +0000 (UTC)
> From: Van Ly <van.ly <at> sdf.org>
> cc: luangruo <at> yahoo.com, 53896 <at> debbugs.gnu.org
>
> >> Maybe the relevant U+8072 slab from Unihan_Readings.txt can be
> >> included in describe-char under "Unicode data".
> >
> > Which slab specifically?
> >
>
> '''
> U+8072 kCantonese sing1
> U+8072 kDefinition sound, voice, noise; tone; music
> U+8072 kHangul 성:0E
> U+8072 kHanyuPinlu shēng(2269) sheng(57)
> U+8072 kHanyuPinyin 42794.040:shēng
> U+8072 kJapaneseKun KOE
> U+8072 kJapaneseOn SEI SHOU
> U+8072 kKorean SENG
> U+8072 kMandarin shēng
> U+8072 kTang *shiɛng
> U+8072 kVietnamese thanh
> U+8072 kXHC1983 1023.021:shēng
> '''
I don't understand -- you suggest to use all of them?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#53896
; Package
emacs
.
(Sun, 13 Feb 2022 14:19:01 GMT)
Full text and
rfc822 format available.
Message #43 received at 53896 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, 13 Feb 2022, Eli Zaretskii wrote:
>>
>> '''
>> U+8072 kCantonese sing1
>> U+8072 kDefinition sound, voice, noise; tone; music
>> U+8072 kHangul 성:0E
>> U+8072 kHanyuPinlu shēng(2269) sheng(57)
>> U+8072 kHanyuPinyin 42794.040:shēng
>> U+8072 kJapaneseKun KOE
>> U+8072 kJapaneseOn SEI SHOU
>> U+8072 kKorean SENG
>> U+8072 kMandarin shēng
>> U+8072 kTang *shiɛng
>> U+8072 kVietnamese thanh
>> U+8072 kXHC1983 1023.021:shēng
>> '''
>
> I don't understand -- you suggest to use all of them?
>
I see in the *Help* buffer in response to describe-char a section
'''
Unicode data:
Name: <CJK Ideograph>
Category: Letter, Other
Combining class: 0
Bidi category: Left-to-Right
'''
there could be a 'customize what to show' link that adjusts to
include none, any or all of the lines for U+8072 in that section.
--
vl
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#53896
; Package
emacs
.
(Sun, 13 Feb 2022 14:35:02 GMT)
Full text and
rfc822 format available.
Message #46 received at 53896 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, 12 Feb 2022, Eli Zaretskii wrote:
>
> The characters _are_ supported, and we do assign names to them (which
> are trivially derived from their codepoints), so typing their names is
> just an unnecessarily complicated way of typing their codepoint. IOW,
> why not just type 8072 at "C-x 8 RET"s prompt, instead of selecting
> "CJK IDEOGRAPH-8072" from a list of 27,000 candidates?
>
I do use 8072 at the "C-x 8 RET" prompt. The problem is it says:
'''
Insert character (Unicode name or hex): 8072 [No matches]
'''
And, I have to blindly hit RET at that point to insert the U+8072
sign.
What I expect to see is:
'''
Insert character (Unicode name or hex): 8072
聲 CJK UNIFIED IDEOGRAPH 8072
'''
And, I can then either hit RET at the end of 8072 or use the down
arrow key to choose that line underneath.
--
vl
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#53896
; Package
emacs
.
(Sun, 13 Feb 2022 14:55:01 GMT)
Full text and
rfc822 format available.
Message #49 received at 53896 <at> debbugs.gnu.org (full text, mbox):
On Feb 13 2022, Van Ly wrote:
> I do use 8072 at the "C-x 8 RET" prompt. The problem is it says:
>
> '''
> Insert character (Unicode name or hex): 8072 [No matches]
> '''
>
> And, I have to blindly hit RET at that point to insert the U+8072 sign.
Blindly? You see the number you are about to accept.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#53896
; Package
emacs
.
(Sun, 13 Feb 2022 16:38:02 GMT)
Full text and
rfc822 format available.
Message #52 received at 53896 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 13 Feb 2022 14:18:41 +0000 (UTC)
> From: Van Ly <van.ly <at> sdf.org>
> cc: luangruo <at> yahoo.com, 53896 <at> debbugs.gnu.org
>
>
> [1:text/plain Hide]
>
> On Sun, 13 Feb 2022, Eli Zaretskii wrote:
>
> >>
> >> '''
> >> U+8072 kCantonese sing1
> >> U+8072 kDefinition sound, voice, noise; tone; music
> >> U+8072 kHangul 성:0E
> >> U+8072 kHanyuPinlu shēng(2269) sheng(57)
> >> U+8072 kHanyuPinyin 42794.040:shēng
> >> U+8072 kJapaneseKun KOE
> >> U+8072 kJapaneseOn SEI SHOU
> >> U+8072 kKorean SENG
> >> U+8072 kMandarin shēng
> >> U+8072 kTang *shiɛng
> >> U+8072 kVietnamese thanh
> >> U+8072 kXHC1983 1023.021:shēng
> >> '''
> >
> > I don't understand -- you suggest to use all of them?
> >
>
> I see in the *Help* buffer in response to describe-char a section
>
> '''
> Unicode data:
> Name: <CJK Ideograph>
> Category: Letter, Other
> Combining class: 0
> Bidi category: Left-to-Right
> '''
>
> there could be a 'customize what to show' link that adjusts to
> include none, any or all of the lines for U+8072 in that section.
We are mis-communicating. I thought you were talking about
completions on character names in "C-x 8 RET", and I thought you were
suggesting how to provide meaningful names to CJK Ideographs for that
completion. But for that, each character should have a single unique
name.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#53896
; Package
emacs
.
(Sun, 13 Feb 2022 16:39:02 GMT)
Full text and
rfc822 format available.
Message #55 received at 53896 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 13 Feb 2022 14:34:41 +0000 (UTC)
> From: Van Ly <van.ly <at> sdf.org>
> cc: luangruo <at> yahoo.com, 53896 <at> debbugs.gnu.org
>
> > The characters _are_ supported, and we do assign names to them (which
> > are trivially derived from their codepoints), so typing their names is
> > just an unnecessarily complicated way of typing their codepoint. IOW,
> > why not just type 8072 at "C-x 8 RET"s prompt, instead of selecting
> > "CJK IDEOGRAPH-8072" from a list of 27,000 candidates?
> >
>
> I do use 8072 at the "C-x 8 RET" prompt. The problem is it says:
>
> '''
> Insert character (Unicode name or hex): 8072 [No matches]
> '''
>
> And, I have to blindly hit RET at that point to insert the U+8072
> sign.
>
> What I expect to see is:
>
> '''
> Insert character (Unicode name or hex): 8072
> 聲 CJK UNIFIED IDEOGRAPH 8072
> '''
>
> And, I can then either hit RET at the end of 8072 or use the down
> arrow key to choose that line underneath.
How did you know to type "8072" to begin with?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#53896
; Package
emacs
.
(Mon, 14 Feb 2022 14:48:01 GMT)
Full text and
rfc822 format available.
Message #58 received at 53896 <at> debbugs.gnu.org (full text, mbox):
On Sun, 13 Feb 2022, Andreas Schwab wrote:
>>
>> '''
>> Insert character (Unicode name or hex): 8072 [No matches]
>> '''
>>
>> And, I have to blindly hit RET at that point to insert the U+8072 sign.
>
> Blindly? You see the number you are about to accept.
>
The overriding message I see is [No matches] and when I hit RET I
feel like I am ignoring a warning.
--
vl
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#53896
; Package
emacs
.
(Mon, 14 Feb 2022 14:56:02 GMT)
Full text and
rfc822 format available.
Message #61 received at 53896 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, 13 Feb 2022, Eli Zaretskii wrote:
>> Date: Sun, 13 Feb 2022 14:18:41 +0000 (UTC)
>> From: Van Ly <van.ly <at> sdf.org>
>> cc: luangruo <at> yahoo.com, 53896 <at> debbugs.gnu.org
>>
>>
>> [1:text/plain Hide]
>>
>> On Sun, 13 Feb 2022, Eli Zaretskii wrote:
>>
>>>>
>>>> '''
>>>> U+8072 kCantonese sing1
>>>> U+8072 kDefinition sound, voice, noise; tone; music
>>>> U+8072 kHangul 성:0E
>>>> U+8072 kHanyuPinlu shēng(2269) sheng(57)
>>>> U+8072 kHanyuPinyin 42794.040:shēng
>>>> U+8072 kJapaneseKun KOE
>>>> U+8072 kJapaneseOn SEI SHOU
>>>> U+8072 kKorean SENG
>>>> U+8072 kMandarin shēng
>>>> U+8072 kTang *shiɛng
>>>> U+8072 kVietnamese thanh
>>>> U+8072 kXHC1983 1023.021:shēng
>>>> '''
>>>
>>> I don't understand -- you suggest to use all of them?
>>>
>>
>> I see in the *Help* buffer in response to describe-char a section
>>
>> '''
>> Unicode data:
>> Name: <CJK Ideograph>
>> Category: Letter, Other
>> Combining class: 0
>> Bidi category: Left-to-Right
>> '''
>>
>> there could be a 'customize what to show' link that adjusts to
>> include none, any or all of the lines for U+8072 in that section.
>
> We are mis-communicating. I thought you were talking about
> completions on character names in "C-x 8 RET", and I thought you were
> suggesting how to provide meaningful names to CJK Ideographs for that
> completion. But for that, each character should have a single unique
> name.
>
I think I wasn't clear in saying
聲 CJK UNIFIED IDEOGRAPH 8072
is meaningful to me, better than "no match". The tangent to
Unihan_Reading.txt provides more meaning than the address scheme
label "CJK UNIFIED IDEOGRAPH" which to Po Lu is arbitrary and
meaningless. For me, the label
* LINEAR A SIGN
* CJK UNIFIED IDEOGRAPH
puts meaning on the four digit hex value used in Unicode, as it is
being typed
* 8
* 80
* 807
* 8072
--
vl
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#53896
; Package
emacs
.
(Mon, 14 Feb 2022 14:58:01 GMT)
Full text and
rfc822 format available.
Message #64 received at 53896 <at> debbugs.gnu.org (full text, mbox):
On Feb 14 2022, Van Ly wrote:
> On Sun, 13 Feb 2022, Andreas Schwab wrote:
>
>>>
>>> '''
>>> Insert character (Unicode name or hex): 8072 [No matches]
>>> '''
>>>
>>> And, I have to blindly hit RET at that point to insert the U+8072 sign.
>>
>> Blindly? You see the number you are about to accept.
>>
>
> The overriding message I see is [No matches] and when I hit RET I feel
> like I am ignoring a warning.
Plain numbers never have completions.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#53896
; Package
emacs
.
(Mon, 14 Feb 2022 14:58:02 GMT)
Full text and
rfc822 format available.
Message #67 received at 53896 <at> debbugs.gnu.org (full text, mbox):
On Sun, 13 Feb 2022, Eli Zaretskii wrote:
>
> How did you know to type "8072" to begin with?
>
I use the handwriting recognition on the iPhone's Pleco App and
scroll down to the Unicode description for the character and that
contains the number for the Unicode.
--
vl
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#53896
; Package
emacs
.
(Mon, 14 Feb 2022 15:02:02 GMT)
Full text and
rfc822 format available.
Message #70 received at 53896 <at> debbugs.gnu.org (full text, mbox):
On Mon, 14 Feb 2022, Andreas Schwab wrote:
> Plain numbers never have completions.
C-x 8 RET 807 has the completion
LINEAR A SIGN A807
--
vl
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#53896
; Package
emacs
.
(Mon, 14 Feb 2022 15:18:01 GMT)
Full text and
rfc822 format available.
Message #73 received at 53896 <at> debbugs.gnu.org (full text, mbox):
On Feb 14 2022, Van Ly wrote:
> On Mon, 14 Feb 2022, Andreas Schwab wrote:
>
>> Plain numbers never have completions.
>
> C-x 8 RET 807 has the completion
>
> LINEAR A SIGN A807
That's not a plain number, A807 is SYLOTI NAGRI LETTER KO.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#53896
; Package
emacs
.
(Mon, 14 Feb 2022 17:04:02 GMT)
Full text and
rfc822 format available.
Message #76 received at 53896 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 14 Feb 2022 14:57:47 +0000 (UTC)
> From: Van Ly <van.ly <at> sdf.org>
> cc: luangruo <at> yahoo.com, 53896 <at> debbugs.gnu.org
>
> On Sun, 13 Feb 2022, Eli Zaretskii wrote:
>
> >
> > How did you know to type "8072" to begin with?
> >
>
> I use the handwriting recognition on the iPhone's Pleco App and
> scroll down to the Unicode description for the character and that
> contains the number for the Unicode.
Then you don't really need the completion, since you already know the
full codepoint value.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#53896
; Package
emacs
.
(Tue, 15 Feb 2022 01:05:01 GMT)
Full text and
rfc822 format available.
Message #79 received at 53896 <at> debbugs.gnu.org (full text, mbox):
Van Ly <van.ly <at> sdf.org> writes:
> 聲 CJK UNIFIED IDEOGRAPH 8072
>
> is meaningful to me, better than "no match". The tangent to
> Unihan_Reading.txt provides more meaning than the address scheme label
> "CJK UNIFIED IDEOGRAPH" which to Po Lu is arbitrary and meaningless.
Then if that's what you want, you're better served by one of the Chinese
input methods, such as `chinese-py', as opposed to `insert-char'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#53896
; Package
emacs
.
(Tue, 15 Feb 2022 11:14:02 GMT)
Full text and
rfc822 format available.
Message #82 received at 53896 <at> debbugs.gnu.org (full text, mbox):
On Mon, 14 Feb 2022, Andreas Schwab wrote:
>> C-x 8 RET 807 has the completion
>>
>> LINEAR A SIGN A807
>
> That's not a plain number, A807 is SYLOTI NAGRI LETTER KO.
>
People interested in studying Linear A signs will appreciate that more
informative label. IIRC that first hex value has flags indicating the
number of following bytes clump as one Unicode codepoint.
--
vl
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#53896
; Package
emacs
.
(Tue, 15 Feb 2022 11:22:02 GMT)
Full text and
rfc822 format available.
Message #85 received at 53896 <at> debbugs.gnu.org (full text, mbox):
On Mon, 14 Feb 2022, Eli Zaretskii wrote:
>>> How did you know to type "8072" to begin with?
>>>
>>
>> I use the handwriting recognition on the iPhone's Pleco App and
>> scroll down to the Unicode description for the character and that
>> contains the number for the Unicode.
>
> Then you don't really need the completion, since you already know the
> full codepoint value.
I envy the Linear A people who get to have completions. Having the
label "[No matches]" and hitting RET to punch past that for the sign
is better done without that label and leaving the rest of the line
blank after the number. Engineers have a saying, "The best part is no part."
--
vl
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#53896
; Package
emacs
.
(Tue, 15 Feb 2022 11:29:02 GMT)
Full text and
rfc822 format available.
Message #88 received at 53896 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, 15 Feb 2022, Po Lu wrote:
> Van Ly <van.ly <at> sdf.org> writes:
>
>> 聲 CJK UNIFIED IDEOGRAPH 8072
>>
>> is meaningful to me, better than "no match". The tangent to
>> Unihan_Reading.txt provides more meaning than the address scheme label
>> "CJK UNIFIED IDEOGRAPH" which to Po Lu is arbitrary and meaningless.
>
> Then if that's what you want, you're better served by one of the Chinese
> input methods, such as `chinese-py', as opposed to `insert-char'.
I have experimented with about three input methods. Old characters
out of use quail-show-key says the input method is unable to enter
and that is when I fall back to the plain hex number for insert-char.
--
vl
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#53896
; Package
emacs
.
(Tue, 15 Feb 2022 11:34:01 GMT)
Full text and
rfc822 format available.
Message #91 received at 53896 <at> debbugs.gnu.org (full text, mbox):
On Feb 15 2022, Van Ly wrote:
> On Mon, 14 Feb 2022, Andreas Schwab wrote:
>
>>> C-x 8 RET 807 has the completion
>>>
>>> LINEAR A SIGN A807
>>
>> That's not a plain number, A807 is SYLOTI NAGRI LETTER KO.
>>
>
> People interested in studying Linear A signs will appreciate that more
> informative label. IIRC that first hex value has flags indicating the
> number of following bytes clump as one Unicode codepoint.
No, that has nothing to do with the Unicode code point. LINEAR A SIGN
A807 is U+00010767.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#53896
; Package
emacs
.
(Tue, 15 Feb 2022 11:41:01 GMT)
Full text and
rfc822 format available.
Message #94 received at 53896 <at> debbugs.gnu.org (full text, mbox):
Van Ly <van.ly <at> sdf.org> writes:
> I envy the Linear A people who get to have completions. Having the
> label "[No matches]" and hitting RET to punch past that for the sign
> is better done without that label and leaving the rest of the line
> blank after the number. Engineers have a saying, "The best part is no
> part."
If I do this:
C-x 8 RET 8072 RET
There is no "[No matches]" message, so I don't understand what you're
trying to say here.
As such, completions for "CJK UNIFIED IDEOGRAPHs" are meaningless for
both people studying CJK languages and speakers of such languages.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#53896
; Package
emacs
.
(Tue, 15 Feb 2022 21:26:01 GMT)
Full text and
rfc822 format available.
Message #97 received at 53896 <at> debbugs.gnu.org (full text, mbox):
On Tue, 15 Feb 2022, Andreas Schwab wrote:
>> People interested in studying Linear A signs will appreciate that more
>> informative label. IIRC that first hex value has flags indicating the
>> number of following bytes clump as one Unicode codepoint.
>
> No, that has nothing to do with the Unicode code point. LINEAR A SIGN
> A807 is U+00010767.
Yes. I looked it up on the Wikipedia's entry for Linear A. There's
a table copy of the Unicode sheet pertaining.
--
vl
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#53896
; Package
emacs
.
(Tue, 15 Feb 2022 21:31:01 GMT)
Full text and
rfc822 format available.
Message #100 received at 53896 <at> debbugs.gnu.org (full text, mbox):
On Tue, 15 Feb 2022, Po Lu wrote:
> If I do this:
>
> C-x 8 RET 8072 RET
>
> There is no "[No matches]" message,
C-x 8 RET 8072
pops up the "No matches" message before the final RET. That speaks
to me a RET won't help beyond.
--
vl
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#53896
; Package
emacs
.
(Tue, 22 Feb 2022 01:39:02 GMT)
Full text and
rfc822 format available.
Message #103 received at 53896 <at> debbugs.gnu.org (full text, mbox):
Van Ly <van.ly <at> sdf.org> writes:
> The vertical listing in the minibuffer in response to "insert-char"
> fails to preview the match for "C-x 8 RET 8072".
Re-reading this thread, I think the conclusion here is that we don't
want to change how completion works in `C-x 8 RET', so I'm closing this
bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) wontfix.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Tue, 22 Feb 2022 01:39:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
53896 <at> debbugs.gnu.org and Van Ly <van.ly <at> sdf.org>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Tue, 22 Feb 2022 01:39:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 22 Mar 2022 11:24:09 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 86 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.