bug#1042: 23.0.60; read-char can evaluate to non-character

bug#1042: 23.0.60; read-char can evaluate to non-character

[Markus Triska]

In "$ emacs -Q", when I evaluate:

   (read-char)

and press C-0, I get:

   67108912

However, (characterp 67108912) is nil, and (char-to-string 67108912)
throws an error. Thus I expect an error also from read-char in this
case. Besides, in `char-resolve-modifers', "modifiers" is misspelled.

In GNU Emacs 23.0.60.1 (i386-apple-darwin8.11.1, GTK+ Version 2.12.9)
 of 2008-09-24 on mt-computer.local
Windowing system distributor `The XFree86 Project, Inc', version 11.0.40400000
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_GB.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: nil
  default-enable-multibyte-characters: t

bug#1042: 23.0.60; read-char can evaluate to non-character

[martin rudalics]

 > In "$ emacs -Q", when I evaluate:
 >
 >    (read-char)
 >
 > and press C-0, I get:
 >
 >    67108912
 >
 > However, (characterp 67108912) is nil, and (char-to-string 67108912)
 > throws an error. Thus I expect an error also from read-char in this
 > case.

The doc-string of `read-char' says

     If the character has modifiers, they are resolved and reflected to the
     character code if possible (e.g. C-SPC -> 0).

Do you have a particular use case that calls for throwing an error here?

 > Besides, in `char-resolve-modifers', "modifiers" is misspelled.

I fixed that.

Thanks, martin.

bug#1042: 23.0.60; read-char can evaluate to non-character

[Markus Triska]

martin rudalics <rudalics@gmx.at> writes:

> The doc-string of `read-char' says

C-SPC (= 0) is different from C-0: (characterp 0) is t, and
(char-to-string 0) evaluates to a string; i.e., it is a character.

> Do you have a particular use case that calls for throwing an error
> here?

I relied on `read-char' evaluating to a character in ediprolog:

   http://www.logic.at/prolog/ediprolog/ediprolog.html

On l.352, I read a character from the user and use `char-to-string' to
send it to the Prolog process as string. If the user generates an event
that is not a character, it should not be sent to the Prolog process,
and a usage note is displayed instead.

Thus, I can work around the current behaviour of `read-char' by also
guarding `char-to-string' against errors, or using the now obsolete
`char-valid-p' for Emacs 22, and `characterp' for later versions.
However, it would be nice if `read-char' always yielded a character.

bug#1042: 23.0.60; read-char can evaluate to non-character

[Chong Yidong]

> it would be nice if `read-char' always yielded a character.

This may be true, but let's discuss this after the release.  Making such
a change right now would be dangerous.