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

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: 36717@debbugs.gnu.org,  alessi@robertalessi.net
> Date: Fri, 19 Jul 2019 15:27:45 +0200
> 
>     >> 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

That's OK, but it's not really relevant, AFAIU.  We don't force users
to type decomposed characters, primarily because that's inconvenient,
and because most users wouldn't know what a given precomposed
character decomposes into.  A user who _wants_ to type decomposed
characters can (or at least should be able to) do that, including by
using our input methods.

>     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) ('ι' '́')

As hinted by the last line above, you should try the reverse: type
"C-x 8 RET 3b9" followed by "C-x 8 RET 301".  Then compare that with
what you get for "C-x 8 RET 3af".

IOW, I wasn't talking about "glyph decomposition" -- there's no such
thing AFAIK -- I was talking about the shaping engine displaying 2
characters as a single glyph using the font glyph for the precomposed
character.

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

I don't see why this would be a problem.  We should provide the
variant expected by modern Greek in the input methods which target
modern Greek, and the variants for Classic Greek in input methods
which target that.  Bonus points for providing at least some of the
other variants in each type of the input methods.

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

I don't see that everyone agrees it was a mistake, and in any case
both variants are still in usage.  So I see no need to change
anything.