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: Cesar Crusius
Subject: Re: [ELPA] New Package: greek-polytonic.el
Date: Sat, 14 Jul 2018 18:37:23 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

From: Cesar Crusius <address@hidden> Cc: Johannes Choo <address@hidden>, address@hidden 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: signature.asc
Description: PGP signature


reply via email to

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