From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#36717: 25.3; greek.el: deprecated vowel+oxia combinations should be replaced with vowel+tonos counterparts Date: Fri, 19 Jul 2019 17:26:59 +0300 Message-ID: <837e8eumks.fsf@gnu.org> References: <87zhlbaf5d.fsf@kiddo.i-did-not-set--mail-host-address--so-tickle-me> <20190718173252.GA3093@robertalessi.net> <20190718184700.GA4886@robertalessi.net> <20190718203203.GG4886@robertalessi.net> <83tvbiv7dp.fsf@gnu.org> <83h87iur38.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="127905"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 36717@debbugs.gnu.org, alessi@robertalessi.net To: Robert Pluim Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jul 19 16:28:08 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hoTrj-000X8d-N4 for geb-bug-gnu-emacs@m.gmane.org; Fri, 19 Jul 2019 16:28:07 +0200 Original-Received: from localhost ([::1]:45956 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hoTri-0002N9-Dv for geb-bug-gnu-emacs@m.gmane.org; Fri, 19 Jul 2019 10:28:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50097) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hoTrf-0002N2-UM for bug-gnu-emacs@gnu.org; Fri, 19 Jul 2019 10:28:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hoTre-0007cA-M6 for bug-gnu-emacs@gnu.org; Fri, 19 Jul 2019 10:28:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47580) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hoTre-0007c4-Ho for bug-gnu-emacs@gnu.org; Fri, 19 Jul 2019 10:28:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hoTre-0004Kj-DQ for bug-gnu-emacs@gnu.org; Fri, 19 Jul 2019 10:28:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 19 Jul 2019 14:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36717 X-GNU-PR-Package: emacs Original-Received: via spool by 36717-submit@debbugs.gnu.org id=B36717.156354643416593 (code B ref 36717); Fri, 19 Jul 2019 14:28:02 +0000 Original-Received: (at 36717) by debbugs.gnu.org; 19 Jul 2019 14:27:14 +0000 Original-Received: from localhost ([127.0.0.1]:56401 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hoTqs-0004JZ-DF for submit@debbugs.gnu.org; Fri, 19 Jul 2019 10:27:14 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:37621) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hoTqq-0004JN-Qg for 36717@debbugs.gnu.org; Fri, 19 Jul 2019 10:27:13 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:59604) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hoTql-00073I-2i; Fri, 19 Jul 2019 10:27:07 -0400 Original-Received: from [176.228.60.248] (port=3951 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hoTqj-0006PF-RE; Fri, 19 Jul 2019 10:27:06 -0400 In-reply-to: (message from Robert Pluim on Fri, 19 Jul 2019 15:27:45 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:163417 Archived-At: > From: Robert Pluim > 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.