all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* 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 bug#17702: 24.3; insert-char no longer inserts "bell" control character 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 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 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
       [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 bug#17702: 24.3; insert-char no longer inserts "bell" control character 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

* 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

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 --
2014-06-05 14:13 bug#17702: 24.3; insert-char no longer inserts "bell" control character 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
     [not found] <<21392.31505.332595.525782@a1i15.kph.uni-mainz.de>
     [not found] ` <<83oay75qhu.fsf@gnu.org>
2014-06-05 17:53   ` Drew Adams

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.