* bug#17702: 24.3; insert-char no longer inserts "bell" control character
[not found] ` <<83oay75qhu.fsf@gnu.org>
@ 2014-06-05 17:53 ` Drew Adams
0 siblings, 0 replies; 12+ messages in thread
From: Drew Adams @ 2014-06-05 17:53 UTC (permalink / raw)
To: Eli Zaretskii, Ulrich Mueller; +Cc: 17702
[-- Attachment #1: Type: text/plain, Size: 1216 bytes --]
> > In Emacs 24.3, typing C-x 8 RET bell RET
> > results in character #x1f541 being inserted (which on my system is
> > displayed as a box with text 01F 514 inside).
> >
> > I would expect the command to insert character #x7 (ASCII BEL
> > character, C-g) instead
>
> That's because U+1F541 has "BELL" as its 'name' property, whereas
> u+0007 has "BELL" as its 'old-name' property. Emacs completion picks
> only one from these 2 duplicate candidates.
>
> Perhaps some completion guru could find a way to allow multiple
> candidates with the same name in this case.
FWIW, this is the case with Icicles. See the attached screenshots,
which show, as candidates whose names match the minibuffer input
`bell', seven candidates for substring matching (`S-TAB') and four
candidates for prefix matching (`TAB'). You can see that two of the
chars have exactly the same name, `BELL', with Unicode code points
1F514 and 7.
You can choose a candidate (e.g. the one with code point 7) by
clicking it with the mouse or cycling to it and hitting `RET'.
(The actual chars are also shown, following the code points, but
the default font displays most of these chars as boxes enclosing
the code point).
[-- Attachment #2: throw-icy-bell-char-prefix-only.png --]
[-- Type: image/png, Size: 18254 bytes --]
[-- Attachment #3: throw-icy-bell-char.png --]
[-- Type: image/png, Size: 21599 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#17702: 24.3; insert-char no longer inserts "bell" control character
@ 2014-06-05 14:13 Ulrich Mueller
2014-06-05 15:24 ` Eli Zaretskii
2014-06-05 20:11 ` Josh
0 siblings, 2 replies; 12+ messages in thread
From: Ulrich Mueller @ 2014-06-05 14:13 UTC (permalink / raw)
To: 17702
In Emacs 24.3, typing
C-x 8 RET bell RET
results in character #x1f541 being inserted (which on my system is
displayed as a box with text 01F 514 inside).
I would expect the command to insert character #x7 (ASCII BEL
character, C-g) instead, which is also the behaviour that I get in
Emacs 23.4.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#17702: 24.3; insert-char no longer inserts "bell" control character
2014-06-05 14:13 Ulrich Mueller
@ 2014-06-05 15:24 ` Eli Zaretskii
2014-06-05 16:08 ` Ulrich Mueller
2014-06-05 17:05 ` Stefan Monnier
2014-06-05 20:11 ` Josh
1 sibling, 2 replies; 12+ messages in thread
From: Eli Zaretskii @ 2014-06-05 15:24 UTC (permalink / raw)
To: Ulrich Mueller; +Cc: 17702
> Date: Thu, 5 Jun 2014 16:13:37 +0200
> From: Ulrich Mueller <ulm@gentoo.org>
>
> In Emacs 24.3, typing
> C-x 8 RET bell RET
> results in character #x1f541 being inserted (which on my system is
> displayed as a box with text 01F 514 inside).
>
> I would expect the command to insert character #x7 (ASCII BEL
> character, C-g) instead
That's because U+1F541 has "BELL" as its 'name' property, whereas
u+0007 has "BELL" as its 'old-name' property. Emacs completion picks
only one from these 2 duplicate candidates.
Perhaps some completion guru could find a way to allow multiple
candidates with the same name in this case.
> which is also the behaviour that I get in Emacs 23.4.
Emacs 23.4 supported an earlier version of Unicode, where U+1F541 was
unavailable. IOW, what you see there is sheer luck.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#17702: 24.3; insert-char no longer inserts "bell" control character
2014-06-05 15:24 ` Eli Zaretskii
@ 2014-06-05 16:08 ` Ulrich Mueller
2014-06-05 17:38 ` Eli Zaretskii
2014-06-05 17:05 ` Stefan Monnier
1 sibling, 1 reply; 12+ messages in thread
From: Ulrich Mueller @ 2014-06-05 16:08 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 17702
>>>>> On Thu, 05 Jun 2014, Eli Zaretskii wrote:
> That's because U+1F541 has "BELL" as its 'name' property, whereas
> u+0007 has "BELL" as its 'old-name' property. Emacs completion picks
> only one from these 2 duplicate candidates.
Is there any chance to get this fixed upstream (i.e. to have U+1F514
renamed in Unicode)? It seems obvious that they shouldn't assign
duplicate names, nor reuse names that have been in use for half a
century.
Also, if BELL is an "old-name", what is the new name of the U+0007
character then? (describe-char says <control> which doesn't look like
a proper name at all.)
> Perhaps some completion guru could find a way to allow multiple
> candidates with the same name in this case.
Does this mean that more such duplicates exist?
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#17702: 24.3; insert-char no longer inserts "bell" control character
2014-06-05 16:08 ` Ulrich Mueller
@ 2014-06-05 17:38 ` Eli Zaretskii
2014-06-05 21:26 ` Ulrich Mueller
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2014-06-05 17:38 UTC (permalink / raw)
To: Ulrich Mueller; +Cc: 17702
> Date: Thu, 5 Jun 2014 18:08:43 +0200
> Cc: 17702@debbugs.gnu.org
> From: Ulrich Mueller <ulm@gentoo.org>
>
> >>>>> On Thu, 05 Jun 2014, Eli Zaretskii wrote:
>
> > That's because U+1F541 has "BELL" as its 'name' property, whereas
> > u+0007 has "BELL" as its 'old-name' property. Emacs completion picks
> > only one from these 2 duplicate candidates.
>
> Is there any chance to get this fixed upstream (i.e. to have U+1F514
> renamed in Unicode)?
I wouldn't hold my breath. They've deliberately removed names of the
control characters, as explained clearly in the Unicode Standard. But
you are welcome to ask a question on the Unicode mailing list
unicode@unicode.org.
> Also, if BELL is an "old-name", what is the new name of the U+0007
> character then?
It doesn't have one.
> (describe-char says <control> which doesn't look like a proper name
> at all.)
That was fixed for Emacs v24.4.
> > Perhaps some completion guru could find a way to allow multiple
> > candidates with the same name in this case.
>
> Does this mean that more such duplicates exist?
I don't know; I hope not.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#17702: 24.3; insert-char no longer inserts "bell" control character
2014-06-05 17:38 ` Eli Zaretskii
@ 2014-06-05 21:26 ` Ulrich Mueller
2014-06-05 22:38 ` Josh
0 siblings, 1 reply; 12+ messages in thread
From: Ulrich Mueller @ 2014-06-05 21:26 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 17702
>>>>> On Thu, 05 Jun 2014, Eli Zaretskii wrote:
> I wouldn't hold my breath. They've deliberately removed names of the
> control characters, as explained clearly in the Unicode Standard.
> But you are welcome to ask a question on the Unicode mailing list
> unicode@unicode.org.
I've browsed around and found
http://www.unicode.org/Public/6.3.0/ucd/NameAliases.txt which says:
# Note that no formal name alias for the ISO 6429 "BELL" is
# provided for U+0007, because of the existing name collision
# with U+1F514 BELL.
So it seems that they are aware of the problem already.
>>>>> On Thu, 5 Jun 2014, Josh wrote:
> Is there a reason you can't use `C-q C-g' to insert this character?
Sure, it's not unusual that a task can be performed in Emacs in
several different ways. Is this an excuse for one of them being
imperfect?
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#17702: 24.3; insert-char no longer inserts "bell" control character
2014-06-05 21:26 ` Ulrich Mueller
@ 2014-06-05 22:38 ` Josh
2014-06-06 6:30 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Josh @ 2014-06-05 22:38 UTC (permalink / raw)
To: Ulrich Mueller; +Cc: 17702
[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]
On Thu, Jun 5, 2014 at 2:26 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
> I've browsed around and found
> http://www.unicode.org/Public/6.3.0/ucd/NameAliases.txt which says:
>
> # Note that no formal name alias for the ISO 6429 "BELL" is
> # provided for U+0007, because of the existing name collision
> # with U+1F514 BELL.
>
> So it seems that they are aware of the problem already.
The passage you quoted suggests a possible enhancement to insert-char,
namely adding support for ISO 6429 names in addition to Unicode names,
using suffixes something like "BELL (Unicode)" and "BELL (ISO 6429)" to
disambiguate.
> >>>>> On Thu, 5 Jun 2014, Josh wrote:
>
> > Is there a reason you can't use `C-q C-g' to insert this character?
>
> Sure, it's not unusual that a task can be performed in Emacs in
> several different ways. Is this an excuse for one of them being
> imperfect?
Certainly not, but I thought it possible that you hadn't considered
that approach and might be interested in performing the task with
1/3 the keystrokes :)
[-- Attachment #2: Type: text/html, Size: 2213 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#17702: 24.3; insert-char no longer inserts "bell" control character
2014-06-05 22:38 ` Josh
@ 2014-06-06 6:30 ` Eli Zaretskii
2014-06-06 14:27 ` Stefan Monnier
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2014-06-06 6:30 UTC (permalink / raw)
To: Josh; +Cc: ulm, 17702
> From: Josh <josh@foxtail.org>
> Date: Thu, 5 Jun 2014 15:38:52 -0700
> Cc: Eli Zaretskii <eliz@gnu.org>, 17702@debbugs.gnu.org
>
> The passage you quoted suggests a possible enhancement to insert-char,
> namely adding support for ISO 6429 names in addition to Unicode names,
> using suffixes something like "BELL (Unicode)" and "BELL (ISO 6429)" to
> disambiguate.
There's no need for Emacs to recognize yet another set of names, it
already looks in the 'old-name' property of the characters, and
considers them as completion candidates for "C-x 8 RET".
This is not an issue with missing data; this is an issue with how we
present that data to the user.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#17702: 24.3; insert-char no longer inserts "bell" control character
2014-06-06 6:30 ` Eli Zaretskii
@ 2014-06-06 14:27 ` Stefan Monnier
0 siblings, 0 replies; 12+ messages in thread
From: Stefan Monnier @ 2014-06-06 14:27 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Josh, ulm, 17702-done
> There's no need for Emacs to recognize yet another set of names, it
> already looks in the 'old-name' property of the characters, and
> considers them as completion candidates for "C-x 8 RET".
> This is not an issue with missing data; this is an issue with how we
> present that data to the user.
Upon further investigation, BELL seems to be the only char who doesn't
have a new-name and whose old-name is shadowed by some other char's
new-name. So rather than change the code to handle such situations,
I special-cased BELL.
Stefan
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#17702: 24.3; insert-char no longer inserts "bell" control character
2014-06-05 15:24 ` Eli Zaretskii
2014-06-05 16:08 ` Ulrich Mueller
@ 2014-06-05 17:05 ` Stefan Monnier
2014-06-05 17:35 ` Eli Zaretskii
1 sibling, 1 reply; 12+ messages in thread
From: Stefan Monnier @ 2014-06-05 17:05 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Ulrich Mueller, 17702
> That's because U+1F541 has "BELL" as its 'name' property, whereas
> u+0007 has "BELL" as its 'old-name' property. Emacs completion picks
> only one from these 2 duplicate candidates.
It's not just a question of completion: u+0007 does not seem to have
a "name", and U+1F541 does not seem to have an "old-name", so the only
thing we don't have much to disambiguate the two, and given the "old-"
prefix, we prefer the char whose "name" matches.
I guess we could tweak the table such that u+0007 is provided under
a name like "BELL (old)", but C-x 8 RET BELL RET would still insert
U+1F541 since that's the char named "BELL".
Stefan
^ permalink raw reply [flat|nested] 12+ messages in thread* bug#17702: 24.3; insert-char no longer inserts "bell" control character
2014-06-05 17:05 ` Stefan Monnier
@ 2014-06-05 17:35 ` Eli Zaretskii
0 siblings, 0 replies; 12+ messages in thread
From: Eli Zaretskii @ 2014-06-05 17:35 UTC (permalink / raw)
To: Stefan Monnier; +Cc: ulm, 17702
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Ulrich Mueller <ulm@gentoo.org>, 17702@debbugs.gnu.org
> Date: Thu, 05 Jun 2014 13:05:55 -0400
>
> > That's because U+1F541 has "BELL" as its 'name' property, whereas
> > u+0007 has "BELL" as its 'old-name' property. Emacs completion picks
> > only one from these 2 duplicate candidates.
>
> It's not just a question of completion: u+0007 does not seem to have
> a "name", and U+1F541 does not seem to have an "old-name", so the only
> thing we don't have much to disambiguate the two, and given the "old-"
> prefix, we prefer the char whose "name" matches.
Where in the code do we prefer 'name' to 'old-name'? Perhaps we
shouldn't. (I thought we treated them equally.)
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#17702: 24.3; insert-char no longer inserts "bell" control character
2014-06-05 14:13 Ulrich Mueller
2014-06-05 15:24 ` Eli Zaretskii
@ 2014-06-05 20:11 ` Josh
1 sibling, 0 replies; 12+ messages in thread
From: Josh @ 2014-06-05 20:11 UTC (permalink / raw)
To: Ulrich Mueller; +Cc: 17702
[-- Attachment #1: Type: text/plain, Size: 457 bytes --]
On Thu, Jun 5, 2014 at 7:13 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
> In Emacs 24.3, typing
> C-x 8 RET bell RET
> results in character #x1f541 being inserted (which on my system is
> displayed as a box with text 01F 514 inside).
>
> I would expect the command to insert character #x7 (ASCII BEL
> character, C-g) instead, which is also the behaviour that I get in
> Emacs 23.4.
>
Is there a reason you can't use `C-q C-g' to insert this character?
[-- Attachment #2: Type: text/html, Size: 816 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2014-06-06 14:27 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <<21392.31505.332595.525782@a1i15.kph.uni-mainz.de>
[not found] ` <<83oay75qhu.fsf@gnu.org>
2014-06-05 17:53 ` bug#17702: 24.3; insert-char no longer inserts "bell" control character Drew Adams
2014-06-05 14:13 Ulrich Mueller
2014-06-05 15:24 ` Eli Zaretskii
2014-06-05 16:08 ` Ulrich Mueller
2014-06-05 17:38 ` Eli Zaretskii
2014-06-05 21:26 ` Ulrich Mueller
2014-06-05 22:38 ` Josh
2014-06-06 6:30 ` Eli Zaretskii
2014-06-06 14:27 ` Stefan Monnier
2014-06-05 17:05 ` Stefan Monnier
2014-06-05 17:35 ` Eli Zaretskii
2014-06-05 20:11 ` Josh
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).
![[-- Attachment #2: throw-icy-bell-char-prefix-only.png --] [-- Type: image/png, Size: 18254 bytes --]](../../6fc8f878-80aa-452f-9272-78a6c58cc37b@default/2-throw-icy-bell-char-prefix-only.png){kind=link}
![[-- Attachment #3: throw-icy-bell-char.png --] [-- Type: image/png, Size: 21599 bytes --]](../../6fc8f878-80aa-452f-9272-78a6c58cc37b@default/3-throw-icy-bell-char.png){kind=link}