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

[Visuwesh]

[வெள்ளி ஜூலை 01, 2022] Eli Zaretskii wrote:

>> From: Visuwesh <visuweshm@gmail.com>
>> Cc: 56323@debbugs.gnu.org
>> Date: Fri, 01 Jul 2022 19:17:18 +0530
>> 
>> > Then you'll need to write your own comparison function and use it
>> > instead string-lessp.
>> >
>> 
>> I suppose so.  How does the following look?
>> 
>>     (sort
>>      '("க்" "ங்" "ச்" "ஞ்" "ட்" "ண்" "ற்ற்" "ந்" "ப்" "ய்"
>>        "ம்" "த்" "ர்" "ல்" "வ்" "ள்" "ற்" "ழ்" "ன்"
>>        "ஸ்" "ஜ்" "க்ஷ்" "ஷ்" "ஹ்" "க்‌ஷ்" "ஶ்")
>>      (lambda (x y)
>>        (let* ((cp '(("க்" . 0) ("ங்" . 1) ("ச்" . 2) ("ஞ்" . 3) ("ட்" . 4) 
>> ("ண்" . 5)
>>                     ("த்" . 6) ("ந்" . 7) ("ப்" . 8) ("ம்" . 9) ("ய்" . 10) 
>> ("ர்" . 11)
>>                     ("ல்" . 12) ("வ்" . 13) ("ழ்" . 14) ("ள்" . 15) ("ற்" . 
>> 16) ("ன்" . 17)
>>                     ("ஜ்" . 18) ("ஸ்" . 19) ("ஷ்" . 20) ("ஹ்" . 21) ("க்ஷ்" 
>> . 22)
>>                     ("க்‌ஷ்" . 23) ("ஶ்" . 24)))
>>               (xp (or (assoc-default x cp nil) 10000))
>>               (yp (or (assoc-default y cp nil) 10000)))
>>          (< xp yp))))
>
> 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.

Obviously, I don't have much programming experience, so I'm unsure if
there's a better way to sort.

>> >> Can I use the min-width property in buffer text?
>> >
>> > Why do you need that?  Please tell more about what you want to
>> > accomplish.
>> 
>> Currently we don't try too hard to ensure that text don't bump into each
>> other in the tables we calculate.  If you are unlucky, then the table
>> will be incomprehensible so I thought about putting a reasonable
>> min-width value on the text in signs table at least.  Of course, finding
>> a reasonable value is a headache in of itself; the better solution would
>> be probably pulling in the vtable library but I'm not too sure about
>> that.
>
> I think it would be better to be more accurate in alignment of table
> cells.  We do have string-width and string-pixel-width, let alone
> window-text-pixel-size.
>
>> I also attached a screenshot comparing my running Emacs session and
>> emacs -Q (yellow window is my current Emacs session) to get the point
>> across better.
>
> 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).

Maybe someday, I will be annoyed enough at the misalignment to come back
and fix it.  But until that day, I will just leave the code as is.

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.