bug#56323: 29.0.50; [v2] Add new customisable phonetic Tamil input method

[Visuwesh]

[சனி ஜூலை 02, 2022] Eli Zaretskii wrote:

>> From: Visuwesh <visuweshm@gmail.com>
>> Cc: 56323@debbugs.gnu.org
>> Date: Fri, 01 Jul 2022 22:07:38 +0530
>> 
>> >> BTW, do you have any other code/documentation review?  And what about
>> >> the patch I posted in 
>> >> https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-06/msg02256.html?
>> >> No rush but I would like to know if it can go in since it only addresses
>> >> fallouts from the previous bug in this area.  Thanks.
>> >
>> > It sounded to me like you are still working on the code, so I didn't
>> > see a need to review it.  If you have specific parts that you'd like
>> > me to review nonetheless, please tell which parts are those.
>> 
>> Thanks.  The patch I posted in
>> https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-06/msg02256.html
>> is done, and can be pushed to master if you see no problems.
>
> I installed it, thanks.
>

Thanks.

>> Also, I would like to know if there's a better to write the :set
>> function for the defcustoms tamil-vowel-translation,
>> tamil-consonant-translation, tamil-misc-translation, tamil-native-digits
>> without the boundp check chain below,
>> 
>>     (defun tamil--set-variable (sym val)
>>       (set-default sym val)
>>       (when (and (boundp 'tamil-vowel-translation)
>>                  (boundp 'tamil-consonant-translation)
>>                  (boundp 'tamil-misc-translation)
>>                  (boundp 'tamil-native-digits))
>>         (tamil--update-quail-rules)))
>
> Why do you need a single function for all of them?  Would a separate
> setter function for each defcustom do the job?
>

Because it is harder to clear the old translation rules and add the new
translation rules than clearing ALL translation rules and starting over
again.  When the user changes tamil-vowel-translation, then not only
does the translation rule for the vowels change, we also need to change
the translation rules for consonant+vowel pairs so that means we need to
check if the consonant var is bound.  (The translation rules for
consonant+vowel pairs are auto-generated based on the rules for vowels
and consonants.)

Similarly, when the consonant defcustom changes, we need to change both
the consonant and the consonant+vowel pair translation rules.  Moreover,
if the user decides to delete an extra consonant translation, then we
need to smartly detect that and delete it from the current quail map.

Instead of all this, a simple clear ALL+start over approach is much
simpler.  And since this approach doesn't take too much time, I don't
think implementing the smarter approach would be worth it.

Besides, even if this smart approach is easy to implement, quail-map
structure is just too hard to manipulate by hand...

> I also don't understand the need for the boundp tests -- the function
> will live on the same indian.el file as the defcustoms, so if the
> function is defined, the defcustoms are also bound, no?
>

IIUC, when we load indian.el, first, the vowel defcustom will be bound,
then the consonant defcustom and so on.  So this boundp test is needed,
I think?  See above for why the defcustoms have a "dependency" on each
other.  When the vowel defcustom is loaded, then its job _sometimes_
depends on the consonant defcustom being bound as well.

I say sometimes because when we initially load the vowel defcustom,
having a separate setter should be fine but when we change it after
loading _all_ the other defcustoms (example in the Customize interface),
we also need to access the consonant translation values and update the
translation rules for consonant+vowel pairs.  A big fat setter function
that does everything at the cost of boundp checks is simpler AFAIU.

>> I'm also doubtful about the current group being used for these
>> defcustoms.  Should I go ahead and make a new 'tamil' group and make it
>> a subgroup of leim or i18n?
>
> It's okay to have a separate group, but what would be the subject of
> this group?  If it's just about input methods, the name had better
> reflected that, and just "tamil" is too general for that.
>

I thought the subject could be "Translation rules for the Tamil input
method."  If you think the group name is too general, then "tamil-im"
could work?

>> And is the prefix tamil- okay or should I change it to something
>> else?
>
> I see no problem with 'tamil-'.
>

Okay, thanks.

>> Finally, I'm unsure if "List of input sequences to translate to ..." is
>> clear.  I think it sounds a mouthful and there should be a better way to
>> put it.  I think "translation rules" is quite nice but I'm afraid that
>> it is too Quail specific and might not be well understood.
>
> I have no problem with that wording, but I wonder whether we should
> have these defcustoms in the first place.  What are the chances that
> some user will want to change the sequences, and why would they want
> that?

I think the chances are quite high.  As I tried to explain in the first
mail, there are too many ambiguities when transliterating Tamil and
sometimes there is no perfect transliteration for a character/consonant
family.

For example, the user in the wordpress article I linked chooses to
translate ல் as 'l' ள் as 'll' and take the penalty of having to type
C-SPC at the right time: to write ல்ல the sequence would l C-SPC la since
lla would translate to ள.

That user can take this penalty but I would rather translate ள் as L
instead and not worry about C-SPC at all.  

Bottom line, there is no one size fits all.  These small annoyances can
be dealt with when one writes Tamil rarely but for frequent writing, the
flexibility this input method offers will be welcome IMO.

The users _can_ update the quail-map themselves by hand but that becomes
tricky and a REAL chore for a language like Tamil.

[ FWIW, I add new translations and modify existing translations for the
  compose input method by setf-ing its quail map.  That is hard enough
  already, and I definitely wouldn't wish someone to do it for the Tamil
  input method.  Offering a defcustom is the least we can do to ease the
  pain of tweaking the translation rules.  ]


> P.S. Please in the future don't modify the Subject of the messages in
> the same bug report: that makes it harder to find related messages at
> least when using Rmail.

Oops, sorry about that.  I thought it would be easier to track the
progress but I guess it misfired.