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

[Eli Zaretskii]

> From: Visuwesh <visuweshm@gmail.com>
> Cc: 56323@debbugs.gnu.org
> Date: Fri, 01 Jul 2022 20:00:03 +0530
> 
> > I don't think I understand what you want to achieve, and don't read
> > Tamil in the first place, to tell you whether this is correct or not,
> > sorry.
> >
> 
> I mostly meant to ask if the weighted approach was good but I wasn't
> clear enough, sorry.  Let me try to explain it better:
> 
> Let's suppose that string-lessp does not work for English for the
> discussion here.  The task is to sort a list of jumbled English
> alphabets in alphabetical order.  What I'm currently doing is creating
> an alist where the key is the alphabet and the value is the alphabet's
> order (so a will be 1, b will be 2, etc.).  Then in the sort function, I
> look for this order.  If the alphabet is not in this list, then I fall
> back to a large number.
> 
> So the code above would look like this if it were in English,
> 
>     (sort '("b" "z" "c" "n" "a" "aa" "p")
>           (lambda (x y)
>             (let ((cp '(("a" . 0) ("b" . 1) ("c" . 2) ("d" . 3) ("e" . 4)
>                         ("f" . 5) ("g" . 6) ("h" . 7) ("i" . 8) ("j" . 9)
>                         ("k" . 10) ("l" . 11) ("m" . 12) ("n" . 13) ("o" . 14)
>                         ("p" . 15) ("q" . 16) ("r" . 17) ("s" . 18) ("t" . 19)
>                         ("u" . 20) ("v" . 21) ("w" . 22) ("x" . 23) ("y" . 24)
>                         ("z" . 25))))
>               (< (or (assoc-default x cp) 10000)
>                  (or (assoc-default y cp) 10000)))))
> 
> and the sorted list comes out as ("a" "b" "c" "n" "p" "z" "aa")
> which is exactly what I desire.  I hope this is clear enough.

The above just gives each letter its order in the alphabet.  But if
that is what you wanted, string-lessp (or even just direct comparison
of characters) would have worked for you.  So there's still something
important missing from your description, I think.

> > Looks like simple misalignment to me, which should be cured by using
> > pixel-resolution alignment features.
> 
> Yep, it is misalignment.  I could try to use those pixel-resolution
> alignment features but I really don't think I can do a good enough job.
> It is something I tried in the past but gave up since it was too complex
> for me.  The current code produces a Good Enough™ table and I think I
> will just leave it unless Someone™ complains since after all, the
> current situation is much better than what we have in Emacs 28 (the
> docfix that happened as part of bug#50143 isn't in Emacs 28).

I thought vtable.el was about solving such problems?

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