emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: quail input methods and conversion functions


From: Michael Welsh Duggan
Subject: Re: quail input methods and conversion functions
Date: Fri, 09 Feb 2018 13:26:25 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Uwe Brauer <address@hidden> writes:

>>>> "Michael" == Michael Welsh Duggan <address@hidden> writes:
>
>    > Uwe Brauer <address@hidden> writes:
>    >> In ancient pre Mule times, there was iso-unacentuate which for example
>    >> would translatex ä to "a
>    >> 
>    >> 
>    >> Does something like this exist for all, or some quail input methods?
>
>    > It seems to exist.  The interactive version is `M-x quail-show-key', and
>    > the programmatic version is `quail-find-key'.  For example, using the
>    > latin-1-prefix input method, M-x quail-show-key on ä outputs:
>
>    >   To input ‘ä’, type ""a"
>
>    > and (quail-find-key ?ä) -> ("\"a")
>
>    > Both of these depend on the current input method, of course.
>
> Thanks, but these functions do not convert globally, that is for a
> region or file, between the two sets.
>
> I mean suppose I have
>
>  Über den Wolken, unter dem Öl,
>
> Should give when converted
>
> "Uber den Wolken, unter dem "Ol.
>
> And vice versa, same way as iso-accentuate and iso-unaccentuate
> worked/s.

In the unaccentuate case (which is what your original question), it
should be easy to write that functionality using `quail-find-key' as a
base.  You would have to decide how to handle failures (character can't
be typed using the current input method).

The accentuate case looks more difficult.  Quail allows more than one
translation candidate for a single key sequence, which leaves no good
way handle these characters.  A simple example from the ipa input
method: tsh can translate into ʧ, tʃ, or t⁀ʃ.  Something that works with
input methods that do not have this ambiguity is possible, though my
initial look through the code leads me to believe that this is still
going to be more difficult to write then the (fairly trivial)
unaccentuate case.

-- 
Michael Welsh Duggan
(address@hidden)



reply via email to

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