bug#25641: 25.1; insert-char function inconsistency

bug#25641: 25.1; insert-char function inconsistency

[Pablo Mercader Alcántara]

Im playing with a bat file triying to put a BELL sound when the file
execution is complete and I have a file that has the character so I just
have to copy it into the bat file. But I was curious about how could I
get the char directly from emacs so I did a C-u C-x = and emacs showed
me this:

             position: 7 of 8 (75%), column: 6
            character: C-g (displayed as C-g) (codepoint 7, #o7, #x7)
    preferred charset: ascii (ASCII (ISO646 IRV))
code point in charset: 0x07
               script: latin
               syntax: .     which means: punctuation
             to input: type "C-x 8 RET 7" or "C-x 8 RET BELL"
          buffer code: #x07
            file code: #x07 (encoded by coding system iso-latin-1-dos)
              display: no font available
       hardcoded face: escape-glyph

Character code properties: customize what to show
  old-name: BELL
  general-category: Cc (Other, Control)

There are text properties here:
  fontified            t

I thought "ooh! this is cool I can write this character using its name,
BELL" so I created a new bat file "alarm2.bat" with just one line and
tryed to write the character on that file using C-x 8 RET BELL as the
previous help screen told me, but got a different character. When I do a
C-u C-x = over that character I got this:

             position: 9 of 10 (80%), column: 9
            character: 🔔 (displayed as 🔔) (codepoint 128276,
#o372424, #x1f514)
    preferred charset: unicode (Unicode (ISO10646))
code point in charset: 0x1F514
               script: symbol
               syntax: w     which means: word
             category: .:Base
             to input: type "C-x 8 RET 1f514" or "C-x 8 RET BELL"
          buffer code: #xF0 #x9F #x94 #x94
            file code: not encodable by coding system iso-latin-1-dos
              display: no font available

Character code properties: customize what to show
  name: BELL
  general-category: So (Symbol, Other)
  decomposition: (128276) ('🔔')

There are text properties here:
  fontified            t

Its a different character but it also states that I could write it using
C-x 8 RET BELL. To me that is an inconsistency, because one of the
commands that the help screen showed me was C-x 8 RET BELL and that
clearly doesn't work.



In GNU Emacs 25.1.1 (x86_64-w64-mingw32)
 of 2016-11-15 built on LAPHROAIG
Windowing system distributor 'Microsoft Corp.', version 10.0.10240
Configured using:
 'configure --without-dbus --without-compress-install 'CFLAGS=-O2
 -static -g3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1252

Major mode: Bat

Minor modes in effect:
  diff-auto-refine-mode: t
  shell-dirtrack-mode: t
  yas-global-mode: t
  yas-minor-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
Quit [6 times]

Char: 🔔 (128276, #o372424, #x1f514) point=9 of 10 (80%) column=9
You can run the command ‘rename-buffer’ with M-x ren-b RET
Type "q" in help window to restore previous buffer
You can run the command ‘describe-function’ with C-h f
Type "q" in help window to restore previous buffer
Making completion list...
Quit [2 times]
Making completion list...

Load-path shadows:
c:/Users/pmercader/AppData/Roaming/.emacs.d/elpa/cygwin-mount-20131111.1346/cygwin-mount
hides d:/share/emacs/share/emacs/site-lisp/cygwin/cygwin-mount

Features:
(shadow sort mail-extr emacsbug sendmail iso-transl pp wid-edit
descr-text tutorial vc add-log log-view pcvs-util vc-dispatcher vc-svn
frameset edebug apropos jka-compr ediff-merg ediff-wind ediff-diff
ediff-mult ediff-help ediff-init ediff-util ediff message rfc822 mml
mml-sec epg mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047
rfc2045 ietf-drums mailabbrev mail-utils gmm-utils mailheader calc-help
calc-aent calc-misc calccomp calc-sel info calc-stuff calc-yank
calc-store eieio-opt speedbar sb-image ezimage dframe calc-alg calc-ext
calc-menu calc calc-loaddefs calc-macs bat-mode vc-git diff-mode
easy-mmode dabbrev files-x omnisharp omnisharp-settings
omnisharp-auto-complete-actions omnisharp-server-actions omnisharp-utils
s flycheck find-func rx subr-x etags xref project popup dash flymake
csharp-mode imenu compile cc-mode cc-fonts cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-vars cc-defs macros nxml-uchnm rng-xsd
xsd-regexp rng-cmpct rng-nxml rng-valid rng-loc rng-uri rng-parse
nxml-parse rng-match rng-dt rng-util rng-pttrn nxml-ns nxml-mode
nxml-outln nxml-rap nxml-util nxml-glyph nxml-enc xmltok sql view python
tramp-sh tramp tramp-compat auth-source eieio eieio-core cl-macs
gnus-util mm-util help-fns mail-prsvr password-cache tramp-loaddefs
trampver ucs-normalize shell pcomplete format-spec advice json map
dired-aux dired thingatpt misearch multi-isearch rect edmacro kmacro
setup-cygwin cygwin-mount ange-ftp comint ansi-color ring cl-seq
yasnippet misterioso-theme finder-inf package epg-config windmove ido
seq byte-opt gv bytecomp byte-compile cl-extra help-mode easymenu cconv
cl-loaddefs pcase cl-lib time-date mule-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp
disp-table w32-win w32-vars term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cl-generic cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote w32notify w32 multi-tty
make-network-process emacs)

Memory information:
((conses 16 522627 96926)
 (symbols 56 52480 0)
 (miscs 48 342 935)
 (strings 32 141122 2904)
 (string-bytes 1 3803911)
 (vectors 16 68626)
 (vector-slots 8 1966421 74426)
 (floats 8 1055 909)
 (intervals 56 4040 2404)
 (buffers 976 52))

bug#25641: 25.1; insert-char function inconsistency

[Eli Zaretskii]

> From: Pablo Mercader Alcántara <programingfrik@gmail.com>
> Date: Tue, 7 Feb 2017 09:04:01 -0400
> 
> Character code properties: customize what to show
>   old-name: BELL
>   general-category: Cc (Other, Control)
> [...]
> Character code properties: customize what to show
>   name: BELL
>   general-category: So (Symbol, Other)
>   decomposition: (128276) ('🔔')
> 
> Its a different character but it also states that I could write it using
> C-x 8 RET BELL. To me that is an inconsistency, because one of the
> commands that the help screen showed me was C-x 8 RET BELL and that
> clearly doesn't work.

It's not an inconsistency: the first one has BELL as its "old name"
property (and has no "name" property), the second one as its "name"
property.  This is per Unicode definitions in their character
database, which Emacs uses for this feature.  Unicode removed the
names of low control characters in some version of their standard,
leaving the "old name" behind for compatibility.

Emacs displays "old name" if "name" is missing.

If you type "C-x 8 RET BELL" and hit TAB right after that, Emacs will
tell you this is "complete, but not unique".  Another TAB will pop up
the list of completion candidates, where you will see both BELLs (and
a couple more characters).

I don't think there's a bug here.

Thanks.

bug#25641: 25.1; insert-char function inconsistency

[Stephen Berman]

On Tue, 07 Feb 2017 18:08:48 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Pablo Mercader Alcántara <programingfrik@gmail.com>
>> Date: Tue, 7 Feb 2017 09:04:01 -0400
>> 
>> Character code properties: customize what to show
>>   old-name: BELL
>>   general-category: Cc (Other, Control)
>> [...]
>> Character code properties: customize what to show
>>   name: BELL
>>   general-category: So (Symbol, Other)
>>   decomposition: (128276) ('🔔')
>> 
>> Its a different character but it also states that I could write it using
>> C-x 8 RET BELL. To me that is an inconsistency, because one of the
>> commands that the help screen showed me was C-x 8 RET BELL and that
>> clearly doesn't work.
>
> It's not an inconsistency: the first one has BELL as its "old name"
> property (and has no "name" property), the second one as its "name"
> property.  This is per Unicode definitions in their character
> database, which Emacs uses for this feature.  Unicode removed the
> names of low control characters in some version of their standard,
> leaving the "old name" behind for compatibility.
>
> Emacs displays "old name" if "name" is missing.
>
> If you type "C-x 8 RET BELL" and hit TAB right after that, Emacs will
> tell you this is "complete, but not unique".  Another TAB will pop up
> the list of completion candidates, where you will see both BELLs (and
> a couple more characters).
>
> I don't think there's a bug here.

But as the OP noted, the *Help* buffer for the character #x7 says:

             to input: type "C-x 8 RET 7" or "C-x 8 RET BELL"

yet hitting RET after `C-x RET BELL' only inserts the character #x1f514;
the only way to insert it via `C-x 8' is to hit TAB and then click on
the entry `BELL (BEL)' in the *Completions* buffer.  So the *Help* is at
best misleading.

Steve Berman

bug#25641: 25.1; insert-char function inconsistency

[Pablo Mercader Alcántara]

Ok, I understand both arguments. I think it's a trivial problem too.

I had the problem because the first time I typed exactly what the help
buffer told me. But later I saw that there were different "BELL"
characters with different terminations. The problem is that the
information in the help screen should say C-x 8 RET BELL (BEL) for one
character and C-x 8 RET BELL for the other.

I know its a really small thing. Any way thanks for the fast answer!

2017-02-07 13:04 GMT-04:00 Stephen Berman <stephen.berman@gmx.net>:
> On Tue, 07 Feb 2017 18:08:48 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
>
>>> From: Pablo Mercader Alcántara <programingfrik@gmail.com>
>>> Date: Tue, 7 Feb 2017 09:04:01 -0400
>>>
>>> Character code properties: customize what to show
>>>   old-name: BELL
>>>   general-category: Cc (Other, Control)
>>> [...]
>>> Character code properties: customize what to show
>>>   name: BELL
>>>   general-category: So (Symbol, Other)
>>>   decomposition: (128276) ('🔔')
>>>
>>> Its a different character but it also states that I could write it using
>>> C-x 8 RET BELL. To me that is an inconsistency, because one of the
>>> commands that the help screen showed me was C-x 8 RET BELL and that
>>> clearly doesn't work.
>>
>> It's not an inconsistency: the first one has BELL as its "old name"
>> property (and has no "name" property), the second one as its "name"
>> property.  This is per Unicode definitions in their character
>> database, which Emacs uses for this feature.  Unicode removed the
>> names of low control characters in some version of their standard,
>> leaving the "old name" behind for compatibility.
>>
>> Emacs displays "old name" if "name" is missing.
>>
>> If you type "C-x 8 RET BELL" and hit TAB right after that, Emacs will
>> tell you this is "complete, but not unique".  Another TAB will pop up
>> the list of completion candidates, where you will see both BELLs (and
>> a couple more characters).
>>
>> I don't think there's a bug here.
>
> But as the OP noted, the *Help* buffer for the character #x7 says:
>
>              to input: type "C-x 8 RET 7" or "C-x 8 RET BELL"
>
> yet hitting RET after `C-x RET BELL' only inserts the character #x1f514;
> the only way to insert it via `C-x 8' is to hit TAB and then click on
> the entry `BELL (BEL)' in the *Completions* buffer.  So the *Help* is at
> best misleading.
>
> Steve Berman

bug#25641: 25.1; insert-char function inconsistency

[Stephen Berman]

On Tue, 7 Feb 2017 20:45:43 -0400 Pablo Mercader Alcántara <programingfrik@gmail.com> wrote:

> I had the problem because the first time I typed exactly what the help
> buffer told me. But later I saw that there were different "BELL"
> characters with different terminations. The problem is that the
> information in the help screen should say C-x 8 RET BELL (BEL) for one
> character and C-x 8 RET BELL for the other.

I agree.  The following patch does that (the special-casing here has a
precedent in ucs-names in mule-cmds.el, from which the comment is
copied):

diff --git a/lisp/descr-text.el b/lisp/descr-text.el
index 3971dbb..a1efb67 100644
--- a/lisp/descr-text.el
+++ b/lisp/descr-text.el
@@ -617,7 +617,14 @@ describe-char
 				 "input method")
 			 (list
                           (let ((name
-                                 (or (get-char-code-property char 'name)
+                                 (or (when (= char 7)
+				       ;; Special case for "BELL" which is
+				       ;; apparently the only char which
+				       ;; doesn't have a new name and whose
+				       ;; old-name is shadowed by a newer char
+				       ;; with that name.
+				       (car (rassoc char ucs-names)))
+				     (get-char-code-property char 'name)
                                      (get-char-code-property char 'old-name))))
                             (if (and name (assoc-string name (ucs-names)))
                                 (format

Eli, what do you say?

Steve Berman

bug#25641: 25.1; insert-char function inconsistency

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Date: Wed, 08 Feb 2017 14:15:00 +0100
> Cc: 25641@debbugs.gnu.org
> 
> I agree.  The following patch does that (the special-casing here has a
> precedent in ucs-names in mule-cmds.el, from which the comment is
> copied):
> 
> diff --git a/lisp/descr-text.el b/lisp/descr-text.el
> index 3971dbb..a1efb67 100644
> --- a/lisp/descr-text.el
> +++ b/lisp/descr-text.el
> @@ -617,7 +617,14 @@ describe-char
>  				 "input method")
>  			 (list
>                            (let ((name
> -                                 (or (get-char-code-property char 'name)
> +                                 (or (when (= char 7)
> +				       ;; Special case for "BELL" which is
> +				       ;; apparently the only char which
> +				       ;; doesn't have a new name and whose
> +				       ;; old-name is shadowed by a newer char
> +				       ;; with that name.
> +				       (car (rassoc char ucs-names)))
> +				     (get-char-code-property char 'name)
>                                       (get-char-code-property char 'old-name))))
>                              (if (and name (assoc-string name (ucs-names)))
>                                  (format
> 
> Eli, what do you say?

I don't mind, but ucs-names might be nil if the function by the same
name was not yet called, so I think we should call it first.

Also, I think it would be good to mention this bug report in the
comment.

Thanks.

bug#25641: 25.1; insert-char function inconsistency

[Stephen Berman]

On Wed, 08 Feb 2017 19:54:12 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Date: Wed, 08 Feb 2017 14:15:00 +0100
>> Cc: 25641@debbugs.gnu.org
>> 
>> I agree.  The following patch does that (the special-casing here has a
>> precedent in ucs-names in mule-cmds.el, from which the comment is
>> copied):
>> 
>> diff --git a/lisp/descr-text.el b/lisp/descr-text.el
>> index 3971dbb..a1efb67 100644
>> --- a/lisp/descr-text.el
>> +++ b/lisp/descr-text.el
>> @@ -617,7 +617,14 @@ describe-char
>>  				 "input method")
>>  			 (list
>>                            (let ((name
>> -                                 (or (get-char-code-property char 'name)
>> +                                 (or (when (= char 7)
>> +				       ;; Special case for "BELL" which is
>> +				       ;; apparently the only char which
>> +				       ;; doesn't have a new name and whose
>> +				       ;; old-name is shadowed by a newer char
>> +				       ;; with that name.
>> +				       (car (rassoc char ucs-names)))
>> +				     (get-char-code-property char 'name)
>>                                       (get-char-code-property char 'old-name))))
>>                              (if (and name (assoc-string name (ucs-names)))
>>                                  (format
>> 
>> Eli, what do you say?
>
> I don't mind, but ucs-names might be nil if the function by the same
> name was not yet called, so I think we should call it first.

Oh yes, I should have noticed that.

> Also, I think it would be good to mention this bug report in the
> comment.

Done and pushed to master as 90f76eb.

Steve Berman

bug#25641: 25.1; insert-char function inconsistency

[Pablo Mercader Alcántara]

oooh cool!

thanks again!

2017-02-08 17:43 GMT-04:00 Stephen Berman <stephen.berman@gmx.net>:
> On Wed, 08 Feb 2017 19:54:12 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
>
>>> From: Stephen Berman <stephen.berman@gmx.net>
>>> Date: Wed, 08 Feb 2017 14:15:00 +0100
>>> Cc: 25641@debbugs.gnu.org
>>>
>>> I agree.  The following patch does that (the special-casing here has a
>>> precedent in ucs-names in mule-cmds.el, from which the comment is
>>> copied):
>>>
>>> diff --git a/lisp/descr-text.el b/lisp/descr-text.el
>>> index 3971dbb..a1efb67 100644
>>> --- a/lisp/descr-text.el
>>> +++ b/lisp/descr-text.el
>>> @@ -617,7 +617,14 @@ describe-char
>>>                               "input method")
>>>                       (list
>>>                            (let ((name
>>> -                                 (or (get-char-code-property char 'name)
>>> +                                 (or (when (= char 7)
>>> +                                   ;; Special case for "BELL" which is
>>> +                                   ;; apparently the only char which
>>> +                                   ;; doesn't have a new name and whose
>>> +                                   ;; old-name is shadowed by a newer char
>>> +                                   ;; with that name.
>>> +                                   (car (rassoc char ucs-names)))
>>> +                                 (get-char-code-property char 'name)
>>>                                       (get-char-code-property char 'old-name))))
>>>                              (if (and name (assoc-string name (ucs-names)))
>>>                                  (format
>>>
>>> Eli, what do you say?
>>
>> I don't mind, but ucs-names might be nil if the function by the same
>> name was not yet called, so I think we should call it first.
>
> Oh yes, I should have noticed that.
>
>> Also, I think it would be good to mention this bug report in the
>> comment.
>
> Done and pushed to master as 90f76eb.
>
> Steve Berman

bug#25641: 25.1; insert-char function inconsistency

[Stephen Berman]

On Wed, 8 Feb 2017 18:01:06 -0400 Pablo Mercader Alcántara <programingfrik@gmail.com> wrote:
>
> 2017-02-08 17:43 GMT-04:00 Stephen Berman <stephen.berman@gmx.net>:
[...]
>> Done and pushed to master as 90f76eb.

> oooh cool!
>
> thanks again!

I'll take that as confirmation that the bug can be closed, and have done so.

Steve Berman