GNU bug report logs - #6576
documentation `string-to-char' is incorrect

Previous Next

Package: emacs;

Reported by: MON KEY <monkey <at> sandpframing.com>

Date: Tue, 6 Jul 2010 21:35:01 UTC

Severity: minor

Done: Chong Yidong <cyd <at> stupidchicken.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: monkey <at> sandpframing.com, schwab <at> linux-m68k.org, 6576 <at> debbugs.gnu.org
Subject: bug#6576: documentation `string-to-char' is incorrect
Date: Thu, 14 Jul 2011 01:50:59 +0200
Eli Zaretskii <eliz <at> gnu.org> writes:

> Actually, there's no way we could return the eight-bit characters in
> the 160 to 255 range, since that range is already taken by Unicode
> codepoints of Latin characters.  So how about
>
>   "Return the codepoint of the first character of STRING.
>
>   Value is the Unicode codepoint, if it is below #x110000 (in hex).
>   Codepoints beyond that are Emacs extensions of Unicode.  In
>   particular, eight-bit characters are returned as codepoints in
>   the range #x3FFF80 through #x3FFFFF, inclusive."

I've now installed a slight variation on this in Emacs 24.

But after checking it in, I started wondering whether this doc string
really makes sense.  The function returns an Emacs character, and it
would be rather weird if all functions that take or return an Emacs
character goes through that entire explanation.

Is there a specific reason this particular function deserves this
detailed explanation?

If not, I'd rather just revert the change I just checked in...

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/




This bug report was last modified 14 years and 2 days ago.

Previous Next


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