From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Johannes Choo Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] New Package: greek-polytonic.el Date: Wed, 8 Aug 2018 06:12:35 -0700 Message-ID: References: <83fu0mawzb.fsf@gnu.org> <86wotxzqsa.fsf@macmini.i-did-not-set--mail-host-address--so-tickle-me> <83o9f9acsf.fsf@gnu.org> <86sh4le0to.fsf@gmail.com> <83pnzn8982.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000004ffcdd0572ec4433" X-Trace: blaine.gmane.org 1533734030 28516 195.159.176.226 (8 Aug 2018 13:13:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 8 Aug 2018 13:13:50 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Cesar Crusius Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 08 15:13:46 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fnOHZ-0007Hz-Bo for ged-emacs-devel@m.gmane.org; Wed, 08 Aug 2018 15:13:46 +0200 Original-Received: from localhost ([::1]:43722 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fnOJg-0001Ch-27 for ged-emacs-devel@m.gmane.org; Wed, 08 Aug 2018 09:15:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46220) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fnOGn-0007tK-Bn for emacs-devel@gnu.org; Wed, 08 Aug 2018 09:12:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fnOGl-0002Qw-LC for emacs-devel@gnu.org; Wed, 08 Aug 2018 09:12:57 -0400 Original-Received: from mail-lj1-x230.google.com ([2a00:1450:4864:20::230]:43536) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fnOGf-0002NN-Ih; Wed, 08 Aug 2018 09:12:49 -0400 Original-Received: by mail-lj1-x230.google.com with SMTP id r13-v6so1661573ljg.10; Wed, 08 Aug 2018 06:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lIPMSN5G7eqm1OFvZz1oXtkOlLdy/2UVdr/v9sIDEWk=; b=hKiS8mtq0enbKmfZHpmZPnKDz4lsOuRS/mPKaABDasc+wFqiltX7Ghvy3cPRIKElmF FF/ltU2ArIS3Ffz48zltiYGsXyo7zNNODIlUAgVDRhHb/PNZFkdSGt5UAJf6WnYLeUZf lwYGQDt8GR6zKBVndZpkQtSBs8O5aQ/Sx3oZDjXD6txXd6wINlHRnpYI+isov7FZlU5T TssH7b8NURRurkSACB+sHW/4bu83zXcGvLNwtd10SQ4854d3u5TBNGchIlT11KwAtgrB CLvTN1KgxGAWg2LX14l0YQOxmtAWqJoErOn/JL/0Xcb3zHES9vppb+mFVli7O2BGZLbL 7HuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lIPMSN5G7eqm1OFvZz1oXtkOlLdy/2UVdr/v9sIDEWk=; b=Nj1M8qVKN+kwkjVedmbSJ29A64NBo58urC1LR3k1/W63284XhJnqQqTlADndK4K+m4 2LANznCrTNpXDLNVkn3BVi1zoSSA1Ks/mYc5ZMWGn0bRj6+VM5mF01kSMfQcle2Or/97 gn5D6M2oA+we3DeE32Gij75us554upBbyzY/LG3MoGOWVE4LVlpV/0NA41C8zFK7pDj/ EVFBaok5a3Fva8zO3nRfMHgdZ62cMdVSTYtFktuqAeLGdSsMflFwj8mS/kK9hZQTRmY0 qnhafBkWqc5/CiO/byX9DlK9jurNVJMJhWe1XQhahyPbpZfAywjtwoII008WAldmrrmu H2NQ== X-Gm-Message-State: AOUpUlHb6JD/bKYj/aVtyGKWT5RNDokGWYBT62VqBtt40bPDWd/yFA2t yHrQvFWpwOiXE73IpHNup+wS/eNqWj7l18bBhkQ= X-Google-Smtp-Source: AA+uWPxUs1j/JfQKViq5xkImgC03+taPIxPcvd3vT3d5mM0I+VpZj/FKARxyWOEbKJAPRKlKwBdU/6gKTq0yJ3FPtT0= X-Received: by 2002:a2e:9645:: with SMTP id z5-v6mr1954966ljh.127.1533733967492; Wed, 08 Aug 2018 06:12:47 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::230 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:228309 Archived-At: --0000000000004ffcdd0572ec4433 Content-Type: text/plain; charset="UTF-8" Sorry for a late reply. I found a couple typos and it actually needs to be updated. @Cesar: I actually have a working polytonic Greek setup for LaTeX; (more accurately, XeLaTeX and LuaLaTeX); send me a message and I'll send you a minimum working preamble :) @Eli: yes, I think putting it in greek.el would be a better option, but I don't have contributor rights, and so far this has been the easier way for me to distribute it. I'd be happy to if someone can help me with that. > It seems to go against the intent of whoever is > typing the text: they do want the decomposed characters to appear in > the text. Emacs will automatically (by default) compose them on > display (and if it doesn't, that's a bug that should be reported and > fixed), per Unicode requirements, and if the font supports the > precomposed glyph, you will actually see that glyph on display. > Replacing characters with their NFC equivalents should IMO be a > separate feature, not something an input method does. In an ideal world... yeah. De facto, polytonic Greek online and presumably in most digital systems use the precomposed forms, and /all/ polytonic fonts I'm aware of do not gracefully handle the placement of decorations on greek letters.[1] Some fonts don't display the accents, some fonts have them overlap, and probably all fonts don't place the combining breathings (single-quotation-commas) in the right place. When writing this I found that my favorite programming font on emacs actually crashes my Linux system when using these combining characters![2] This is the most prevalent compromise I've found online. greek-polytonic.el gives the most graceful fallback, compositing into precomposed forms whenever available. [1]: I think this is in fact the case, de facto, for most Latin/Greek/Cyrillic documents. For example, I've observed that in movement in emacs, decomposed characters count as two characters, but all the documents so far I've opened have their accented characters count as one. Korean... is similar in its poor de facto support for decomposed characters. The only natural language that I know writes in decomposed characters de facto are the Indic languages! [2]: This is a bug on emacs or the window system, but I don't even know where to begin diagnosing it. Bests, Johannes On Tue, Jul 17, 2018 at 12:23 AM Cesar Crusius wrote: > Eli Zaretskii writes: > > >> From: Cesar Crusius Cc: Cesar Crusius > >> , jhanschoo@gmail.com, > >> emacs-devel@gnu.org Date: Sat, 14 Jul 2018 18:37:23 -0700 > >> >> I'm not sure what you mean by "want the decomposed > >> >> characters > >> >> to appear in the text," but when I am writing polytonic > >> >> Greek and type the sequence above, all I want is to see an > >> >> alpha+macron+acute in front of me. > >> > On display or in the buffer? If on display, then Emacs > >> > should already do that, provided that the font you are using > >> > supports the composed characters. That's because by default > >> > we have the auto-composition-mode turned on. I was > >> > talking about what's in the buffer. I think that if the > >> > user types a sequence of characters, Emacs should generally > >> > put those characters unaltered in the buffer. If the user > >> > wants a precomposed character, she could always type that > >> > character's codepoint using "C-x 8 RET", no? But maybe I > >> > don't know enough about the expectations of users who would > >> > use greek-polytonic input method, maybe in some use cases > >> > such automatic composition in the buffer is expected? > >> Maybe we're talking about different things... (snip) > > > > More accurately, input methods normally read ASCII characters > > and produce non-ASCII characters, whether accented or not. By > > contrast, your original text: > > > >> For example, the sequence ++ >> acute accent> is not represented by any precomposed character, > >> but appears frequently in critical editions of > >> classics. greek-polytonic.el allows for the input of combining > >> characters themselves, and substitutes such sequences with > >> their Unicode-canonical precomposed equivalents if they exist; > > That's not mine, but the OP's text :) > > > led me to believe that your input method takes three non-ASCII > > characters, alpha combining macron and combining acute accent, > > and produce from them a single composed character which is their > > NFC precomposed character. This is not what an input method > > should do, IMO. > > > > However, I see now that no such NFC composition is being done > > for non-ASCII input (right?), so I guess I misunderstood; sorry > > about that. > > No need to be sorry about anything -- wonders of written > communication. I think we're on the same page now. > > > (snip) > > > >> By the way, I'm all for greek.el supporting polytonic Greek > >> natively and naturally. I don't remember what the problems > >> were, but I gave up on it quickly when trying polytonic > >> because it didn't work. > > > > I was talking about adding your input method to greek.el. > > Not /my/ input method, I'm just encouraging the OP to think about > making this an improvement to greek.el instead of a separate > package, as you suggested in your first e-mail :) > > Cheers, > > -- > Cesar Crusius > -- Bests, Johannes Choo B. Comp student at National University of Singapore NUSHackers Coreteam --0000000000004ffcdd0572ec4433 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry for a late reply. I found a couple typos and it= actually needs to be updated.

