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: Sun, 16 Dec 2012 08:31:18 -0800 Message-ID: <30C2FE288AE34DC698FA04B884D98FB3@us.oracle.com> References: <4AF22BD1F38E4AF2A650D1F537B47069@us.oracle.com><8762431shy.fsf@mail.jurta.org><9D74DAC118B44C3DAF75A8CFC6AE7FB3@us.oracle.com><156AF208FCA440DDB10CA4CFBF2815AF@us.oracle.com> <8738z6r8pj.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 1355675521 1383 80.91.229.3 (16 Dec 2012 16:32:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 16 Dec 2012 16:32:01 +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 Sun Dec 16 17:32: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 1TkH8N-00019j-5N for geb-bug-gnu-emacs@m.gmane.org; Sun, 16 Dec 2012 17:32:11 +0100 Original-Received: from localhost ([::1]:36428 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TkH89-0004De-VI for geb-bug-gnu-emacs@m.gmane.org; Sun, 16 Dec 2012 11:31:57 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:52805) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TkH86-0004Ci-88 for bug-gnu-emacs@gnu.org; Sun, 16 Dec 2012 11:31:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TkH84-0002UJ-Sy for bug-gnu-emacs@gnu.org; Sun, 16 Dec 2012 11:31:54 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35186) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TkH84-0002UF-PZ for bug-gnu-emacs@gnu.org; Sun, 16 Dec 2012 11:31:52 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TkH9C-0001Qd-DE for bug-gnu-emacs@gnu.org; Sun, 16 Dec 2012 11:33:02 -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: Sun, 16 Dec 2012 16:33:02 +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.13556755675471 (code B ref 13177); Sun, 16 Dec 2012 16:33:02 +0000 Original-Received: (at 13177) by debbugs.gnu.org; 16 Dec 2012 16:32:47 +0000 Original-Received: from localhost ([127.0.0.1]:45437 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TkH8t-0001Q9-Mu for submit@debbugs.gnu.org; Sun, 16 Dec 2012 11:32:46 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:41791) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TkH8r-0001Pz-6W for 13177@debbugs.gnu.org; Sun, 16 Dec 2012 11:32:42 -0500 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qBGGVTkx003731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 16 Dec 2012 16:31:30 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qBGGVSY3005532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Dec 2012 16:31:29 GMT Original-Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qBGGVStH018454; Sun, 16 Dec 2012 10:31:28 -0600 Original-Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 16 Dec 2012 08:31:28 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <8738z6r8pj.fsf@mail.jurta.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac3bcHWiFMLmjNp+QXazWzgtlu/JZQAOZtNw X-Source-IP: acsinet22.oracle.com [141.146.126.238] 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:68602 Archived-At: > > Great. That's what I would prefer also. And that was exactly what > > I said in the original bug report: that's what the other `read*' > > functions do: return the thing their names say they read. > > `read-char' says it reads a character but it returns 0 (^@) for > invalid characters. I see no reason why 0 would be better than nil. > Using an arbitrary character ^@ for invalid characters makes no sense. OK, perhaps my analogy was too black & white. Let's try to deal with `read-char' exceptions to returning a char in a separate thread. Keep in mind, though, that `read-char' has been around even longer (a lot longer) than `read-char-by-name', so changes would like affect more 3rd-party code. Also, `read-char' returns non-char events, which is why we also have `read-char-exclusive'. Anyway, let's not let my analogy get in the way too much; let's concentrate here on `read-char-by-name' and try to figure out what the best behavior (and then doc) would be. > > So we start with a code bug - make sure it always returns a char. > > Then we fix the doc. Anyway, FWIW you've got my vote in favor of > > fixing the code to always return a char. > > Also in bug#13195 the same request: > > > Seems like `read-char-by-name' should always return something > > that `insert-char' can use, i.e., something that passes > > `characterp'. > > Yes, to always return a valid char or nil, we could check for > `characterp' like in the patch below. Why return nil ever? That's still part of the discussion, AFAIK. nil is not a character.