emacs-devel
[Top][All Lists]
Advanced

[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.



reply via email to

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