@Cesar:

I actually have a working polytonic Greek setup for = LaTeX; (more accurately, XeLaTeX and LuaLaTeX); send me a message and I'= ;ll send you a minimum working preamble :)

@El= i:

yes, I think putting it in greek.el would be a = better option, but I=20 don't have contributor rights, and so far this has been the easier way= =20 for me to distribute it. I'd be happy to if someone can help me with th= at.

> It seems to go against the intent of = whoever is
> typing the text: they do want the decomposed characters to appear in > the text.=C2=A0 Emacs will automatically (by default) compose them on<= br> > display (and if it doesn't, that's a bug that should be report= ed and
> fixed), per Unicode requirements, and if the font supports the
> precomposed glyph, you will actually see that glyph on display.
> Replacing characters with their NFC equivalents should IMO be a
>= ; separate feature, not something an input method does.

In an ideal world... yeah. De facto, polytonic Greek online and presu= mably in most digital systems use the precomposed forms, and /all/ polytoni= c fonts I'm aware of do not gracefully handle the placement of decorati= ons on greek letters.[1] Some fonts don't display the accents, some fon= ts have them overlap, and probably all fonts don't place the combining = breathings (single-quotation-commas) in the right place. When writing this = I found that my favorite programming font on emacs actually crashes my Linu= x system when using these combining characters![2]

