bug#36717: 25.3; greek.el: deprecated vowel+oxia combinations should be replaced with vowel+tonos counterparts

[Robert Pluim <rpluim@gmail.com>]

>>>>> On Fri, 19 Jul 2019 15:49:31 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: Robert Alessi <alessi@robertalessi.net>,  36717@debbugs.gnu.org
    >> Date: Fri, 19 Jul 2019 10:27:35 +0200
    >> 
    >> >>>>> On Fri, 19 Jul 2019 09:57:38 +0300, Eli Zaretskii <eliz@gnu.org> said:
    >> 
    Eli> We could ask on the Unicode mailing list.  There are Unicode experts
    Eli> there, and they are quite friendly.  If someone can come up with a
    Eli> comprehensive description of our situation and the issues we are
    Eli> trying to resolve, please write to unicode@unicode.org, and ask the
    Eli> questions.
    >> 
    >> I think reading <https://www.unicode.org/faq/greek.html> helps
    >> some.

    Eli> It didn't help me, FWIW.

    >> My understanding of the situation is that the basic Greek block
    >> should be used, rather than the extended Greek block, for the LETTER +
    >> OXIA/TONOS combinations (and the extended block versions all decompose
    >> to characters in the basic block + a combining mark).

Iʼm wrong about that bit in the parentheses, at least within Emacs. I
should have said

"decompose to characters in the basic block, which in turn decompose
to a base character + a combining mark", ie

GREEK SMALL LETTER IOTA WITH OXIA has decomposition
GREEK SMALL LETTER IOTA WITH TONOS which has decomposition
GREEK SMALL LETTER IOTA + COMBINING ACUTE ACCENT

    Eli> That's unrelated to the issue at hand, AFAIU.  It is relevant to how
    Eli> you set up your fonts, but not how our input methods should work.  The
    Eli> point there is that by using the Greek Extended block, you request the
    Eli> precomposed glyphs from the font, which may or may not be according to
    Eli> what you want; whereas by using base characters followed by combining
    Eli> marks you leave it to the rendering system to select the glyph.  But
    Eli> we should always keep in mind that the shaping engine we use can (and
    Eli> usually does) decide to use a precomposed glyph even when we type the
    Eli> character in its decomposed form.  So this is not really relevant to
    Eli> our issue here.

Now you've confused me (or Iʼve been unclear). The relevant characters
in the Greek basic block do not result in glyph composition:

C-u C-x = on ί =>

             position: 2893 of 3607 (80%), restriction: <411-3608>, column: 13
            character: ί (displayed as ί) (codepoint 943, #o1657, #x3af)
              charset: unicode (Unicode (ISO10646))
code point in charset: 0x03AF
               script: greek
               syntax: w 	which means: word
             category: .:Base, L:Left-to-right (strong), g:Greek, j:Japanese
             to input: type "C-x 8 RET 3af" or "C-x 8 RET GREEK SMALL LETTER IOTA WITH TONOS"
          buffer code: #xCE #xAF
            file code: #xCE #xAF (encoded by coding system utf-8-emacs)
              display: by this font (glyph code)
    mac-ct:-*-Hack-normal-normal-normal-*-14-*-*-*-m-0-iso10646-1 (#x5DB)

Character code properties: customize what to show
  name: GREEK SMALL LETTER IOTA WITH TONOS
  old-name: GREEK SMALL LETTER IOTA TONOS
  general-category: Ll (Letter, Lowercase)
  decomposition: (953 769) ('ι' '́')

    >> To me that implies that the Greek input methods should use GREEK TONOS
    >> (\u384) consistently rather then GREEK OXIA (\u1ffd), but I couldn't
    >> see any explicit mention of that, and at least in my font they're
    >> visually distinct.

    Eli> I don't actually understand this assertion, because we currently
    Eli> provide both forms.  So I fail to see a problem in our input methods.
    Eli> What did I miss?

We donʼt provide both forms within the same input method. The question
is whether we should provide both, or provide only tonos, since letter
+ oxia were allegedly added by mistake, hence standalone oxia should
not be produced. Or we could change nothing.

Perhaps we should ask the unicode people :-)

Robert