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

[Cesar Crusius <cesar.crusius@gmail.com>]

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

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Cesar Crusius <cesar.crusius@gmail.com> Cc: Johannes Choo 
>> <jhanschoo@gmail.com>,  emacs-devel@gnu.org Date: Sat, 14 Jul 
>> 2018 10:11:01 -0700  
>> > Is this a good idea?  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.  Am I 
>> > missing something? 
>>  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. If my buffer had instead 
"<a>+<combining acute>" I would consider that a bug. Unicode 
supports the combination, I want the combination there.

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.

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.

"C-x 8 RET" is not a solution if you are typing in a language that 
requires it once or more every word. (Again, that becomes the job 
of the input method.)

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.

Cheers,

-- 
Cesar Crusius

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]