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#9653: 24.0.50; `ucs-names' - Why all of the ("" . XXX) entries? Date: Tue, 4 Oct 2011 15:03:27 -0700 Message-ID: <15EC7D84019545E980B6E4C35CEC84EC@us.oracle.com> References: <83sjn8r553.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1317765880 31607 80.91.229.12 (4 Oct 2011 22:04:40 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 4 Oct 2011 22:04:40 +0000 (UTC) Cc: 9653@debbugs.gnu.org To: "'Stefan Monnier'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 05 00:04:36 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RBD6J-0002nb-W1 for geb-bug-gnu-emacs@m.gmane.org; Wed, 05 Oct 2011 00:04:36 +0200 Original-Received: from localhost ([::1]:59888 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBD6J-0007T8-Dt for geb-bug-gnu-emacs@m.gmane.org; Tue, 04 Oct 2011 18:04:35 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:53656) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBD6G-0007T3-Eq for bug-gnu-emacs@gnu.org; Tue, 04 Oct 2011 18:04:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RBD6F-0002Y9-5x for bug-gnu-emacs@gnu.org; Tue, 04 Oct 2011 18:04:32 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34607) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBD6F-0002Y4-39 for bug-gnu-emacs@gnu.org; Tue, 04 Oct 2011 18:04:31 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RBD7i-0005mr-0q for bug-gnu-emacs@gnu.org; Tue, 04 Oct 2011 18:06:02 -0400 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: Tue, 04 Oct 2011 22:06:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9653 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 9653-submit@debbugs.gnu.org id=B9653.131776590822174 (code B ref 9653); Tue, 04 Oct 2011 22:06:01 +0000 Original-Received: (at 9653) by debbugs.gnu.org; 4 Oct 2011 22:05:08 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RBD6q-0005lb-JJ for submit@debbugs.gnu.org; Tue, 04 Oct 2011 18:05:08 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RBD6o-0005lT-2I for 9653@debbugs.gnu.org; Tue, 04 Oct 2011 18:05:07 -0400 Original-Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p94M3VPL007773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Oct 2011 22:03:33 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p94M3Ucf018012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Oct 2011 22:03:31 GMT Original-Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p94M3PWd013985; Tue, 4 Oct 2011 17:03:25 -0500 Original-Received: from dradamslap1 (/10.159.58.205) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 Oct 2011 15:03:24 -0700 X-Mailer: Microsoft Office Outlook 11 In-reply-to: Thread-Index: AcyC3hq/+BPa4Ef1RjyAjMKJSsx9HQAAMvag X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090207.4E8B82B6.001D,ss=1,re=0.000,fgs=0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Tue, 04 Oct 2011 18:06:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) 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:52188 Archived-At: > > whether and why we want to have such unnamed > > characters in `ucs-names'. That's all. How those names > > happen to be there has never been in question. > > I'd have hoped my message #23 > (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9653#23) > made it all clear already. We're just discussing how to fix > the problem. Well, sort of, but I didn't have the impression that the question was really closed, that you do indeed want to "filter out those useless entries", and that you had moved on to how to filter them. In any case, as you point out, message #23 already showed "how" the list gets populated, which Eli repeated. Your subsequent discussion of whether to use "" or nil to represent an empty name (no name) didn't do much to further the impression that you really wanted to filter out such entries. If they are to be removed from `ucs-names', what difference does it make how you choose to represent them temporarily? Be that as it may, I have a further question about this. Currently the only use of `ucs-names' in the Emacs source code is in `read-char-by-name', and in that context the 49,368 empty names are not even available to users as character choices. That is, the empty _names_ are not available as completion targets, but their characters, and the alist entries with empty names, are still available to users, because a user can alternatively enter a character code (not a name). It is that, in part, that made me wonder whether you might really be wanting to keep such empty-name entries. I supposed, however, that each empty-name alist entry has an alter-ego entry that has the same code point but also has a non-empty name: e.g. ("" . 32) & ("SPACE" . 32). If that were the case, then I would see no use by `read-char-by-name' for the empty-name entries. Users of `read-char-by-name' would never see or touch a character that has no name (has an empty name), unless it were by entering a code point that also corresponds to a character that also has a name. That was my impression until I verified just now. I see in fact that there are some `ucs-names' entries that, yes, constitute a pair with the same character code, yet _both_ are empty. E.g., ("" . 11565) & ("" . 11565). So do we want to keep empty-name entries perhaps for that reason: because there are some characters that have no name (old or new), and we want users to be able to read them (e.g. to insert them using `ucs-insert') by giving their char codes? To me it still looks like an open question.