GNU bug report logs - #1042
23.0.60; read-char can evaluate to non-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 1042 in the body.
You can then email your comments to 1042 AT debbugs.gnu.org in the normal way.

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

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Markus Triska <markus.triska <at> gmx.at>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.0.60; read-char can evaluate to non-character
Date: Sun, 28 Sep 2008 07:09:36 +0200 (CEST)

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

Message #10 received at 1042 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Markus Triska <markus.triska <at> gmx.at>, 1042 <at> debbugs.gnu.org
Subject: Re: bug#1042: 23.0.60; read-char can evaluate to non-character
Date: Sun, 28 Sep 2008 10:50:12 +0200

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

Message #15 received at 1042 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Markus Triska <markus.triska <at> gmx.at>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 1042 <at> debbugs.gnu.org
Subject: Re: bug#1042: 23.0.60; read-char can evaluate to non-character
Date: Sun, 28 Sep 2008 14:14:55 +0200

martin rudalics <rudalics <at> 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.

Message #20 received at 1042 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Markus Triska <markus.triska <at> gmx.at>
Cc: 1042 <at> debbugs.gnu.org
Subject: Re: bug#1042: 23.0.60; read-char can evaluate to non-character
Date: Mon, 29 Sep 2008 18:38:52 -0400

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

Previous Next

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