From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#13177: 24.3.50; doc of `read-char-by-name' Date: Sat, 15 Dec 2012 07:52:51 -0800 Message-ID: References: <4AF22BD1F38E4AF2A650D1F537B47069@us.oracle.com> <8762431shy.fsf@mail.jurta.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1355586842 6360 80.91.229.3 (15 Dec 2012 15:54:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 15 Dec 2012 15:54:02 +0000 (UTC) Cc: 13177@debbugs.gnu.org To: "'Juri Linkov'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Dec 15 16:54:15 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Tju47-0008RO-Ch for geb-bug-gnu-emacs@m.gmane.org; Sat, 15 Dec 2012 16:54:15 +0100 Original-Received: from localhost ([::1]:44795 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tju3u-0001ue-B3 for geb-bug-gnu-emacs@m.gmane.org; Sat, 15 Dec 2012 10:54:02 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:45525) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tju3r-0001uM-Bl for bug-gnu-emacs@gnu.org; Sat, 15 Dec 2012 10:54:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tju3q-00039O-6F for bug-gnu-emacs@gnu.org; Sat, 15 Dec 2012 10:53:59 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:33986) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tju3q-00039K-2Y for bug-gnu-emacs@gnu.org; Sat, 15 Dec 2012 10:53:58 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Tju4r-0008Mn-T7 for bug-gnu-emacs@gnu.org; Sat, 15 Dec 2012 10:55:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 15 Dec 2012 15:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13177 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 13177-submit@debbugs.gnu.org id=B13177.135558684832096 (code B ref 13177); Sat, 15 Dec 2012 15:55:01 +0000 Original-Received: (at 13177) by debbugs.gnu.org; 15 Dec 2012 15:54:08 +0000 Original-Received: from localhost ([127.0.0.1]:44237 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tju3z-0008Lc-Qu for submit@debbugs.gnu.org; Sat, 15 Dec 2012 10:54:08 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:37483) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tju3x-0008LV-O8 for 13177@debbugs.gnu.org; Sat, 15 Dec 2012 10:54:06 -0500 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qBFFqxJW030116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 15 Dec 2012 15:53:00 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qBFFqxew006738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Dec 2012 15:52:59 GMT Original-Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qBFFqwvu028366; Sat, 15 Dec 2012 09:52:59 -0600 Original-Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 15 Dec 2012 07:52:58 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <8762431shy.fsf@mail.jurta.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac3atVVh2/8mzRa/Qa6kwGbbY3hH2wAIcsqA X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:68567 Archived-At: > > Dunno just what the intention was for this function. If it really > > was to return a recognized Unicode character then this is a product > > bug and reading should not end until the user enters matching input > > (or hits `C-g'). > > As its docstring says, it also accepts a hexadecimal number > of Unicode code whose input can't use completion. Yes, I know. But the doc string also says that the hex numbers accepted are those corresponding to Unicode code points. And it mentions hash notation for numbers, but in that case it does not say that those numbers too must correspond to Unicode code points. The question I posed is whether the intention was to always return a recognized Unicode char. If that is the case then the function should never return nil or anything else (e.g. a non code-point number) other than a Unicode char. It's an open question. If you are answering for the design intention, stating that the intention is not to do what the doc currently says (always return a Unicode char), then fine. In that case, all that's needed is a doc-string patch, to point out that exception to its general statement. However (see below), that exception needs to be clarified in the case of hash notation input that does not correspond to a Unicode char. > +When input is neither a known Unicode name nor a hex number string, > +return nil." It is not enough, according to the existing doc string, for input to be any old hex number - it must be a "hexadecimal number of Unicode code point" - or presumably we return nil (?). The additional info should say this (or equivalent): "Return nil if the input does not correspond to a Unicode character." The doc string should also be corrected to not give the impression that hash notation input somehow escapes this need for the number to represent a character, i.e., to be numerically equivalent to "a hexadecimal number of Unicode code point". So we should replace the last paragraph of the doc string with something like this: "Besides a Unicode character name, input can represent a Unicode character numerically. It can be a hexadecimal number or a number in hash notation, e.g. #o21430 for octal, #x2318 for hex, or #10r8984 for decimal." Follow that with the statement above that _any other_ input, i.e., any input that does not correspond to a recognized Unicode char, means return nil. Then things will be clear. Otherwise, we are not saying anything about what is returned if the input hash notation does not correspond to a Unicode char - a doc bug. If, on the other hand, it is not the case that the function returns nil for hash notation input that does not correspond to a known character, then the doc should say that clearly. In that case, the function has two exceptions to returning a Unicode character: 1. Return nil if a name is entered that is not a recognized name. 2. Return a number if hash notation is entered that does not match a Unicode code point. I cannot speak for what the function is supposed to do (design), so I cannot say whether there is a code bug or a doc bug here. I can only outline the possibilities.