GNU bug report logs - #17702
24.3; insert-char no longer inserts "bell" control character

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17702 in the body.
You can then email your comments to 17702 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ulrich Mueller <ulm <at> gentoo.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3; insert-char no longer inserts "bell" control character
Date: Thu, 5 Jun 2014 16:13:37 +0200

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.

Message #8 received at 17702 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ulrich Mueller <ulm <at> gentoo.org>
Cc: 17702 <at> debbugs.gnu.org
Subject: Re: bug#17702: 24.3;
 insert-char no longer inserts "bell" control character
Date: Thu, 05 Jun 2014 18:24:13 +0300

> Date: Thu, 5 Jun 2014 16:13:37 +0200
> From: Ulrich Mueller <ulm <at> 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.

Message #11 received at 17702 <at> debbugs.gnu.org (full text, mbox):

From: Ulrich Mueller <ulm <at> gentoo.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17702 <at> debbugs.gnu.org
Subject: Re: bug#17702: 24.3;
 insert-char no longer inserts "bell" control character
Date: Thu, 5 Jun 2014 18:08:43 +0200

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

Message #14 received at 17702 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Ulrich Mueller <ulm <at> gentoo.org>, 17702 <at> debbugs.gnu.org
Subject: Re: bug#17702: 24.3;
 insert-char no longer inserts "bell" control character
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.

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

Message #17 received at 17702 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: ulm <at> gentoo.org, 17702 <at> debbugs.gnu.org
Subject: Re: bug#17702: 24.3;
 insert-char no longer inserts "bell" control character
Date: Thu, 05 Jun 2014 20:35:05 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Ulrich Mueller <ulm <at> gentoo.org>,  17702 <at> 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.)

Message #20 received at 17702 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ulrich Mueller <ulm <at> gentoo.org>
Cc: 17702 <at> debbugs.gnu.org
Subject: Re: bug#17702: 24.3;
 insert-char no longer inserts "bell" control character
Date: Thu, 05 Jun 2014 20:38:46 +0300

> Date: Thu, 5 Jun 2014 18:08:43 +0200
> Cc: 17702 <at> debbugs.gnu.org
> From: Ulrich Mueller <ulm <at> 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 <at> 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.

Message #23 received at 17702 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Ulrich Mueller <ulm <at> gentoo.org>
Cc: 17702 <at> debbugs.gnu.org
Subject: RE: bug#17702: 24.3;	insert-char no longer inserts "bell" control
 character
Date: Thu, 5 Jun 2014 10:53:40 -0700 (PDT)

[Message part 1 (text/plain, inline)]

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

[throw-icy-bell-char-prefix-only.png (image/png, attachment)]

[throw-icy-bell-char.png (image/png, attachment)]

Message #26 received at 17702 <at> debbugs.gnu.org (full text, mbox):

From: Josh <josh <at> foxtail.org>
To: Ulrich Mueller <ulm <at> gentoo.org>
Cc: 17702 <at> debbugs.gnu.org
Subject: Re: bug#17702: 24.3;
 insert-char no longer inserts "bell" control character
Date: Thu, 5 Jun 2014 13:11:42 -0700

[Message part 1 (text/plain, inline)]

On Thu, Jun 5, 2014 at 7:13 AM, Ulrich Mueller <ulm <at> 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?

[Message part 2 (text/html, inline)]

Message #29 received at 17702 <at> debbugs.gnu.org (full text, mbox):

From: Ulrich Mueller <ulm <at> gentoo.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17702 <at> debbugs.gnu.org
Subject: Re: bug#17702: 24.3;
 insert-char no longer inserts "bell" control character
Date: Thu, 5 Jun 2014 23:26:18 +0200

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

Message #32 received at 17702 <at> debbugs.gnu.org (full text, mbox):

From: Josh <josh <at> foxtail.org>
To: Ulrich Mueller <ulm <at> gentoo.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 17702 <at> debbugs.gnu.org
Subject: Re: bug#17702: 24.3;
 insert-char no longer inserts "bell" control character
Date: Thu, 5 Jun 2014 15:38:52 -0700

[Message part 1 (text/plain, inline)]

On Thu, Jun 5, 2014 at 2:26 PM, Ulrich Mueller <ulm <at> 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 :)

[Message part 2 (text/html, inline)]

Message #35 received at 17702 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Josh <josh <at> foxtail.org>
Cc: ulm <at> gentoo.org, 17702 <at> debbugs.gnu.org
Subject: Re: bug#17702: 24.3;
 insert-char no longer inserts "bell" control character
Date: Fri, 06 Jun 2014 09:30:17 +0300

> From: Josh <josh <at> foxtail.org>
> Date: Thu, 5 Jun 2014 15:38:52 -0700
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 17702 <at> 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.

Message #40 received at 17702-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Josh <josh <at> foxtail.org>, ulm <at> gentoo.org, 17702-done <at> debbugs.gnu.org
Subject: Re: bug#17702: 24.3;
 insert-char no longer inserts "bell" control character
Date: Fri, 06 Jun 2014 10:27:08 -0400

> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.