bug#58070: [PATCH] Add tamil99 input method

[Arun Isaac]

Hi,

> I have a tamil99 keyboard layout in the works as well, and I'm slowly
> dogfeeding it whilst also learning the layout.  I use a different
> approach to add these special rules: using a
> UPDATE-TRANSLATION-FUNCTION.
>
> WDYT about this approach, is this feasible?

Nice to see your code, Visuwesh. Sorry to have duplicated your work, but
it happens at times! ;-) I wrote my implementation of tamil99 more than
a year ago, and have been using it privately since. But only last month,
I finished it properly and published it in a git repo at
https://git.systemreboot.net/tamil99/about/

> The only reason why I haven't submitted a patch so far is because I was
> not sure if my implementation wasn't riddled of bugs.

I know the feeling. I empathize. :-)

I see that Visuwesh's implementation takes an imperative mutational
approach, whereas mine is a more functional declarative approach which
enumerates all possible rules into a quail map.

The imperative approach is indeed more powerful since it is arbitrary
code and can do anything. But, I feel that is not really necessary for a
relatively simple input method like tamil99.

The declarative approach results in shorter and more readable code. It
also gives us nice features such as the keyboard layout visualization
and the key sequence tabulation in describe-input-method.

> AFAIK, MS Windows' tamil99 keyboard layout behaves like mine, whereas
> the ibus layout behaves like your implementation.  If you are a heavy
> user of this layout, can you try out the attached?

Indeed, I do use the tamil99 input method almost every day.

I tried out your implementation, and am having difficulty getting it
working correctly. This is likely because I have an Ergodox keyboard
with a non-standard keyboard layout. I have told quail about this
keyboard layout by setting the quail-keyboard-layout variable. But, your
implementation assumes a qwerty layout. It should instead call
quail-keyboard-translate or quail-keyseq-translate to translate
keystrokes. My declarative implementation does this correctly since I
don't directly touch the quail state machine, and merely instruct quail
to do the necessary translation by passing a non-nil kbd-translate
argument to quail-define-package.

> This has the advantage that you can insert the vowel sign for any
> consonant out-of-sequence i.e., you can say h j BACKSPACE s
> to insert கி (and so do other rules).

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.

Also, while the out-of-sequence vowel insertion is a very clever
feature, it shouldn't be required at all if we handled grapheme cluster
boundaries correctly. See
https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries Let me
explain with a latin example for the benefit of non-Tamil
readers. Suppose we had:

g̀|

where | is the position of the cursor. Now, if we press backspace, the
entire g+grave accent grapheme cluster should be deleted. But, what
actually happens is that the grave accent alone is deleted and we are
left with a 'g' like so:

g|

A similar thing happens in Tamil. Now, based on user expectation, this
may be acceptable in some languages. But, in Tamil, it is quite contrary
to user expectation. If I have

கி|

and press backspace, I get:

க|

But, I want the whole "user-perceived character" (கி) deleted like so:

|

I would happily submit a patch fixing this if I knew where the fix
should be applied. My guess is that this is outside the scope of quail,
and probably even outside the scope of Emacs. Any insight on this would
be much appreciated.

Regards,
Arun