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

[Visuwesh <visuweshm@gmail.com>]

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

>> > 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.)
>
> If the rules are generated based on both defcustom's, then shouldn't
> we have just one defcustom for both?  IOW, what is the purpose of
> having two separate defcustom's here?
>

It simply seemed natural to me to separate consonants and vowels.  I
combined the three defcustoms (vowels, consonants and misc) as you told
but the native digits defcustom is still a problem... hmm.  I can just
leave it to the user to add the native digit translations to the
defcustom if they want.

>> > 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?
>
> Wouldn't that be fixed by having the setter function defined before
> the defcustom's?
>
>> 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.
>
> Since the defcustom's have their default value, I don't think I see
> the problem.  Did you actually see any problems, and if so, in which
> scenario, and what were the error messages?
>

I was mostly worried about the tamil-native-digits defcustom but that
can be easily avoided.    

>> 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?
>
> tamil-input, perhaps?

Okay, then.  That looks better to me as well.

I will post an updated patch later when I clean up the comments, and
docstrings.  Thanks.