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

[Drew Adams]

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