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

[Johannes Choo <jhanschoo@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5502 bytes --]

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 <cesar.crusius@gmail.com>
wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Cesar Crusius <cesar.crusius@gmail.com> Cc: Cesar Crusius
> >> <cesar.crusius@gmail.com>,  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 <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 :)
>
> Cheers,
>
> --
> Cesar Crusius
>
-- 
Bests,
Johannes Choo
B. Comp student at National University of Singapore
NUSHackers Coreteam

[-- Attachment #2: Type: text/html, Size: 7280 bytes --]