From: Robert Pluim <rpluim@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 36717@debbugs.gnu.org, alessi@robertalessi.net
Subject: bug#36717: 25.3; greek.el: deprecated vowel+oxia combinations should be replaced with vowel+tonos counterparts
Date: Fri, 19 Jul 2019 15:27:45 +0200 [thread overview]
Message-ID: <m2imryf92m.fsf@gmail.com> (raw)
In-Reply-To: <83h87iur38.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 19 Jul 2019 15:49:31 +0300")
>>>>> 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
next prev parent reply other threads:[~2019-07-19 13:27 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-18 9:03 bug#36717: 25.3; greek.el: deprecated vowel+oxia combinations should be replaced with vowel+tonos counterparts Robert Alessi
2019-07-18 14:54 ` Robert Pluim
2019-07-18 17:32 ` Robert Alessi
2019-07-18 18:06 ` Robert Pluim
2019-07-18 18:47 ` Robert Alessi
2019-07-18 18:57 ` Robert Pluim
2019-07-18 20:14 ` Robert Alessi
2019-07-18 20:32 ` Robert Alessi
2019-07-19 6:57 ` Eli Zaretskii
2019-07-19 8:27 ` Robert Pluim
2019-07-19 9:09 ` Robert Alessi
2019-07-19 12:49 ` Eli Zaretskii
2019-07-19 13:27 ` Robert Pluim [this message]
2019-07-19 14:26 ` Eli Zaretskii
2019-07-19 14:41 ` Robert Pluim
2019-07-19 14:51 ` Eli Zaretskii
2019-07-19 14:52 ` Robert Alessi
2019-07-19 15:00 ` Eli Zaretskii
2019-07-19 15:14 ` Robert Alessi
2019-07-19 14:45 ` Robert Alessi
2019-07-19 8:58 ` Robert Alessi
2019-07-19 9:26 ` Robert Pluim
2019-07-19 9:42 ` Robert Alessi
2019-07-19 9:49 ` Robert Pluim
2019-07-19 10:03 ` Robert Alessi
2019-07-19 11:49 ` Robert Pluim
2019-07-19 13:32 ` Robert Alessi
2019-07-19 12:54 ` Eli Zaretskii
2019-07-19 13:00 ` Eli Zaretskii
2019-07-19 13:31 ` Robert Alessi
2019-07-19 14:27 ` Eli Zaretskii
2020-01-16 13:59 ` Stefan Kangas
2019-07-19 13:29 ` Robert Pluim
2019-07-19 13:33 ` Robert Alessi
2019-07-19 12:52 ` Eli Zaretskii
2019-07-19 9:33 ` Eli Zaretskii
2019-07-19 9:54 ` Robert Alessi
2019-07-19 12:55 ` Eli Zaretskii
2019-07-19 13:47 ` Robert Alessi
2019-07-18 18:19 ` Basil L. Contovounesios
2019-07-18 20:19 ` Robert Alessi
2019-07-18 20:52 ` Basil L. Contovounesios
2019-07-18 18:16 ` Basil L. Contovounesios
2019-07-18 18:47 ` Robert Pluim
2019-07-18 20:27 ` Robert Alessi
2019-07-18 20:23 ` Robert Alessi
2019-07-19 9:40 ` Robert Pluim
2019-07-18 18:16 ` Basil L. Contovounesios
2019-07-18 20:29 ` Robert Alessi
2019-07-19 12:40 ` Eli Zaretskii
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=m2imryf92m.fsf@gmail.com \
--to=rpluim@gmail.com \
--cc=36717@debbugs.gnu.org \
--cc=alessi@robertalessi.net \
--cc=eliz@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.