all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: <9653@debbugs.gnu.org>
Subject: bug#9653: 24.0.50; `ucs-names' - Why all of the ("" . XXX) entries?
Date: Sun, 2 Oct 2011 10:38:43 -0700	[thread overview]
Message-ID: <3EB320EE64B3419489F05F06AE8B3486@us.oracle.com> (raw)
In-Reply-To: <74B14D2A03144E798C9415172D5FE01A@us.oracle.com>

(Not claiming this additional question relates to a bug, in particular to this
bug report - except in so far as it asks for better doc.)

In `ucs-names', what are the CHAR-NAMEs "VARIATION SELECTOR-n" all about (for
n=17...256)?  Are those actually character names?

Googling indicates that a variation selector is a metacharacter that selects one
of a set of semantically equivalent glyphs.  

I no doubt do not fully understand (even after scanning the Unicode standard,
http://unicode.org/reports/tr28/tr28-3.html#13_7_variation_selectors and this:
http://babelstone.blogspot.com/2007/06/secret-life-of-variation-selectors.html
about it).  I can, however, see the difference variation selectors can make,
e.g. here: http://www.w3.org/TR/xml-entity-names/U0FE00.html.

But why are the "VARIATION SELECTOR-n" included as CHAR-NAMEs in `ucs-names'?
IIUC, variant selectors, when used, follow characters whose
representations/appearance they modify in some sense.

Why do we treat variation selectors, in `ucs-names', as "character names", if
they are only "metacharacters", "combining marks" used to indicate how to change
the appearance of the characters they follow?

I see that the Unicode standard also refers to variation selectors as "default
ignorable characters", so I guess they are characters in some sense.

But how about providing a function that filters out all such "ignorable
characters" from `ucs-names', or how about at least providing a list of all such
chars.

I see this in the standard too: "If a user requires a visual distinction between
a character and a particular variant of that character, then fonts must be used
to make that distinction."

The "variation selector" information seems to be only about visual appearance,
not about names of displayable characters.  Does it really belong in
`ucs-names'?

And I see that such "ignorable" stuff is apparently supposed to be invisible -
e.g., "default_ignorable_code points...are invisible, have no glyph...".  If so,
how about a function that filters out all such invisible stuff from `ucs-names'
(or at least a list of such stuff).

How about a little more doc for `ucs-names', so that any programmer who might
want to use `ucs-names' (e.g. for completion) might know how to reasonably
use/deal with such  particular CHAR-NAMEs.  Please do not simply say that
`ucs-names' is only "internal" so you need not describe it better.  It's already
being used in various 3rd-party code.

Again, this is not really part of this bug report (which is only about "" as a
CHAR-NAME), unless you see that it is related (e.g. wrt doc).  But I would like
to know more about the "ignorable characters" - how to recognize them etc. so
that I can (optionally, at least) remove them as completion candidates.

I understand that the Emacs doc does not have as its purpose to teach the
details of the Unicode standard, but perhaps a little more explanation of the
content of `ucs-names' wouldn't hurt?






  reply	other threads:[~2011-10-02 17:38 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <<74B14D2A03144E798C9415172D5FE01A@us.oracle.com>
     [not found] ` <<tl7fwe65odg.fsf@m17n.org>
2011-10-02 16:36   ` bug#9653: 24.0.50; `ucs-names' - Why all of the ("" . XXX) entries? Drew Adams
2011-10-02 17:38     ` Drew Adams [this message]
2011-10-02 22:31       ` Juanma Barranquero
2011-10-02 22:51         ` Drew Adams
2011-10-02 22:55           ` Juanma Barranquero
2011-10-03 13:20           ` Jason Rumney
2011-10-03 13:56             ` Drew Adams
2011-10-03 14:00               ` Juanma Barranquero
2011-10-02 18:09     ` Thierry Volpiatto
2011-10-03  1:28     ` Stefan Monnier
2011-10-03  4:23       ` Kenichi Handa
2011-10-03  8:22         ` Andreas Schwab
2011-10-04  1:14           ` Kenichi Handa
2011-10-03 13:31         ` Stefan Monnier
2011-10-04  1:59           ` Kenichi Handa
2011-10-04 12:56             ` Stefan Monnier
2011-10-06  3:53             ` Kevin Rodgers
2011-10-06 12:19               ` Juanma Barranquero
2011-10-06 13:02                 ` Andreas Schwab
2011-10-06 13:47                   ` Juanma Barranquero
2011-10-06 14:01                     ` Andreas Schwab
2011-10-06 14:02                       ` Juanma Barranquero
2011-10-04  2:19         ` Drew Adams
2011-10-04  4:02           ` Kenichi Handa
2011-10-04 13:43             ` Drew Adams
2011-10-04 17:34               ` Drew Adams
2011-10-04 18:19                 ` Eli Zaretskii
2011-10-04 18:30                   ` Drew Adams
2011-10-04 20:55                     ` Eli Zaretskii
2011-10-04 21:39                     ` Stefan Monnier
2011-10-04 22:03                       ` Drew Adams
2011-10-05  4:11                         ` Eli Zaretskii
2011-10-05 13:20                           ` Drew Adams
2011-10-05 17:24                             ` Eli Zaretskii
2011-10-05  8:59     ` Kenichi Handa
2011-10-05 10:20       ` Eli Zaretskii
2011-10-05 12:40         ` Stefan Monnier
2011-10-06 18:02           ` Eli Zaretskii
2011-10-06 20:56             ` Stefan Monnier
2012-01-14 18:35               ` Drew Adams
2012-02-17 15:55     ` Drew Adams
2018-02-13 23:35     ` Drew Adams
2018-02-15  1:11       ` Noam Postavsky
2018-02-15  3:17         ` Drew Adams
     [not found] <tl74nupdi7g.fsf@m17n.org>
2012-02-17 15:25 ` Stefan Monnier
     [not found]   ` <7CCDEE21B0ED42B097600BB24692952A@us.oracle.com>
2012-02-17 23:42     ` Stefan Monnier
2012-02-18  0:05       ` Drew Adams
     [not found]         ` <8339a8wp2m.fsf@gnu.org>
2012-02-18 19:08           ` Drew Adams
2012-02-20  0:39   ` Kenichi Handa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3EB320EE64B3419489F05F06AE8B3486@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=9653@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.