[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ELPA] New Package: greek-polytonic.el

From: Johannes Choo
Subject: Re: [ELPA] New Package: greek-polytonic.el
Date: Wed, 8 Aug 2018 06:12:35 -0700

Sorry for a late reply. I found a couple typos and it actually needs to be updated.


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 :)


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.


On Tue, Jul 17, 2018 at 12:23 AM Cesar Crusius <address@hidden> wrote:
Eli Zaretskii <address@hidden> writes:

>> From: Cesar Crusius <address@hidden> Cc: Cesar Crusius
>> <address@hidden>,  address@hidden,
>> address@hidden 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 <alpha>+<combining macron>+<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.  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 :)


Cesar Crusius
Johannes Choo
B. Comp student at National University of Singapore
NUSHackers Coreteam

reply via email to

[Prev in Thread] Current Thread [Next in Thread]