bug#9653: 24.0.50; `ucs-names' - Why all of the ("" . XXX) entries?

[Eli Zaretskii <eliz@gnu.org>]

> From: Kenichi Handa <handa@m17n.org>
> Date: Wed, 05 Oct 2011 17:59:06 +0900
> Cc: 9653@debbugs.gnu.org
> 
> I think what get-char-code-proeprty returns belongs to an
> external API, and currently I put this docstring to `name'
> property.
> 
> "Unicode character name.
> Property value is a string."

Right, and the same is in the ELisp manual:

  `name'
       Corresponds to the `Name' Unicode property.  The value is a string
       consisting of upper-case Latin letters A to Z, digits, spaces, and
       hyphen `-' characters.  For unassigned codepoints, the value is an
       empty string.

A similar verbiage is there for old-name.

> I'll repeat that when one want to know what Unicode says
> about the name of a character, the answer is "", not
> "<Unnamed>".

Correct.

> > >> 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.
> > 
> > Of course they are, nil usually means "not found" or something like
> > that, and I think it suits this case perfectly.
> 
> I'm not sure because there are multiple use-cases of
> get-char-code-property, and nil is better only in some of
> them.  But, it's just "I'm not sure".  If you are sure, as I
> wrote above, I'll change it back.

FWIW, I'm not sure, either.  Stefan, can you please provide "heavier"
arguments than just what's been written in this thread?

If the issue is just to filter the empty names from what ucs-names
returns, we can do that with either nil or empty strings.  But let's
also think about other users of get-char-code-property, such as
what-cursor-position etc., where we will now need to display an empty
string when we get nil.  By contrast, the way get-char-code-property
is coded now its results are ready to be displayed in a manner that is
entirely consistent with the requirements of the Unicode standard, and
not really getting in the way of Emacs.  So it is unclear to me why we
should disregard the standard's guidance in this particular case.