all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Cesar Crusius <cesar.crusius@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Johannes Choo <jhanschoo@gmail.com>, emacs-devel@gnu.org
Subject: Re: [ELPA] New Package: greek-polytonic.el
Date: Sat, 14 Jul 2018 10:11:01 -0700	[thread overview]
Message-ID: <86wotxzqsa.fsf@macmini.i-did-not-set--mail-host-address--so-tickle-me> (raw)
In-Reply-To: <83fu0mawzb.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 14 Jul 2018 14:16:24 +0300")

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

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Johannes Choo <jhanschoo@gmail.com>
>> Date: Sat, 14 Jul 2018 04:29:15 -0500
>> 
>> I'd like to contribute a new package greek-polytonic.el to ELPA, or
>> where ever it is more appropriate.
>
> Why not add this to greek.el?
>
>> 2) Input of combining character sequences possible—While the
>> existing input methods allow for the input of
>> bare letters and precomposed letter+diacritics, but not for Unicode
>> letter+diacritic sequences that are not
>> represented by precomposed characters. 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; hence input from this method satisfies Unicode-NFC
>> (Normalization Form Canonical Composition),
>> while allowing input of sequences that have no corresponding
>> precomposed character. Though it is to be
>> admitted that font support and Emacs's display support for such
>> decomposed sequences is still rudimentary
>> and the sequence may visually appear funky.
>
> 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. I don't particularly care how it is represented internally. As long
as the input method produces a valid representation for what I want, it
should be fine.

By the way, thanks for trying to solve this problem -- it's been a
long-standing one. I solved some of that for myself via XCompose, but
that's not portable.

Font and application support may be the biggest hurdle, though. It is
for me. What are the consumers of the texts you are producing in Emacs,
TeX and friends?  I'd be interested in a properly working TeX setup for
polytonic Greek, but that's another thread (in another group, maybe?).

Cheers,

-- 
Cesar Crusius

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

  reply	other threads:[~2018-07-14 17:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-14  9:29 [ELPA] New Package: greek-polytonic.el Johannes Choo
2018-07-14 11:16 ` Eli Zaretskii
2018-07-14 17:11   ` Cesar Crusius [this message]
2018-07-14 18:32     ` Eli Zaretskii
2018-07-15  0:31       ` Richard Stallman
2018-07-15  1:37       ` Cesar Crusius
2018-07-16 15:57         ` Eli Zaretskii
2018-07-16 16:23           ` Cesar Crusius
2018-08-08 13:12             ` Johannes Choo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86wotxzqsa.fsf@macmini.i-did-not-set--mail-host-address--so-tickle-me \
    --to=cesar.crusius@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=jhanschoo@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.