bug#58070: [PATCH] Add tamil99 input method

[Visuwesh]

[செவ்வாய் செப்டம்பர் 27, 2022] Eli Zaretskii wrote:

Some bits about tamil99 layout first:

    Tamil99 layout has two parts: the physical keyboard layout akin to
    QWERTY, Dvorak, workman, etc. and the special "rules" which are
    supposed to combine vowels and consonants, and ease typing certain
    character sequences.  Tamil has vowels, consonants, and
    vowel-consonant pairs.  When you combine a consonant and a vowel
    sign, you get a vowel-consonant pair.  Tamil99's special "rules"
    comes into the picture here: these rules tell you how to write these
    vowel-consonant pairs as the layout itself does not have keys to
    type all the possible vowel-consonant pairs.
    E.g., h maps to the consonant க, d maps to the vowel உ.  When you
    type h d, you get கு.  This is basically what the rules say.

I will explain how our implementations differ below.

>> I agree. Your imperative approach does have this advantage. But, it
>> comes at the price of having to inspect the buffer at (point). The
>> declarative approach does not need to inspect the buffer at all since it
>> merely composes sequential keystrokes and doesn't know anything about
>> what's already on the buffer. I personally think buffer inspection is a
>> lot of code complexity for a simple input method like tamil99, but
>> perhaps Eli should take a call on this.
>
> I don't think I understand what you are talking about (I'm not an
> expert on Quail).  

Arun's implementation precalculates the key sequences that produce
vowel-consonant pairs and adds them as separate Quail rules, kind of
what happens in the itrans IMs.  So in the quail-map, you have rules
like "h" = க, "d" = உ, "hd" = கு which works great until you run into a
situation like Eric described in emacs-devel here: 
https://yhetil.org/emacs-devel/87a66ori6g.fsf@gmail.com/T/#m5b261c1a7bb06c7c074fdcdb746fb53ab7af1aa1

I'm sure that situation is familiar to many who use Quail IMs regularly,
which is why I decided to make my IM consider the character before point
to decide what codepoint Quail should insert in the buffer.  In my
implementation, the quail-map only has "h" = க, "d" = உ.  I use the
UPDATE-TRANSLATION-FUNCTION to see what the character before point is
and change what Quail should insert: if the user types 'd' and the
character before point is a 'க', then I make Quail insert ு (instead of
உ) to get கு.  This lets you insert vowel-consonant pairs out-of-order
which is akin to what Eric wants.

> Does this complexity slow down the input noticeably?

This I cannot tell since I am not a fast enough typist.  Each keystroke
looks up two to three alists of differing sizes on each input.  If it
leads to a noticeable slowdown, then we can replace the alists with a
hashtable instead.

> Does it make the code much harder to understand, even if you put
> enough comments there to explain what's going on?  If not, then I
> don't think the added complexity should be a problem, and you should
> decide based on other aspects.

I tried to comment almost everything I do for the future maintainers,
and use the same language as the keyboard layout's spec does (linked in
the file's Commentary).

>
>> Let me explain with a latin example for the benefit of non-Tamil
>> readers. Suppose we had:
>> 
>> [...]
>
> [...]
>
> Emacs 29 also has the composition-break-at-point variable, which you
> could set non-nil, in which case <Delete> will also work by
> codepoints.  So perhaps the out-of-sequence vowel insertion would be
> possible without further complications if composition-break-at-point
> is non-nil?

Unfortunately, composition-break-at-point is not enough here since the
layout does not have keys to insert the *vowel signs* (the grave accent
in Arun's example), only *vowels*.