bug#17702: 24.3; insert-char no longer inserts "bell" control character

bug#17702: 24.3; insert-char no longer inserts "bell" control character

[Ulrich Mueller]

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.

bug#17702: 24.3; insert-char no longer inserts "bell" control character

[Eli Zaretskii]

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

bug#17702: 24.3; insert-char no longer inserts "bell" control character

[Ulrich Mueller]

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

bug#17702: 24.3; insert-char no longer inserts "bell" control character

[Stefan Monnier]

> 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

bug#17702: 24.3; insert-char no longer inserts "bell" control character

[Eli Zaretskii]

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

bug#17702: 24.3; insert-char no longer inserts "bell" control character

[Eli Zaretskii]

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

bug#17702: 24.3; insert-char no longer inserts "bell" control character

[Drew Adams]

[-- 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 --]

bug#17702: 24.3; insert-char no longer inserts "bell" control character

[Josh]

[-- 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 --]

bug#17702: 24.3; insert-char no longer inserts "bell" control character

[Ulrich Mueller]

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

bug#17702: 24.3; insert-char no longer inserts "bell" control character

[Josh]

[-- 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 --]

bug#17702: 24.3; insert-char no longer inserts "bell" control character

[Eli Zaretskii]

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

bug#17702: 24.3; insert-char no longer inserts "bell" control character

[Stefan Monnier]

> 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