GNU bug report logs - #32562
26; `read-char(-exclusive)' and `characterp'

Previous Next

Package: emacs;

Reported by: Drew Adams <drew.adams <at> oracle.com>

Date: Tue, 28 Aug 2018 20:40:02 UTC

Severity: minor

Merged with 1042, 13599

Found in version 24.2

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#1042: closed (23.0.60; read-char can evaluate to non-character)
Date: Mon, 10 Sep 2018 10:02:02 +0000
[Message part 1 (text/plain, inline)]
Your message dated Mon, 10 Sep 2018 13:01:11 +0300
with message-id <83bm95pt7c.fsf <at> gnu.org>
and subject line Re: bug#32562: 26; `read-char(-exclusive)' and `characterp'
has caused the debbugs.gnu.org bug report #32562,
regarding 23.0.60; read-char can evaluate to non-character
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
32562: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=32562
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
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 part 3 (message/rfc822, inline)]
From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: npostavs <at> gmail.com, 32562-done <at> debbugs.gnu.org
Subject: Re: bug#32562: 26; `read-char(-exclusive)' and `characterp'
Date: Mon, 10 Sep 2018 13:01:11 +0300
> Date: Tue, 28 Aug 2018 14:24:36 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 32562 <at> debbugs.gnu.org
> 
> is `read-char' necessarily about chars that satisfy `characterp'?

No.  It returns a character event, not a character.

> The doc string of `text-char-description' says "file-character CHARACTER". What's a "file character"? A character that can appear in a file name?

No, text-char-description accepts only valid character codes, those
which satisfy the 'characterp' test.  This is unlike
single-key-description, which accepts _events_, and thus will happily
process character input events that are not valid character codes,
i.e. fail the 'characterp' test.  I've now made that clear in the
respective doc strings.

> This stuff is not clear more generally, I think - beyond the max value of `max-char'. Do we have or want to have different kinds of "characters" returned from or passed as args to different "character" functions? Why (or why not)?

The basic difference is between a character code and a character input
event.

> Wrt my original problem: taking a value of `M-:' from `read-char' and passing it to `text-char-description', Emacs has a regression of sorts. Older Emacs versions "work", whereas recent versions raise an error. E.g. Emacs 20 `read-char' returns -134217670, and passing that to `text-char-description' gives "\272". Whatever `read-char' can read, it seems, `text-char-description' can describe (perhaps imperfectly?).

It's not a regression: text-char-description wants a valid character
code.

I'm closing this bug, as I think this is a documentation issue which
is now fixed.

Thanks.


This bug report was last modified 6 years and 307 days ago.

Previous Next


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