From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.bugs Subject: bug#9653: 24.0.50; `ucs-names' - Why all of the ("" . XXX) entries? Date: Tue, 04 Oct 2011 10:59:55 +0900 Message-ID: References: <74B14D2A03144E798C9415172D5FE01A@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1317693645 4380 80.91.229.12 (4 Oct 2011 02:00:45 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 4 Oct 2011 02:00:45 +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 Tue Oct 04 04:00:41 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 1RAuJF-0008Aa-4r for geb-bug-gnu-emacs@m.gmane.org; Tue, 04 Oct 2011 04:00:41 +0200 Original-Received: from localhost ([::1]:34616 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RAuJE-0007Ps-Ps for geb-bug-gnu-emacs@m.gmane.org; Mon, 03 Oct 2011 22:00:40 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:42984) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RAuJB-0007OF-8z for bug-gnu-emacs@gnu.org; Mon, 03 Oct 2011 22:00:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RAuJA-00047B-3s for bug-gnu-emacs@gnu.org; Mon, 03 Oct 2011 22:00:37 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:39370) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RAuJA-000477-2J for bug-gnu-emacs@gnu.org; Mon, 03 Oct 2011 22:00:36 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RAuKX-0006TT-Qm for bug-gnu-emacs@gnu.org; Mon, 03 Oct 2011 22:02:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Kenichi Handa Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 04 Oct 2011 02:02: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.131769369224851 (code B ref 9653); Tue, 04 Oct 2011 02:02:01 +0000 Original-Received: (at 9653) by debbugs.gnu.org; 4 Oct 2011 02:01:32 +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 1RAuK2-0006Sl-LP for submit@debbugs.gnu.org; Mon, 03 Oct 2011 22:01:31 -0400 Original-Received: from mx1.aist.go.jp ([150.29.246.133]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RAuJy-0006SW-5Q for 9653@debbugs.gnu.org; Mon, 03 Oct 2011 22:01:29 -0400 Original-Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id p941xuoB022199; Tue, 4 Oct 2011 10:59:56 +0900 (JST) env-from (handa@m17n.org) Original-Received: from smtp1.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id p941xt2I026937; Tue, 4 Oct 2011 10:59:55 +0900 (JST) env-from (handa@m17n.org) Original-Received: by smtp1.aist.go.jp with ESMTP id p941xtb1029269; Tue, 4 Oct 2011 10:59:55 +0900 (JST) env-from (handa@m17n.org) In-Reply-To: (message from Stefan Monnier on Mon, 03 Oct 2011 09:31:29 -0400) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Mon, 03 Oct 2011 22:02:01 -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:52138 Archived-At: In article , Stefan Monnier writes: > > * For miscellaneous properties which take strings as > > values, such as the Unicode Name property, the default > > value is a null string. > > ^^^^^^^^^^^^^ > I'm not opposed to this change, but your answer surprises me: > - we don't have to follow any standard. But, it is better to follow a standard, especially an important one as Unicode. > - even less so when it talks about internal APIs rather than about > externally-visible behavior. I think that UCD is talking about external visible behaviour. Unicode says that all characters have `Name' property and each value is a string. So, when you ask a name of a specific character, you should always get a string value. > - "null string" can mean nil just as well as it can mean "". But, as I wrote, nil usually means no-value/not-specified/unassigned/unknown, which is different from the explicit "". > They actually behave quite similarly: length/concat/mapcar treat them > the same, aref signals an error in both cases, ... Similar but different. I think the difference is bigger. insert/string-match/search-forward/etc. signal an error on nil argument. And these two signals the different error; wrong-type-argument vs. args-out-of-range. (aref nil 1) (aref "" 1) > So was there some other motivation (e.g. simpler implementation? No. > Simpler code somewhere else?)? Yes, hypothetically. You can safely write, for instance, (search-forward (get-char-code-property CHAR 'name) ...) or (insert (get-char-code-property CHAR 'name) ...) without checking the return value. > If not (i.e. all things being equal) I'd > prefer to use nil which is ever so slightly closer to usual Elisp > practice, Really? I've thought nil and "" are rather different object in Elisp. In a char-table, (aset CHAR-TABLE CHAR nil) results in that (aref CHAR-TABLE CHAR) returns the default value which may not be nil. > and matches the Emacs-23 behavior. I'm sorry for this incomaptible change. As I wrote before, when I first implemented UCD in Emacs, the Unicode was not clear about the property value of a character not explicitly listed in the database file. So, at that time, I simply selected nil as the default value. But, recently I found that the default value is clearly defined in the recent versions of Unicode. So, if you the emacs maintainer thinks that the backward compatibility is more important, I don't oppose to change the default value back to nil. --- Kenichi Handa handa@m17n.org