[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
signature.asc
Description: PGP signature