GNU bug report logs - #58070
[PATCH 0/1] Add tamil99 input method

Previous Next

Full log

View this message in rfc822 format

From: Visuwesh <visuweshm <at> gmail.com>
To: Arun Isaac <arunisaac <at> systemreboot.net>
Cc: 58070 <at> debbugs.gnu.org
Subject: bug#58070: [PATCH] Add tamil99 input method
Date: Tue, 27 Sep 2022 07:19:17 +0530

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

> 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! ;-) 

No need to apologise!  We both are trying to make typing Tamil more
pleasant, after all.

>> 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.

See below to see why I think checking the buffer is a pleasant
experience.

> 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.

Funnily enough, I went with the imperative approach mainly because I
couldn't wrap my head around generating all the possible keysequences.
It seemed much simpler to just look at the buffer and figure out what
needed to be done.

>> 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.

Hmm, this is weird.  I thought Quail did the translation job for me
which is why I boldly assumed the qwerty layout and coded it that way.
I will try to change Xorg's keyboard layout and test it.  Thanks for
testing!

> 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.
 
Here, I'm confused.  I pass a non-nil KBD-TRANSLATE argument as well...

>> 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.

Despite writing the tamil-phonetic keyboard layout, I disliked how much
backspacing and rewriting letters I needed to do when I found a simple
kuril-nedil typo, etc.  Check-the-buffer approach eases these
corrections tremendously and is more close to the experience of writing
on paper.
I might be biased but I don't think the code is that complex: once I
figured out which Quail variables to modify, it was a simple process of
following the rules section of Tamil99's specs.

> 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. 

While what you say is great for when we go from uyirmei to uyirmei,
sometimes you just need to add a vowel sign to a agara mei easily and be
done with it which is what I tried to achieve with my implementation.

> [...]
> 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.

Emacs 29's delete-forward-char deletes by grapheme clusters now.  It is
now a job of writing a backward version of the grapheme cluster
detection code.  I poked around in the C code to see how
find-composition-internal was implemented, and it looked *relatively*
straightforward to get a backward searching function working.  I might
be wrong here, so I hope Eli corrects my misunderstandings.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.