Tags: patch The attached patchset adds a new customisable phonetic Tamil input method. I tried to reuse as much of the existing itrans input method code since it greatly simplifies the creation of an Indic input method (see `indian-make-hash'). The first patch fixes a fallout from bug#50143 asking to add TAMIL OM ௐ to the itrans table, and this means that one can insert the TAMIL OM character using the tamil-itrans input methods as well. I'd prefer it if this patch can be pushed quickly. The second patch actually adds the new phonetic input method. I will leave the rationale for making it a _customisable_ input method in footnote [1]. To reuse the existing code that calculates the various tables for the tamil-itrans IM, I turned the code in defvars to defuns. However, the definition of the almighty quail-tamil-itrans-syllable-table is still huge since I needed to do a whole lot to convert the indian-tml-base-table to a format that will accepted by the new defun `quail-tamil-itrans-compute-syllable-table'. The current quail rules is inspired by the one in https://github.com/rnchzn/tamil-phonetic/raw/main/tamil-phonetic.el and the comments in https://emacsnotes.wordpress.com/2022/03/07/tamil-phonetic-input-method-in-emacs-emacs-%E0%AE%87%E0%AE%B2%E0%AF%8D-%E0%AE%A4%E0%AE%AE%E0%AE%BF%E0%AE%B4%E0%AF%8D-%E0%AE%83%E0%AE%AA%E0%AF%8A%E0%AE%A9%E0%AF%86%E0%AE%9F%E0%AE%BF%E0%AE%95%E0%AF%8D/. Avid readers might notice that I went for a nil SIMPLE argument despite my recent complaint in emacs-devel. The reason for that is because we need a way to end the ongoing translation (C-SPC). E.g., if one decides to transliterate ல் as "l" and ள் as "ll", then to type ல்ல the key sequence will be l C-SPC la without the C-SPC, "lla" would be translated to ள. The better way forward would be to present _both_ ல்ல and ள் for the sequence "lla" but I have no idea how to do it. Any pointers would be _highly_ appreciated. I plan to modify indian--puthash-char to have one to many translations i.e., "l" would translate to both ல் and ள் and then the user could decide which one to insert. This combined with the DETERMINISTIC argument to quail-define-package would make it an attractive option, I think. But I'm leaving it out right now since I want the current patch to be reviewed first. I think adding an optional NAME argument to tamil--update-quail-rules might be more flexible since then a user could let bind the relevant defcustoms to define other Tamil input methods without hassle (like the tamil99 layout, which I plan to get to at Some Point™). WDYT? The code for tamil--update-quail-rules is sort of convoluted because of the conversion mentioned above. tamil--make-trans-table is also kind of complicated because, 1. I couldn't make the tamil-vowel-translation (and consonant, and misc) alist have a character key since the Customize interface shows those characters as numbers!! I really do not want to dig into the Customize UI code, sorry. :( 2. indian-tml-base-table has the character க in it but the defcustom tamil-consonant-translation has the character க் in it because the latter makes more sense to a native speaker and also because of (1) above. More explanation as to why in footnote [2]. There are some FIXMEs spattered in the code but I will get to it in a later revision. I also don't have a :set function for the defcustoms since I'm not sure if something along the following is the only way to automagically recalculate the quail rules: (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))) Comments on this, and general code review would be much appreciated. I don't think I have missed anything and if you want me to add more comments on some of the stuff, please do tell. Thanks. If Tamil speakers are reading this bug report, shout at me if you want something else and if you have other general comments. Or if I made an embarrassing typo somewhere. Thanks!