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

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> 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.

Of course.

>> - 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.

If so, it doesn't apply to the behavior of (get-char-code-property CHAR
'name) which is an internal detail.

>> - "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 "".

Indeed, and that's why I prefer nil: a char's name should be pretty much
unique and descriptive, so "" really isn't a char name, it just means
"this char doesn't have a name" and in Elisp we usually represent this
with nil.

>> So was there some other motivation (e.g. simpler implementation?
> No.

Then please revert it to using nil.

>> 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.

I doubt there will ever be code that can do the above because the ""
case will need special treatment.

So we end comparing things like

  (insert (or (get-char-code-property CHAR 'name) "<Unnamed>"))
with
  (insert (let ((name (get-char-code-property CHAR 'name)))
            (if (equal name "") "<Unnamed>" name)))

where nil is clearly a more convenient choice.

>> 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.


        Stefan