This is the most prevalent compromise I've found online. greek-polyton= ic.el gives the most graceful fallback, compositing into precomposed forms = whenever available.

[1]: I think this is in fact t= he case, de facto, for most Latin/Greek/Cyrillic documents. For example, I&= #39;ve observed that in movement in emacs, decomposed characters count as t= wo characters, but all the documents so far I've opened have their acce= nted characters count as one. Korean... is similar in its poor de facto sup= port for decomposed characters. The only natural language that I know write= s in decomposed characters de facto are the Indic languages!
=
[2]: This is a bug on emacs or the window system, but I don&= #39;t even know where to begin diagnosing it.

= Bests,
Johannes

On Tue, Jul 17, 2018 at 12:23 AM Cesar Crusius <cesar.crusius@gmail.com> wrote:
=
Eli Zaretskii <eliz@gnu.org> writes:

>> From: Cesar Crusius <cesar.crusius@gmail.com> Cc: Cesar Crusius
>> <c= esar.crusius@gmail.com>,=C2=A0 jhanschoo@gmail.com,
>> emacs-dev= el@gnu.org Date: Sat, 14 Jul 2018 18:37:23 -0700=C2=A0
>> >>=C2=A0 I'm not sure what you mean by "want the de= composed
>> >>=C2=A0 characters=C2=A0
>> >> to appear in the text," but when I am writing polyto= nic
>> >> Greek=C2=A0 and type the sequence above, all I want is to= see an
>> >> alpha+macron+acute in front of me.=C2=A0
>> >=C2=A0 On display or in the buffer?=C2=A0 If on display, then = Emacs
>> > should=C2=A0 already do that, provided that the font you are = using
>> > supports=C2=A0 the composed characters.=C2=A0 That's beca= use by default
>> > we have the=C2=A0 auto-composition-mode turned on.=C2=A0 =C2= =A0 I was
>> > talking about what's in the buffer.=C2=A0 I think that if= the
>> > user types a sequence of characters, Emacs should generally <= br> >> > put=C2=A0 those characters unaltered in the buffer.=C2=A0 If = the user
>> > wants a=C2=A0 precomposed character, she could always type th= at
>> > character's=C2=A0 codepoint using "C-x 8 RET", = no?=C2=A0 =C2=A0 But maybe I
>> > don't know enough about the expectations of users=C2=A0 w= ho would
>> > use greek-polytonic input method, maybe in some use=C2=A0 cas= es
>> > such automatic composition in the buffer is expected?
>>=C2=A0 Maybe we're talking about different things...=C2=A0 =C2= =A0(snip)
>
> More accurately, input methods normally read ASCII characters
> and produce non-ASCII characters, whether accented or not.=C2=A0 By > contrast, your original text:
>
>> For example, the sequence <alpha>+<combining macron>+&= lt;combining
>> acute accent> is not represented by any precomposed character, =
>> but appears frequently in critical editions of
>> classics. greek-polytonic.el allows for the input of combining >> characters themselves, and substitutes such sequences with
>> their Unicode-canonical precomposed equivalents if they exist;

That's not mine, but the OP's text :)

> led me to believe that your input method takes three non-ASCII
> characters, alpha combining macron and combining acute accent,
> and produce from them a single composed character which is their
> NFC precomposed character.=C2=A0 This is not what an input method
> should do, IMO.
>
> However, I see now that no such NFC composition is being done
> for non-ASCII input (right?), so I guess I misunderstood; sorry
> about that.

No need to be sorry about anything -- wonders of written
communication. I think we're on the same page now.

> (snip)
>
>> By the way, I'm all for greek.el supporting polytonic Greek >> natively and naturally. I don't remember what the problems >> were,=C2=A0 but I gave up on it quickly when trying polytonic
>> because it=C2=A0 didn't work.
>
> I was talking about adding your input method to greek.el.

Not /my/ input method, I'm just encouraging the OP to think about
making this an improvement to greek.el instead of a separate
package, as you suggested in your first e-mail :)

Cheers,

--
Cesar Crusius
--
Bests,
Johanne= s Choo
B. Comp student at National University of Singapore
<= div>NUSHackers Coreteam
--0000000000004ffcdd0572ec4433--