[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ELPA] New Package: greek-polytonic.el
From: |
Eli Zaretskii |
Subject: |
Re: [ELPA] New Package: greek-polytonic.el |
Date: |
Mon, 16 Jul 2018 18:57:01 +0300 |
> 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...
>
> Input methods do automatic composition all the time. That's what
> they are expected to do. I do it every day when writing Portuguese
> text. Consider "á": I just wrote it by switching input methods and
> typing "<acute>-<a>". What ends up in the buffer and on the
> display is one single character.
True, and I was not talking about that.
> This means that the input method's semantics is to translate a
> sequence of keys into the most natural underlying
> representation. For "a acute," it is "á", not "a+combining acute",
> and nobody blinks an eye.
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;
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.
> For polytonic Greek, however, the problem is that Unicode does not
> have pre-composed characters to represent all the
> possibilities. Combining characters will be needed, but the input
> method can -- and I argue /should/ -- combine what they
> can. Example:
>
> * Typing "a + macron" should give U+1FB1, "Greek small letter
> alpha with
> macron," /one/ character, just as "á" above. Similarly, I would
> consider "<a>+<combining macron>" a bug.
> * Typing "a + macron + acute" should give the above plus a U+0301
> "combining
> acute", because it is the best it can do -- and it is what fonts
> like Skolar expect.
Emacs combines these automatically, but only on display; in the buffer
we still have several separate codepoints. And I think this is
correct.
> 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.