bug#58070: [PATCH 0/1] Add tamil99 input method

bug#58070: [PATCH 0/1] Add tamil99 input method

[Arun Isaac]

Hi,

This patch adds the tamil99 input method to Emacs.

This is my first contribution to Emacs, and I believe I need to assign
copyright to the FSF. May we get started with copyright assignment? I
have assigned copyright for other GNU projects before, but not for
Emacs.

Thanks!

Arun Isaac (1):
  Add tamil99 input method

 etc/NEWS                   |   3 +
 lisp/leim/quail/tamil99.el | 200 +++++++++++++++++++++++++++++++++++++
 2 files changed, 203 insertions(+)
 create mode 100644 lisp/leim/quail/tamil99.el

-- 
2.37.2

bug#58070: [PATCH] Add tamil99 input method

[Arun Isaac]

* lisp/leim/quail/tamil99.el: New file.
* etc/NEWS: Mention new tamil99 input method.
---
 etc/NEWS                   |   3 +
 lisp/leim/quail/tamil99.el | 200 +++++++++++++++++++++++++++++++++++++
 2 files changed, 203 insertions(+)
 create mode 100644 lisp/leim/quail/tamil99.el

diff --git a/etc/NEWS b/etc/NEWS
index 3d1af8bd6f..bcdc991ea3 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -1279,6 +1279,9 @@ The default input method for the Tamil language environment is now
 change the input method's translation rules, customize the user option
 'tamil-translation-rules'.
 
+---
+*** New tamil99 input method for the Tamil language
+
 \f
 * Changes in Specialized Modes and Packages in Emacs 29.1
 
diff --git a/lisp/leim/quail/tamil99.el b/lisp/leim/quail/tamil99.el
new file mode 100644
index 0000000000..780ef968ee
--- /dev/null
+++ b/lisp/leim/quail/tamil99.el
@@ -0,0 +1,200 @@
+;;; tamil99.el --- Quail package for the tamil99 input method -*- lexical-binding: t -*-
+
+;; Copyright (C) 2022 Free Software Foundation, Inc.
+;;
+;; Author: Arun Isaac <arunisaac@systemreboot.net>
+;; Keywords: multilingual, input method, Indian, Tamil
+
+;; This file is part of GNU Emacs.
+;;
+;; GNU Emacs is free software: you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+;;
+;; GNU Emacs is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+;;
+;; You should have received a copy of the GNU General Public License
+;; along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.
+
+;;; Commentary:
+;;
+;; Tamil99 is a keyboard layout and input method that is specifically
+;; designed for the Tamil language. Vowels and vowel modifiers are
+;; input with your left hand, and consonants are input with your right
+;; hand. See https://en.wikipedia.org/wiki/Tamil_99
+;;
+;; தமிழ்99 தமிழுக்கென்றே உருவாக்கப்பட்ட விசைப்பலகை அமைப்பும் உள்ளீட்டு முறையும்
+;; ஆகும். உயிர்களை இடக்கையுடனும் மெய்களை வலக்கையுடனும் தட்டச்சிடும்படி
+;; அமைக்கப்பட்டது. https://ta.wikipedia.org/wiki/%E0%AE%A4%E0%AE%AE%E0%AE%BF%E0%AE%B4%E0%AF%8D_99
+;; காண்க.
+;;
+;; Usage:
+;;
+;; Switch to the tamil99 input method using M-x set-input-method
+;; tamil99 RET and enjoy typing in Tamil!
+;;
+;; பயன்பாடு:
+;;
+;; tamil99 உள்ளீட்டு முறைக்கு மாற M-x set-input-method tamil99 RET கட்டளையை
+;; இயக்கித் தமிழில் தட்டச்சிட்டு மகிழ்க!
+
+;;; Code:
+
+(require 'pcase)
+(require 'quail)
+(require 'seq)
+
+(quail-define-package
+ "tamil99" "Tamil" "தமிழ்99"
+ t "Tamil99 input method"
+ nil t t t t nil nil nil nil nil t)
+
+(defconst tamil99-vowels
+  '(("q" "ஆ")
+    ("w" "ஈ")
+    ("e" "ஊ")
+    ("r" "ஐ")
+    ("t" "ஏ")
+    ("a" "அ")
+    ("s" "இ")
+    ("d" "உ")
+    ("g" "எ")
+    ("z" "ஔ")
+    ("x" "ஓ")
+    ("c" "ஒ"))
+  "Mapping for vowels.")
+
+(defconst tamil99-vowel-modifiers
+  '(("q" "ா")
+    ("w" "ீ")
+    ("e" "ூ")
+    ("r" "ை")
+    ("t" "ே")
+    ("a" "")
+    ("s" "ி")
+    ("d" "ு")
+    ("g" "ெ")
+    ("z" "ௌ")
+    ("x" "ோ")
+    ("c" "ொ")
+    ("f" "்"))
+  "Mapping for vowel modifiers.")
+
+(defconst tamil99-vallinam-consonants
+  '(("h" "க")
+    ("[" "ச")
+    ("o" "ட")
+    ("l" "த")
+    ("j" "ப")
+    ("u" "ற"))
+  "Mapping for vallinam consonants.")
+
+(defconst tamil99-mellinam-consonants
+  '(("b" "ங")
+    ("]" "ஞ")
+    ("p" "ண")
+    (";" "ந")
+    ("k" "ம")
+    ("i" "ன"))
+  "Mapping for mellinam consonants.")
+
+(defconst tamil99-idaiinam-consonants
+  '(("'" "ய")
+    ("m" "ர")
+    ("n" "ல")
+    ("v" "வ")
+    ("/" "ழ")
+    ("y" "ள"))
+  "Mapping for idaiinam consonants.")
+
+(defconst tamil99-grantham-consonants
+  '(("Q" "ஸ")
+    ("W" "ஷ")
+    ("E" "ஜ")
+    ("R" "ஹ"))
+  "Mapping for grantham consonants.")
+
+(defconst tamil99-consonants
+  (append tamil99-vallinam-consonants
+          tamil99-mellinam-consonants
+          tamil99-idaiinam-consonants
+          tamil99-grantham-consonants)
+  "Mapping for all consonants.")
+
+(defconst tamil99-other
+  `(("T" ,(vector "க்ஷ"))
+    ("Y" ,(vector "ஶஂரீ"))
+    ("O" "[")
+    ("P" "]")
+    ("A" "௹")
+    ("S" "௺")
+    ("D" "௸")
+    ("F" "ஃ")
+    ("K" "\"")
+    ("L" ":")
+    (":" ";")
+    ("\"" "'")
+    ("Z" "௳")
+    ("X" "௴")
+    ("C" "௵")
+    ("V" "௶")
+    ("B" "௷")
+    ("M" "/"))
+  "Mapping for miscellaneous characters.")
+
+(defun tamil99-install ()
+  "Install tamil99 input method."
+  (quail-define-rules)
+  ;; உயிர்
+  ;; vowel
+  (mapc (pcase-lambda (`(,vowel-key ,vowel))
+          (quail-defrule vowel-key vowel))
+        tamil99-vowels)
+  (mapc (pcase-lambda (`(,consonant-key ,consonant))
+          ;; அகர உயிர்மெய்
+          ;; consonant with agaram (அ)
+          (quail-defrule consonant-key consonant)
+          ;; மெய்யொற்று பின் அகர உயிர்மெய்
+          ;; pulli on double consonant
+          (quail-defrule (concat consonant-key consonant-key)
+                         (vector (concat consonant "்" consonant)))
+          (mapc (pcase-lambda (`(,vowel-key ,vowel-modifier))
+                  ;; உயிர்மெய்
+                  ;; vowel+consonant
+                  (quail-defrule (concat consonant-key vowel-key)
+                                 (vector (concat consonant vowel-modifier)))
+                  ;; மெய்யொற்று பின் உயிர்மெய்
+                  ;; vowel+consonant after double consonant
+                  (quail-defrule (concat consonant-key consonant-key vowel-key)
+                                 (vector (concat consonant "்" consonant vowel-modifier))))
+                tamil99-vowel-modifiers))
+        tamil99-consonants)
+  (seq-mapn (pcase-lambda (`(,mellinam-consonant-key ,mellinam-consonant)
+                           `(,vallinam-consonant-key ,vallinam-consonant))
+              ;; மெல்லினம் பின் வல்லினம்
+              ;; vallinam after mellinam
+              (quail-defrule (concat mellinam-consonant-key vallinam-consonant-key)
+                             (vector (concat mellinam-consonant "்" vallinam-consonant)))
+              (mapc (pcase-lambda (`(,vowel-key ,vowel-modifier))
+                      ;; மெல்லின ஒற்றொட்டிய வல்லினம் பின் உயிர்மெய்
+                      ;; vowel+consonant after mellinam-vallinam consonant
+                      (quail-defrule (concat mellinam-consonant-key vallinam-consonant-key vowel-key)
+                                     (vector (concat mellinam-consonant "்" vallinam-consonant vowel-modifier))))
+                    tamil99-vowel-modifiers))
+            tamil99-mellinam-consonants
+            tamil99-vallinam-consonants)
+  ;; பிற வரியுருக்கள்
+  ;; other characters
+  (mapc (pcase-lambda (`(,key ,translation))
+          (quail-defrule key translation))
+        tamil99-other))
+
+(tamil99-install)
+
+(provide 'tamil99)
+
+;;; tamil99.el ends here
-- 
2.37.2

bug#58070: [PATCH] Add tamil99 input method

[Visuwesh]

[-- Attachment #1: Type: text/plain, Size: 3671 bytes --]

[ஞாயிறு செப்டம்பர் 25, 2022] Arun Isaac wrote:

> +(defun tamil99-install ()
> +  "Install tamil99 input method."
> +  (quail-define-rules)
> +  ;; உயிர்
> +  ;; vowel
> +  (mapc (pcase-lambda (`(,vowel-key ,vowel))
> +          (quail-defrule vowel-key vowel))
> +        tamil99-vowels)
> +  (mapc (pcase-lambda (`(,consonant-key ,consonant))
> +          ;; அகர உயிர்மெய்
> +          ;; consonant with agaram (அ)
> +          (quail-defrule consonant-key consonant)
> +          ;; மெய்யொற்று பின் அகர உயிர்மெய்
> +          ;; pulli on double consonant
> +          (quail-defrule (concat consonant-key consonant-key)
> +                         (vector (concat consonant "்" consonant)))
> +          (mapc (pcase-lambda (`(,vowel-key ,vowel-modifier))
> +                  ;; உயிர்மெய்
> +                  ;; vowel+consonant
> +                  (quail-defrule (concat consonant-key vowel-key)
> +                                 (vector (concat consonant vowel-modifier)))
> +                  ;; மெய்யொற்று பின் உயிர்மெய்
> +                  ;; vowel+consonant after double consonant
> +                  (quail-defrule (concat consonant-key consonant-key vowel-key)
> +                                 (vector (concat consonant "்" consonant vowel-modifier))))
> +                tamil99-vowel-modifiers))
> +        tamil99-consonants)
> +  (seq-mapn (pcase-lambda (`(,mellinam-consonant-key ,mellinam-consonant)
> +                           `(,vallinam-consonant-key ,vallinam-consonant))
> +              ;; மெல்லினம் பின் வல்லினம்
> +              ;; vallinam after mellinam
> +              (quail-defrule (concat mellinam-consonant-key vallinam-consonant-key)
> +                             (vector (concat mellinam-consonant "்" vallinam-consonant)))
> +              (mapc (pcase-lambda (`(,vowel-key ,vowel-modifier))
> +                      ;; மெல்லின ஒற்றொட்டிய வல்லினம் பின் உயிர்மெய்
> +                      ;; vowel+consonant after mellinam-vallinam consonant
> +                      (quail-defrule (concat mellinam-consonant-key vallinam-consonant-key vowel-key)
> +                                     (vector (concat mellinam-consonant "்" vallinam-consonant vowel-modifier))))
> +                    tamil99-vowel-modifiers))
> +            tamil99-mellinam-consonants
> +            tamil99-vallinam-consonants)
> +  ;; பிற வரியுருக்கள்
> +  ;; other characters
> +  (mapc (pcase-lambda (`(,key ,translation))
> +          (quail-defrule key translation))
> +        tamil99-other))

Hi, I have a tamil99 keyboard layout in the works as well, and I'm
slowly dogfeeding it whilst also learning the layout.  I use a different
approach to add these special rules: using a UPDATE-TRANSLATION-FUNCTION.
This has the advantage that you can insert the vowel sign for any
consonant out-of-sequence i.e., you can say h j BACKSPACE s
to insert கி (and so do other rules).  WDYT about this approach, is this
feasible?

AFAIK, MS Windows' tamil99 keyboard layout behaves like mine, whereas
the ibus layout behaves like your implementation.  If you are a heavy
user of this layout, can you try out the attached?

The only reason why I haven't submitted a patch so far is because I was
not sure if my implementation wasn't riddled of bugs.


[-- Attachment #2: tamil99.el --]
[-- Type: application/emacs-lisp, Size: 8998 bytes --]

bug#58070: [PATCH] Add tamil99 input method

[Eli Zaretskii]

> Cc: 58070@debbugs.gnu.org
> From: Visuwesh <visuweshm@gmail.com>
> Date: Sun, 25 Sep 2022 17:08:50 +0530
> 
> AFAIK, MS Windows' tamil99 keyboard layout behaves like mine, whereas
> the ibus layout behaves like your implementation.  If you are a heavy
> user of this layout, can you try out the attached?

Please note that we could have support for both layouts, there's no
particular reason we should have only one.

bug#58070: [PATCH] Add tamil99 input method

[Visuwesh]

[ஞாயிறு செப்டம்பர் 25, 2022] Eli Zaretskii wrote:

>> AFAIK, MS Windows' tamil99 keyboard layout behaves like mine, whereas
>> the ibus layout behaves like your implementation.  If you are a heavy
>> user of this layout, can you try out the attached?
>
> Please note that we could have support for both layouts, there's no
> particular reason we should have only one.

Yes of course but I'm afraid that it will create unneeded confusion,
since the differences are quite subtle.  So I would prefer the layout
which is familiar to most users to get in core.
[ If I seemed hasty about getting feedback for my code, it is merely
  because I cannot be the lab rat myself since I type like a sloth in
  Tamil99 layout.  Moreover, my original goal was to add the layout for
  Emacs 29.  ]

bug#58070: [PATCH] Add tamil99 input method

[Eli Zaretskii]

> From: Visuwesh <visuweshm@gmail.com>
> Cc: arunisaac@systemreboot.net,  58070@debbugs.gnu.org
> Date: Sun, 25 Sep 2022 19:44:44 +0530
> 
> [ஞாயிறு செப்டம்பர் 25, 2022] Eli Zaretskii wrote:
> 
> >> AFAIK, MS Windows' tamil99 keyboard layout behaves like mine, whereas
> >> the ibus layout behaves like your implementation.  If you are a heavy
> >> user of this layout, can you try out the attached?
> >
> > Please note that we could have support for both layouts, there's no
> > particular reason we should have only one.
> 
> Yes of course but I'm afraid that it will create unneeded confusion,
> since the differences are quite subtle.

Why do you think it will confuse users to have two input methods, each
one for one of the layouts?  If the supported layout is clearly stated
in the documentation (or even in the name of the IM), why would it
confuse?

Please note that we already have several examples where different
input methods for the same language are offered, one each for every
keyboard layout we think users could find useful.  Is Tamil different
in some way?

> So I would prefer the layout which is familiar to most users to get
> in core.

If one of the layouts comes from Windows, the other from Unix, we are
likely to have two large groups of users, each one of which is
familiar with a different layout.  Why not offer them both what they
are familiar with?

bug#58070: [PATCH] Add tamil99 input method

[Visuwesh]

[ஞாயிறு செப்டம்பர் 25, 2022] Eli Zaretskii wrote:

>> From: Visuwesh <visuweshm@gmail.com>
>> Cc: arunisaac@systemreboot.net,  58070@debbugs.gnu.org
>> Date: Sun, 25 Sep 2022 19:44:44 +0530
>> 
>> [ஞாயிறு செப்டம்பர் 25, 2022] Eli Zaretskii wrote:
>> 
>> >> AFAIK, MS Windows' tamil99 keyboard layout behaves like mine, whereas
>> >> the ibus layout behaves like your implementation.  If you are a heavy
>> >> user of this layout, can you try out the attached?
>> >
>> > Please note that we could have support for both layouts, there's no
>> > particular reason we should have only one.
>> 
>> Yes of course but I'm afraid that it will create unneeded confusion,
>> since the differences are quite subtle.
>
> Why do you think it will confuse users to have two input methods, each
> one for one of the layouts?  If the supported layout is clearly stated
> in the documentation (or even in the name of the IM), why would it
> confuse?

They are both named "Tamil99", just slightly different implementations.
In that case, how do you propose to name these slightly different
implementations that have a single name---Tamil99?  They are identical
majorly in that they both have the same layout but the "special rules"
intended to ease the pain of typing Tamil in a computer are handled
differently.
If you prefer, I can quote the spec and explain the differences between
Windows' and ibus' implementations.

> Please note that we already have several examples where different
> input methods for the same language are offered, one each for every
> keyboard layout we think users could find useful.  Is Tamil different
> in some way?

No, Tamil is not any different.  But the confusion is caused by the
_implementation detail_.  Since the specs is not clear enough [1], you
end up with subtly different implementations of the keyboard layout.

>> So I would prefer the layout which is familiar to most users to get
>> in core.
>
> If one of the layouts comes from Windows, the other from Unix, we are
> likely to have two large groups of users, each one of which is
> familiar with a different layout.  Why not offer them both what they
> are familiar with?

Microsoft added the layout in 2018 in Windows 10.  I have no idea when
the ibus layout was added.  We could offer both, but Someone™ will need
to come up with a clear name.

I hope my stance is now clear.

[1] http://www.tamilvu.org/tkbd/Tamil_Unicode_G.O.zip

bug#58070: [PATCH] Add tamil99 input method

[Eli Zaretskii]

> From: Visuwesh <visuweshm@gmail.com>
> Cc: arunisaac@systemreboot.net,  58070@debbugs.gnu.org
> Date: Sun, 25 Sep 2022 20:08:29 +0530
> 
> >
> > Why do you think it will confuse users to have two input methods, each
> > one for one of the layouts?  If the supported layout is clearly stated
> > in the documentation (or even in the name of the IM), why would it
> > confuse?
> 
> They are both named "Tamil99", just slightly different implementations.
> In that case, how do you propose to name these slightly different
> implementations that have a single name---Tamil99?

No, they should have 2 different names, of course.  Say, Tamil99-ibus
and Tamil99-windows.

bug#58070: [PATCH] Add tamil99 input method

[Arun Isaac]

>> > Why do you think it will confuse users to have two input methods, each
>> > one for one of the layouts?  If the supported layout is clearly stated
>> > in the documentation (or even in the name of the IM), why would it
>> > confuse?
>> 
>> They are both named "Tamil99", just slightly different implementations.
>> In that case, how do you propose to name these slightly different
>> implementations that have a single name---Tamil99?
>
> No, they should have 2 different names, of course.  Say, Tamil99-ibus
> and Tamil99-windows.

I do agree with Visuwesh that we should not offer two separate input
methods---one for each implementation. Our code is but two different
implementations of *exactly* the same input method. The differences in
behaviour are far too subtle and would only confuse the user.

bug#58070: [PATCH] Add tamil99 input method

[Eli Zaretskii]

> From: Arun Isaac <arunisaac@systemreboot.net>
> Cc: 58070@debbugs.gnu.org
> Date: Tue, 27 Sep 2022 02:29:17 +0530
> 
> I do agree with Visuwesh that we should not offer two separate input
> methods---one for each implementation. Our code is but two different
> implementations of *exactly* the same input method. The differences in
> behaviour are far too subtle and would only confuse the user.

I thought they assumed different keyboard layout?

Anyway, even for the same layout, it is not unthinkable to have
several input methods, we already have that for other scripts.  For
example, if they offer distinct features that some users could want,
but at the price of some additional complexity of input sequences.

bug#58070: [PATCH] Add tamil99 input method

[Arun Isaac]

>> I do agree with Visuwesh that we should not offer two separate input
>> methods---one for each implementation. Our code is but two different
>> implementations of *exactly* the same input method. The differences in
>> behaviour are far too subtle and would only confuse the user.
>
> I thought they assumed different keyboard layout?

Not sure what exactly you mean by "keyboard layout" in this
context. But, if you're talking about qwerty, dvorak, etc., then using
quail-keyboard-layout, both implementations can support any keyboard
layout.

bug#58070: [PATCH] Add tamil99 input method

[Arun Isaac]

Hi,

> I have a tamil99 keyboard layout in the works as well, and I'm slowly
> dogfeeding it whilst also learning the layout.  I use a different
> approach to add these special rules: using a
> UPDATE-TRANSLATION-FUNCTION.
>
> WDYT about this approach, is this feasible?

Nice to see your code, Visuwesh. Sorry to have duplicated your work, but
it happens at times! ;-) I wrote my implementation of tamil99 more than
a year ago, and have been using it privately since. But only last month,
I finished it properly and published it in a git repo at
https://git.systemreboot.net/tamil99/about/

> The only reason why I haven't submitted a patch so far is because I was
> not sure if my implementation wasn't riddled of bugs.

I know the feeling. I empathize. :-)

I see that Visuwesh's implementation takes an imperative mutational
approach, whereas mine is a more functional declarative approach which
enumerates all possible rules into a quail map.

The imperative approach is indeed more powerful since it is arbitrary
code and can do anything. But, I feel that is not really necessary for a
relatively simple input method like tamil99.

The declarative approach results in shorter and more readable code. It
also gives us nice features such as the keyboard layout visualization
and the key sequence tabulation in describe-input-method.

> AFAIK, MS Windows' tamil99 keyboard layout behaves like mine, whereas
> the ibus layout behaves like your implementation.  If you are a heavy
> user of this layout, can you try out the attached?

Indeed, I do use the tamil99 input method almost every day.

I tried out your implementation, and am having difficulty getting it
working correctly. This is likely because I have an Ergodox keyboard
with a non-standard keyboard layout. I have told quail about this
keyboard layout by setting the quail-keyboard-layout variable. But, your
implementation assumes a qwerty layout. It should instead call
quail-keyboard-translate or quail-keyseq-translate to translate
keystrokes. My declarative implementation does this correctly since I
don't directly touch the quail state machine, and merely instruct quail
to do the necessary translation by passing a non-nil kbd-translate
argument to quail-define-package.

> This has the advantage that you can insert the vowel sign for any
> consonant out-of-sequence i.e., you can say h j BACKSPACE s
> to insert கி (and so do other rules).

I agree. Your imperative approach does have this advantage. But, it
comes at the price of having to inspect the buffer at (point). The
declarative approach does not need to inspect the buffer at all since it
merely composes sequential keystrokes and doesn't know anything about
what's already on the buffer. I personally think buffer inspection is a
lot of code complexity for a simple input method like tamil99, but
perhaps Eli should take a call on this.

Also, while the out-of-sequence vowel insertion is a very clever
feature, it shouldn't be required at all if we handled grapheme cluster
boundaries correctly. See
https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries Let me
explain with a latin example for the benefit of non-Tamil
readers. Suppose we had:

g̀|

where | is the position of the cursor. Now, if we press backspace, the
entire g+grave accent grapheme cluster should be deleted. But, what
actually happens is that the grave accent alone is deleted and we are
left with a 'g' like so:

g|

A similar thing happens in Tamil. Now, based on user expectation, this
may be acceptable in some languages. But, in Tamil, it is quite contrary
to user expectation. If I have

கி|

and press backspace, I get:

க|

But, I want the whole "user-perceived character" (கி) deleted like so:

|

I would happily submit a patch fixing this if I knew where the fix
should be applied. My guess is that this is outside the scope of quail,
and probably even outside the scope of Emacs. Any insight on this would
be much appreciated.

Regards,
Arun

bug#58070: [PATCH] Add tamil99 input method

[Visuwesh]

[செவ்வாய் செப்டம்பர் 27, 2022] Arun Isaac wrote:

> Hi,
>
>> I have a tamil99 keyboard layout in the works as well, and I'm slowly
>> dogfeeding it whilst also learning the layout.  I use a different
>> approach to add these special rules: using a
>> UPDATE-TRANSLATION-FUNCTION.
>>
>> WDYT about this approach, is this feasible?
>
> Nice to see your code, Visuwesh. Sorry to have duplicated your work, but
> it happens at times! ;-) 

No need to apologise!  We both are trying to make typing Tamil more
pleasant, after all.

>> The only reason why I haven't submitted a patch so far is because I was
>> not sure if my implementation wasn't riddled of bugs.
>
> I know the feeling. I empathize. :-)
>
> I see that Visuwesh's implementation takes an imperative mutational
> approach, whereas mine is a more functional declarative approach which
> enumerates all possible rules into a quail map.
>
> The imperative approach is indeed more powerful since it is arbitrary
> code and can do anything. But, I feel that is not really necessary for a
> relatively simple input method like tamil99.

See below to see why I think checking the buffer is a pleasant
experience.

> The declarative approach results in shorter and more readable code. It
> also gives us nice features such as the keyboard layout visualization
> and the key sequence tabulation in describe-input-method.

Funnily enough, I went with the imperative approach mainly because I
couldn't wrap my head around generating all the possible keysequences.
It seemed much simpler to just look at the buffer and figure out what
needed to be done.

>> AFAIK, MS Windows' tamil99 keyboard layout behaves like mine, whereas
>> the ibus layout behaves like your implementation.  If you are a heavy
>> user of this layout, can you try out the attached?
>
> Indeed, I do use the tamil99 input method almost every day.
>
> I tried out your implementation, and am having difficulty getting it
> working correctly. This is likely because I have an Ergodox keyboard
> with a non-standard keyboard layout. I have told quail about this
> keyboard layout by setting the quail-keyboard-layout variable. But, your
> implementation assumes a qwerty layout. It should instead call
> quail-keyboard-translate or quail-keyseq-translate to translate
> keystrokes.

Hmm, this is weird.  I thought Quail did the translation job for me
which is why I boldly assumed the qwerty layout and coded it that way.
I will try to change Xorg's keyboard layout and test it.  Thanks for
testing!

> My declarative implementation does this correctly since I don't
> directly touch the quail state machine, and merely instruct quail to
> do the necessary translation by passing a non-nil kbd-translate
> argument to quail-define-package.
 
Here, I'm confused.  I pass a non-nil KBD-TRANSLATE argument as well...

>> This has the advantage that you can insert the vowel sign for any
>> consonant out-of-sequence i.e., you can say h j BACKSPACE s
>> to insert கி (and so do other rules).
>
> I agree. Your imperative approach does have this advantage. But, it
> comes at the price of having to inspect the buffer at (point). The
> declarative approach does not need to inspect the buffer at all since it
> merely composes sequential keystrokes and doesn't know anything about
> what's already on the buffer. I personally think buffer inspection is a
> lot of code complexity for a simple input method like tamil99, but
> perhaps Eli should take a call on this.

Despite writing the tamil-phonetic keyboard layout, I disliked how much
backspacing and rewriting letters I needed to do when I found a simple
kuril-nedil typo, etc.  Check-the-buffer approach eases these
corrections tremendously and is more close to the experience of writing
on paper.
I might be biased but I don't think the code is that complex: once I
figured out which Quail variables to modify, it was a simple process of
following the rules section of Tamil99's specs.

> Also, while the out-of-sequence vowel insertion is a very clever
> feature, it shouldn't be required at all if we handled grapheme cluster
> boundaries correctly. 

While what you say is great for when we go from uyirmei to uyirmei,
sometimes you just need to add a vowel sign to a agara mei easily and be
done with it which is what I tried to achieve with my implementation.

> [...]
> I would happily submit a patch fixing this if I knew where the fix
> should be applied. My guess is that this is outside the scope of quail,
> and probably even outside the scope of Emacs. Any insight on this would
> be much appreciated.

Emacs 29's delete-forward-char deletes by grapheme clusters now.  It is
now a job of writing a backward version of the grapheme cluster
detection code.  I poked around in the C code to see how
find-composition-internal was implemented, and it looked *relatively*
straightforward to get a backward searching function working.  I might
be wrong here, so I hope Eli corrects my misunderstandings.

bug#58070: [PATCH] Add tamil99 input method

[Visuwesh]

[செவ்வாய் செப்டம்பர் 27, 2022] Visuwesh wrote:

>> I tried out your implementation, and am having difficulty getting it
>> working correctly. This is likely because I have an Ergodox keyboard
>> with a non-standard keyboard layout. I have told quail about this
>> keyboard layout by setting the quail-keyboard-layout variable. But, your
>> implementation assumes a qwerty layout. It should instead call
>> quail-keyboard-translate or quail-keyseq-translate to translate
>> keystrokes.
>
> Hmm, this is weird.  I thought Quail did the translation job for me
> which is why I boldly assumed the qwerty layout and coded it that way.
> I will try to change Xorg's keyboard layout and test it.  Thanks for
> testing!

[ Looks like Quail does not hold your hand in the
  UPDATE-TRANSLATION-FUNCTION.  Reading `quail-update-translation'
  again, I see the block about keysequence translation now.  ]

>> [...] merely instruct quail to do the necessary translation by
>> passing a non-nil kbd-translate argument to quail-define-package.
>  
> Here, I'm confused.  I pass a non-nil KBD-TRANSLATE argument as well...

Thanks for the hint on quail-keyseq-translate, I fixed it with the
following patch

diff --git a/tamil99.el b/tamil99.el
index 3461ccd..7262d30 100644
--- a/tamil99.el
+++ b/tamil99.el
@@ -105,7 +105,7 @@ consonant pair or hard-soft consonant pair was handled.")
   ;; pulli regardless of the character before point.
   (cond
    ((eq flag t)
-    (let ((key quail-current-key))
+    (let ((key (quail-keyseq-translate quail-current-key)))
       (cond
        ((and (equal key "W")
              (and (eq (char-before (point)) ?்)

bug#58070: [PATCH] Add tamil99 input method

[Eli Zaretskii]

> Cc: 58070@debbugs.gnu.org
> From: Visuwesh <visuweshm@gmail.com>
> Date: Tue, 27 Sep 2022 07:19:17 +0530
> 
> > I would happily submit a patch fixing this if I knew where the fix
> > should be applied. My guess is that this is outside the scope of quail,
> > and probably even outside the scope of Emacs. Any insight on this would
> > be much appreciated.
> 
> Emacs 29's delete-forward-char deletes by grapheme clusters now.  It is
> now a job of writing a backward version of the grapheme cluster
> detection code.  I poked around in the C code to see how
> find-composition-internal was implemented, and it looked *relatively*
> straightforward to get a backward searching function working.  I might
> be wrong here, so I hope Eli corrects my misunderstandings.

I don't think I understand what you are after.  Please elaborate on
the "backward version of the grapheme cluster detection code", and its
purpose in this context.

bug#58070: [PATCH] Add tamil99 input method

[Visuwesh]

[செவ்வாய் செப்டம்பர் 27, 2022] Eli Zaretskii wrote:

>> Emacs 29's delete-forward-char deletes by grapheme clusters now.  It is
>> now a job of writing a backward version of the grapheme cluster
>> detection code.  I poked around in the C code to see how
>> find-composition-internal was implemented, and it looked *relatively*
>> straightforward to get a backward searching function working.  I might
>> be wrong here, so I hope Eli corrects my misunderstandings.
>
> I don't think I understand what you are after.  Please elaborate on
> the "backward version of the grapheme cluster detection code", and its
> purpose in this context.

In delete-forward-char, we use find-composition to get the extend of the
current glyphs in terms of characters.  AFAICT, find-composition does a
forward search for the 'composition' text property.  My proposal was
that we write a find-composition variant that would do a backward search
for the 'composition' text property which we then can make of use in
delete-backward-char.

We cannot simply do backward-char then delete-forward-char and bind it
to a command since IIRC the grapheme cluster movement happens in the
display code?  M-: (progn (backward-char 1) (delete-forward-char 1)) RET
deletes கு| to | (| being point) whereas if I define the above as a
command named test, and call it via M-x test RET it gives க| instead.
Which is why I said we need a "backward version of the grapheme cluster
detection code."  

HTH.

bug#58070: [PATCH] Add tamil99 input method

[Eli Zaretskii]

> From: Visuwesh <visuweshm@gmail.com>
> Cc: arunisaac@systemreboot.net,  58070@debbugs.gnu.org
> Date: Tue, 27 Sep 2022 13:04:48 +0530
> 
> In delete-forward-char, we use find-composition to get the extend of the
> current glyphs in terms of characters.  AFAICT, find-composition does a
> forward search for the 'composition' text property.  My proposal was
> that we write a find-composition variant that would do a backward search
> for the 'composition' text property which we then can make of use in
> delete-backward-char.

You are looking at the wrong branch of the code.  There's no
'composition' text property in the case that is of interest to you;
the characters are composed by the so-called "automatic composition",
whereby Emacs decides which characters to compose without any special
text property.  The relevant code is in find_automatic_composition,
which is called by find-composition-internal.

In any case, my suggestion for finding composition backward is to
incrementally go back and call find-composition-internal, until it
fails to find a composition at or before point.

The next question will be: what would be the key to which you'd bind
this new command?

> We cannot simply do backward-char then delete-forward-char and bind it
> to a command since IIRC the grapheme cluster movement happens in the
> display code?

No, it happens in the command loop.  See adjust_point_for_property,
which calls composition_adjust_point.  I don't think this is important
for the issue at hand, because the point adjustment happens only after
interactive commands.

bug#58070: [PATCH] Add tamil99 input method

[Robert Pluim]

>>>>> On Tue, 27 Sep 2022 10:53:31 +0300, Eli Zaretskii <eliz@gnu.org> said:

    Eli> In any case, my suggestion for finding composition backward is to
    Eli> incrementally go back and call find-composition-internal, until it
    Eli> fails to find a composition at or before point.

or until the glyph-string id changes, no? There could be two grapheme
clusters next to each other.

    Eli> The next question will be: what would be the key to which you'd bind
    Eli> this new command?

DEL, but only for those people who want the new behaviour. The tricky
bit is then how to get the old behaviour somewhere. M- - DEL already
deletes forward, but M-0 DEL does nothing as far as I know.

Robert
-- 

bug#58070: [PATCH] Add tamil99 input method

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Visuwesh <visuweshm@gmail.com>,  arunisaac@systemreboot.net,
>   58070@debbugs.gnu.org
> Date: Tue, 27 Sep 2022 11:24:12 +0200
> 
> >>>>> On Tue, 27 Sep 2022 10:53:31 +0300, Eli Zaretskii <eliz@gnu.org> said:
> 
>     Eli> In any case, my suggestion for finding composition backward is to
>     Eli> incrementally go back and call find-composition-internal, until it
>     Eli> fails to find a composition at or before point.
> 
> or until the glyph-string id changes, no? There could be two grapheme
> clusters next to each other.

Yes, comparison of the results returned by find-composition-internal
is necessary.

>     Eli> The next question will be: what would be the key to which you'd bind
>     Eli> this new command?
> 
> DEL, but only for those people who want the new behaviour. The tricky
> bit is then how to get the old behaviour somewhere. M- - DEL already
> deletes forward, but M-0 DEL does nothing as far as I know.

That's exactly the dilemma.  Maybe using the zero argument is the best
solution.

bug#58070: [PATCH] Add tamil99 input method

[Visuwesh]

[செவ்வாய் செப்டம்பர் 27, 2022] Eli Zaretskii wrote:

>> From: Visuwesh <visuweshm@gmail.com>
>> Cc: arunisaac@systemreboot.net,  58070@debbugs.gnu.org
>> Date: Tue, 27 Sep 2022 13:04:48 +0530
>> 
>> In delete-forward-char, we use find-composition to get the extend of the
>> current glyphs in terms of characters.  AFAICT, find-composition does a
>> forward search for the 'composition' text property.  My proposal was
>> that we write a find-composition variant that would do a backward search
>> for the 'composition' text property which we then can make of use in
>> delete-backward-char.
>
> You are looking at the wrong branch of the code.  There's no
> 'composition' text property in the case that is of interest to you;
> the characters are composed by the so-called "automatic composition",
> whereby Emacs decides which characters to compose without any special
> text property.  The relevant code is in find_automatic_composition,
> which is called by find-composition-internal.

My recollection of the find-composition-internal was that it eventually
fell back to a text property search even for automatic compositions but
I see now that's not the case.  Thanks for setting me straight.

> In any case, my suggestion for finding composition backward is to
> incrementally go back and call find-composition-internal, until it
> fails to find a composition at or before point.

Thanks, I will see what I can do.

> The next question will be: what would be the key to which you'd bind
> this new command?

I thought a user option that would make DEL delete by grapheme clusters
would do the job.

>> We cannot simply do backward-char then delete-forward-char and bind it
>> to a command since IIRC the grapheme cluster movement happens in the
>> display code?
>
> No, it happens in the command loop.  See adjust_point_for_property,
> which calls composition_adjust_point.  I don't think this is important
> for the issue at hand, because the point adjustment happens only after
> interactive commands.

bug#58070: [PATCH] Add tamil99 input method

[Arun Isaac]

> Emacs 29's delete-forward-char deletes by grapheme clusters now.  It
> is now a job of writing a backward version of the grapheme cluster
> detection code.  I poked around in the C code to see how
> find-composition-internal was implemented, and it looked *relatively*
> straightforward to get a backward searching function working.  I might
> be wrong here, so I hope Eli corrects my misunderstandings.

This is great news! I'm still on Emacs 28.1, and I'm looking forward to
this new feature.

bug#58070: [PATCH] Add tamil99 input method

[Eli Zaretskii]

> Cc: 58070@debbugs.gnu.org
> From: Arun Isaac <arunisaac@systemreboot.net>
> Date: Tue, 27 Sep 2022 02:25:28 +0530
> 
> > This has the advantage that you can insert the vowel sign for any
> > consonant out-of-sequence i.e., you can say h j BACKSPACE s
> > to insert கி (and so do other rules).
> 
> I agree. Your imperative approach does have this advantage. But, it
> comes at the price of having to inspect the buffer at (point). The
> declarative approach does not need to inspect the buffer at all since it
> merely composes sequential keystrokes and doesn't know anything about
> what's already on the buffer. I personally think buffer inspection is a
> lot of code complexity for a simple input method like tamil99, but
> perhaps Eli should take a call on this.

I don't think I understand what you are talking about (I'm not an
expert on Quail).  Does this complexity slow down the input
noticeably?  Does it make the code much harder to understand, even if
you put enough comments there to explain what's going on?  If not,
then I don't think the added complexity should be a problem, and you
should decide based on other aspects.

And as I said earlier, we could have two input methods for Tamil, so
we don't necessarily have to decide which of the two is better.

> Also, while the out-of-sequence vowel insertion is a very clever
> feature, it shouldn't be required at all if we handled grapheme cluster
> boundaries correctly. See
> https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries

Well, we do, that's why cursor motion moves by grapheme clusters,
right?  Also, see below.

> Let me explain with a latin example for the benefit of non-Tamil
> readers. Suppose we had:
> 
> g̀|
> 
> where | is the position of the cursor. Now, if we press backspace, the
> entire g+grave accent grapheme cluster should be deleted. But, what
> actually happens is that the grave accent alone is deleted and we are
> left with a 'g' like so:
> 
> g|
> 
> A similar thing happens in Tamil. Now, based on user expectation, this
> may be acceptable in some languages. But, in Tamil, it is quite contrary
> to user expectation. If I have
> 
> கி|
> 
> and press backspace, I get:
> 
> க|
> 
> But, I want the whole "user-perceived character" (கி) deleted like so:
> 
> |

There's a problem with the above: in some situations you want deletion
by codepoints, in others you want deletion by grapheme clusters.  (It
is possible that with Tamil the former is rarely the case, but it is
definitely a frequent case with other scripts, in particular with
those that have diacriticals.)  Emacs 29 solves this by having
delete-forward-char, which is usually bound to the <Delete> key,
delete by grapheme clusters, while DEL (which deletes backward) and
C-d delete individual codepoints.  The primary motivation for DEL to
delete by codepoints is that it allows you to make sub-grapheme
corrections to stuff you just typed, for example if you typed an
incorrect accent.

Emacs 29 also has the composition-break-at-point variable, which you
could set non-nil, in which case <Delete> will also work by
codepoints.  So perhaps the out-of-sequence vowel insertion would be
possible without further complications if composition-break-at-point
is non-nil?

bug#58070: [PATCH] Add tamil99 input method

[Visuwesh]

[செவ்வாய் செப்டம்பர் 27, 2022] Eli Zaretskii wrote:

Some bits about tamil99 layout first:

    Tamil99 layout has two parts: the physical keyboard layout akin to
    QWERTY, Dvorak, workman, etc. and the special "rules" which are
    supposed to combine vowels and consonants, and ease typing certain
    character sequences.  Tamil has vowels, consonants, and
    vowel-consonant pairs.  When you combine a consonant and a vowel
    sign, you get a vowel-consonant pair.  Tamil99's special "rules"
    comes into the picture here: these rules tell you how to write these
    vowel-consonant pairs as the layout itself does not have keys to
    type all the possible vowel-consonant pairs.
    E.g., h maps to the consonant க, d maps to the vowel உ.  When you
    type h d, you get கு.  This is basically what the rules say.

I will explain how our implementations differ below.

>> I agree. Your imperative approach does have this advantage. But, it
>> comes at the price of having to inspect the buffer at (point). The
>> declarative approach does not need to inspect the buffer at all since it
>> merely composes sequential keystrokes and doesn't know anything about
>> what's already on the buffer. I personally think buffer inspection is a
>> lot of code complexity for a simple input method like tamil99, but
>> perhaps Eli should take a call on this.
>
> I don't think I understand what you are talking about (I'm not an
> expert on Quail).  

Arun's implementation precalculates the key sequences that produce
vowel-consonant pairs and adds them as separate Quail rules, kind of
what happens in the itrans IMs.  So in the quail-map, you have rules
like "h" = க, "d" = உ, "hd" = கு which works great until you run into a
situation like Eric described in emacs-devel here: https://yhetil.org/emacs-devel/87a66ori6g.fsf@gmail.com/T/#m5b261c1a7bb06c7c074fdcdb746fb53ab7af1aa1

I'm sure that situation is familiar to many who use Quail IMs regularly,
which is why I decided to make my IM consider the character before point
to decide what codepoint Quail should insert in the buffer.  In my
implementation, the quail-map only has "h" = க, "d" = உ.  I use the
UPDATE-TRANSLATION-FUNCTION to see what the character before point is
and change what Quail should insert: if the user types 'd' and the
character before point is a 'க', then I make Quail insert ு (instead of
உ) to get கு.  This lets you insert vowel-consonant pairs out-of-order
which is akin to what Eric wants.

> Does this complexity slow down the input noticeably?

This I cannot tell since I am not a fast enough typist.  Each keystroke
looks up two to three alists of differing sizes on each input.  If it
leads to a noticeable slowdown, then we can replace the alists with a
hashtable instead.

> Does it make the code much harder to understand, even if you put
> enough comments there to explain what's going on?  If not, then I
> don't think the added complexity should be a problem, and you should
> decide based on other aspects.

I tried to comment almost everything I do for the future maintainers,
and use the same language as the keyboard layout's spec does (linked in
the file's Commentary).

>
>> Let me explain with a latin example for the benefit of non-Tamil
>> readers. Suppose we had:
>> 
>> [...]
>
> [...]
>
> Emacs 29 also has the composition-break-at-point variable, which you
> could set non-nil, in which case <Delete> will also work by
> codepoints.  So perhaps the out-of-sequence vowel insertion would be
> possible without further complications if composition-break-at-point
> is non-nil?

Unfortunately, composition-break-at-point is not enough here since the
layout does not have keys to insert the *vowel signs* (the grave accent
in Arun's example), only *vowels*.

bug#58070: [PATCH] Add tamil99 input method

[Eli Zaretskii]

> From: Visuwesh <visuweshm@gmail.com>
> Cc: Arun Isaac <arunisaac@systemreboot.net>,  58070@debbugs.gnu.org
> Date: Tue, 27 Sep 2022 13:22:02 +0530
> 
> Arun's implementation precalculates the key sequences that produce
> vowel-consonant pairs and adds them as separate Quail rules, kind of
> what happens in the itrans IMs.  So in the quail-map, you have rules
> like "h" = க, "d" = உ, "hd" = கு which works great until you run into a
> situation like Eric described in emacs-devel here: https://yhetil.org/emacs-devel/87a66ori6g.fsf@gmail.com/T/#m5b261c1a7bb06c7c074fdcdb746fb53ab7af1aa1
> 
> I'm sure that situation is familiar to many who use Quail IMs regularly,
> which is why I decided to make my IM consider the character before point
> to decide what codepoint Quail should insert in the buffer.  In my
> implementation, the quail-map only has "h" = க, "d" = உ.  I use the
> UPDATE-TRANSLATION-FUNCTION to see what the character before point is
> and change what Quail should insert: if the user types 'd' and the
> character before point is a 'க', then I make Quail insert ு (instead of
> உ) to get கு.  This lets you insert vowel-consonant pairs out-of-order
> which is akin to what Eric wants.

But the price is that, after typing "h", your implementation doesn't
show in the echo-area that one of the possible next candidates is "d",
whereas Arun's implementation does, is that right?

> > Emacs 29 also has the composition-break-at-point variable, which you
> > could set non-nil, in which case <Delete> will also work by
> > codepoints.  So perhaps the out-of-sequence vowel insertion would be
> > possible without further complications if composition-break-at-point
> > is non-nil?
> 
> Unfortunately, composition-break-at-point is not enough here since the
> layout does not have keys to insert the *vowel signs* (the grave accent
> in Arun's example), only *vowels*.

One could add those missing keys, no?

Anyway, composition-break-at-point doesn't have to be useful with each
IM, that's not necessarily its main purpose.

bug#58070: [PATCH] Add tamil99 input method

[Visuwesh]

[செவ்வாய் செப்டம்பர் 27, 2022] Eli Zaretskii wrote:

>> Arun's implementation precalculates the key sequences that produce
>> vowel-consonant pairs and adds them as separate Quail rules, kind of
>> what happens in the itrans IMs.  So in the quail-map, you have rules
>> like "h" = க, "d" = உ, "hd" = கு which works great until you run into a
>> situation like Eric described in emacs-devel here:
>> https://yhetil.org/emacs-devel/87a66ori6g.fsf@gmail.com/T/#m5b261c1a7bb06c7c074fdcdb746fb53ab7af1aa1
>> 
>> I'm sure that situation is familiar to many who use Quail IMs regularly,
>> which is why I decided to make my IM consider the character before point
>> to decide what codepoint Quail should insert in the buffer.  In my
>> implementation, the quail-map only has "h" = க, "d" = உ.  I use the
>> UPDATE-TRANSLATION-FUNCTION to see what the character before point is
>> and change what Quail should insert: if the user types 'd' and the
>> character before point is a 'க', then I make Quail insert ு (instead of
>> உ) to get கு.  This lets you insert vowel-consonant pairs out-of-order
>> which is akin to what Eric wants.
>
> But the price is that, after typing "h", your implementation doesn't
> show in the echo-area that one of the possible next candidates is "d",
> whereas Arun's implementation does, is that right?

Yes, you are correct.  However, the price is small and it is the same
one Dvorak users pay when using a laptop that has a qwerty layout
keyboard, so not much IMO.

>> > Emacs 29 also has the composition-break-at-point variable, which you
>> > could set non-nil, in which case <Delete> will also work by
>> > codepoints.  So perhaps the out-of-sequence vowel insertion would be
>> > possible without further complications if composition-break-at-point
>> > is non-nil?
>> 
>> Unfortunately, composition-break-at-point is not enough here since the
>> layout does not have keys to insert the *vowel signs* (the grave accent
>> in Arun's example), only *vowels*.
>
> One could add those missing keys, no?

The problem is finding the place to put them.  All the alphabet keys and
all symbol keys except one or two in a standard US layout are occupied.
Tamil99 does put the vowel signs under ^[LETTER] but that is simply
cumbersome to type.

bug#58070: [PATCH] Add tamil99 input method

[Arun Isaac]

> But the price is that, after typing "h", your implementation doesn't
> show in the echo-area that one of the possible next candidates is "d",
> whereas Arun's implementation does, is that right?

tamil99 users don't think of the characters on the qwerty keyboard when
they're typing. They operate on a mental map of the keyboard---something
like
https://commons.wikimedia.org/wiki/File:Tamil99_Key_Bord_foto_of_Thamizhpparithi_Maari.jpg
So, to be honest, the suggestion of possible next candidates is not very
informative for the tamil99 input method. In fact, it's quite a
distraction. So, I wouldn't mind disabling the suggestions if
possible. Is it possible?

bug#58070: [PATCH] Add tamil99 input method

[Eli Zaretskii]

> From: Arun Isaac <arunisaac@systemreboot.net>
> Cc: 58070@debbugs.gnu.org
> Date: Wed, 12 Oct 2022 14:10:04 +0530
> 
> 
> > But the price is that, after typing "h", your implementation doesn't
> > show in the echo-area that one of the possible next candidates is "d",
> > whereas Arun's implementation does, is that right?
> 
> tamil99 users don't think of the characters on the qwerty keyboard when
> they're typing. They operate on a mental map of the keyboard---something
> like
> https://commons.wikimedia.org/wiki/File:Tamil99_Key_Bord_foto_of_Thamizhpparithi_Maari.jpg
> So, to be honest, the suggestion of possible next candidates is not very
> informative for the tamil99 input method.

Please don't forget that input methods are not only for native
speakers of the respective languages, they are also for others.  And
those others do benefit from the display of the next candidates.

> In fact, it's quite a distraction. So, I wouldn't mind disabling the
> suggestions if possible. Is it possible?

Try setting input-method-verbose-flag to the nil value.

bug#58070: [PATCH] Add tamil99 input method

[Arun Isaac]

>> In fact, it's quite a distraction. So, I wouldn't mind disabling the
>> suggestions if possible. Is it possible?
>
> Try setting input-method-verbose-flag to the nil value.

Thanks! input-method-verbose-flag and input-method-highlight-flag are
exactly what I was looking for.

bug#58070: [PATCH] Add tamil99 input method

[Arun Isaac]

> So in the quail-map, you have rules like "h" = க, "d" = உ, "hd" = கு
> which works great until you run into a situation like Eric described
> in emacs-devel here:
> https://yhetil.org/emacs-devel/87a66ori6g.fsf@gmail.com/T/#m5b261c1a7bb06c7c074fdcdb746fb53ab7af1aa1

The problem Eric raises for the Tex IM is much less pronounced for
tamil99. Unlike long key sequences such as [\alpha] in the Tex IM, key
sequences in tamil99 are never more than 2 keys long.

That said, I think there is also a problem with the way out of sequence
vowel insertion is achieved in your implementation. Let me illustrate
with an example. If I entered the key sequence [has], I would get [கஇ],
but if I followed it up with a [<backspace> s], I would get [கி]. In
other words, the key sequences [has] and [has <backspace> s] don't
produce the same result. Likewise, [had] and [has <backspace> d] do not
produce the same result. And, so on. This inconsistency can trip up the
user.

There are many possible key sequences that can compose the same
character, and it is not possible to reliably infer how a character was
composed by only looking at the contents of the buffer. That information
is simply not in the buffer. The ambiguity in this situation is
unresolvable, and it is not possible to fix this in any way.

bug#58070: [PATCH] Add tamil99 input method

[Arun Isaac]

>> Also, while the out-of-sequence vowel insertion is a very clever
>> feature, it shouldn't be required at all if we handled grapheme cluster
>> boundaries correctly. See
>> https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries
>
> Well, we do, that's why cursor motion moves by grapheme clusters,
> right?

That makes sense and must be right. But backspace should also handle
grapheme clusters.

> There's a problem with the above: in some situations you want deletion
> by codepoints, in others you want deletion by grapheme clusters.  (It
> is possible that with Tamil the former is rarely the case, but it is
> definitely a frequent case with other scripts, in particular with
> those that have diacriticals.)  Emacs 29 solves this by having
> delete-forward-char, which is usually bound to the <Delete> key,
> delete by grapheme clusters, while DEL (which deletes backward) and
> C-d delete individual codepoints.  The primary motivation for DEL to
> delete by codepoints is that it allows you to make sub-grapheme
> corrections to stuff you just typed, for example if you typed an
> incorrect accent.
>
> Emacs 29 also has the composition-break-at-point variable, which you
> could set non-nil, in which case <Delete> will also work by
> codepoints.

I see. You're saying that the deletion by grapheme clusters or by
codepoints may be a matter of preference. In that case, it would be nice
to have a variable similar to composition-break-at-point that would
enable deletion by grapheme clusters.

bug#58070: [PATCH] Add tamil99 input method

[Eli Zaretskii]

> From: Arun Isaac <arunisaac@systemreboot.net>
> Cc: visuweshm@gmail.com, 58070@debbugs.gnu.org
> Date: Wed, 28 Sep 2022 01:56:21 +0530
> 
> > There's a problem with the above: in some situations you want deletion
> > by codepoints, in others you want deletion by grapheme clusters.  (It
> > is possible that with Tamil the former is rarely the case, but it is
> > definitely a frequent case with other scripts, in particular with
> > those that have diacriticals.)  Emacs 29 solves this by having
> > delete-forward-char, which is usually bound to the <Delete> key,
> > delete by grapheme clusters, while DEL (which deletes backward) and
> > C-d delete individual codepoints.  The primary motivation for DEL to
> > delete by codepoints is that it allows you to make sub-grapheme
> > corrections to stuff you just typed, for example if you typed an
> > incorrect accent.
> >
> > Emacs 29 also has the composition-break-at-point variable, which you
> > could set non-nil, in which case <Delete> will also work by
> > codepoints.
> 
> I see. You're saying that the deletion by grapheme clusters or by
> codepoints may be a matter of preference.

Not preference, but the specific use case.

> In that case, it would be nice to have a variable similar to
> composition-break-at-point that would enable deletion by grapheme
> clusters.

We already do have that: <Delete> does that in Emacs 29.

bug#58070: [PATCH 0/1] Add tamil99 input method

[Eli Zaretskii]

> Cc: Arun Isaac <arunisaac@systemreboot.net>
> From: Arun Isaac <arunisaac@systemreboot.net>
> Date: Sun, 25 Sep 2022 15:30:20 +0530
> 
> This patch adds the tamil99 input method to Emacs.

Thanks!

> This is my first contribution to Emacs, and I believe I need to assign
> copyright to the FSF. May we get started with copyright assignment? I
> have assigned copyright for other GNU projects before, but not for
> Emacs.

Yes, I've sent the assignment request form off-list.

bug#58070: [PATCH 0/1] Add tamil99 input method

[Arun Isaac]

> Yes, I've sent the assignment request form off-list.

I've filled the form and sent it to assign@gnu.org. Thanks!

bug#58070: [PATCH 0/1] Add tamil99 input method

[Arun Isaac]

>> Yes, I've sent the assignment request form off-list.
>
> I've filled the form and sent it to assign@gnu.org. Thanks!

My copyright assignment is now complete. May we proceed with applying
this patch?

Thanks!

bug#58070: [PATCH 0/1] Add tamil99 input method

[Eli Zaretskii]

> From: Arun Isaac <arunisaac@systemreboot.net>
> Cc: 58070@debbugs.gnu.org
> Date: Wed, 12 Oct 2022 14:11:40 +0530
> 
> 
> >> Yes, I've sent the assignment request form off-list.
> >
> > I've filled the form and sent it to assign@gnu.org. Thanks!
> 
> My copyright assignment is now complete. May we proceed with applying
> this patch?

Which patch is that?  AFAIR, the discussion wasn't completed, or at
least I didn't hear an agreement that your IM should be installed as
the only one.

In addition, I'd rather we had Tamil input methods in a single file,
so how about adding your input method to indian.el?

bug#58070: [PATCH 0/1] Add tamil99 input method

[Arun Isaac]

> Which patch is that?  AFAIR, the discussion wasn't completed, or at
> least I didn't hear an agreement that your IM should be installed as
> the only one.

In https://issues.guix.gnu.org/58070#25 , I made the case that
Visuwesh's implementation does not have enough information to work
consistently. So, I thought the matter was settled. But sure, let's wait
for Visuwesh to chime in.

> In addition, I'd rather we had Tamil input methods in a single file,
> so how about adding your input method to indian.el?

The indian.el file is likely to get very crowded in the future. But
sure, I'll move tamil99 into indian.el. Patch follows in a separate mail
soon.

bug#58070: [PATCH v2] Add tamil99 input method

[Arun Isaac]

* lisp/leim/quail/indian.el: Require pcase and seq.
("tamil99"): New input method.
* etc/NEWS: Mention new tamil99 input method.
---
 etc/NEWS                  |   3 +
 lisp/leim/quail/indian.el | 161 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 164 insertions(+)

diff --git a/etc/NEWS b/etc/NEWS
index 3d1af8bd6f..bcdc991ea3 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -1279,6 +1279,9 @@ The default input method for the Tamil language environment is now
 change the input method's translation rules, customize the user option
 'tamil-translation-rules'.
 
+---
+*** New tamil99 input method for the Tamil language
+
 \f
 * Changes in Specialized Modes and Packages in Emacs 29.1
 
diff --git a/lisp/leim/quail/indian.el b/lisp/leim/quail/indian.el
index 431d8369c1..30b521e389 100644
--- a/lisp/leim/quail/indian.el
+++ b/lisp/leim/quail/indian.el
@@ -30,6 +30,8 @@
 
 ;;; Code:
 
+(require 'pcase)
+(require 'seq)
 (require 'quail)
 (require 'ind-util)
 
@@ -699,6 +701,165 @@ is."
  "tamil-inscript-digits" "Tamil" "TmlISD"
  "Tamil keyboard Inscript with Tamil digits support.")
 
+;; Tamil99 input method
+;;
+;; Tamil99 is a keyboard layout and input method that is specifically
+;; designed for the Tamil language. Vowels and vowel modifiers are
+;; input with your left hand, and consonants are input with your right
+;; hand. See https://en.wikipedia.org/wiki/Tamil_99
+;;
+;; தமிழ்99 உள்ளீட்டு முறை
+;;
+;; தமிழ்99 தமிழுக்கென்றே உருவாக்கப்பட்ட விசைப்பலகை அமைப்பும் உள்ளீட்டு முறையும்
+;; ஆகும். உயிர்களை இடக்கையுடனும் மெய்களை வலக்கையுடனும் தட்டச்சிடும்படி
+;; அமைக்கப்பட்டது. https://ta.wikipedia.org/wiki/%E0%AE%A4%E0%AE%AE%E0%AE%BF%E0%AE%B4%E0%AF%8D_99
+;; காண்க.
+
+(quail-define-package
+ "tamil99" "Tamil" "தமிழ்99"
+ t "Tamil99 input method"
+ nil t t t t nil nil nil nil nil t)
+
+(defconst tamil99-vowels
+  '(("q" "ஆ")
+    ("w" "ஈ")
+    ("e" "ஊ")
+    ("r" "ஐ")
+    ("t" "ஏ")
+    ("a" "அ")
+    ("s" "இ")
+    ("d" "உ")
+    ("g" "எ")
+    ("z" "ஔ")
+    ("x" "ஓ")
+    ("c" "ஒ"))
+  "Mapping for vowels.")
+
+(defconst tamil99-vowel-modifiers
+  '(("q" "ா")
+    ("w" "ீ")
+    ("e" "ூ")
+    ("r" "ை")
+    ("t" "ே")
+    ("a" "")
+    ("s" "ி")
+    ("d" "ு")
+    ("g" "ெ")
+    ("z" "ௌ")
+    ("x" "ோ")
+    ("c" "ொ")
+    ("f" "்"))
+  "Mapping for vowel modifiers.")
+
+(defconst tamil99-vallinam-consonants
+  '(("h" "க")
+    ("[" "ச")
+    ("o" "ட")
+    ("l" "த")
+    ("j" "ப")
+    ("u" "ற"))
+  "Mapping for vallinam consonants.")
+
+(defconst tamil99-mellinam-consonants
+  '(("b" "ங")
+    ("]" "ஞ")
+    ("p" "ண")
+    (";" "ந")
+    ("k" "ம")
+    ("i" "ன"))
+  "Mapping for mellinam consonants.")
+
+(defconst tamil99-idaiinam-consonants
+  '(("'" "ய")
+    ("m" "ர")
+    ("n" "ல")
+    ("v" "வ")
+    ("/" "ழ")
+    ("y" "ள"))
+  "Mapping for idaiinam consonants.")
+
+(defconst tamil99-grantham-consonants
+  '(("Q" "ஸ")
+    ("W" "ஷ")
+    ("E" "ஜ")
+    ("R" "ஹ"))
+  "Mapping for grantham consonants.")
+
+(defconst tamil99-consonants
+  (append tamil99-vallinam-consonants
+          tamil99-mellinam-consonants
+          tamil99-idaiinam-consonants
+          tamil99-grantham-consonants)
+  "Mapping for all consonants.")
+
+(defconst tamil99-other
+  `(("T" ,(vector "க்ஷ"))
+    ("Y" ,(vector "ஶஂரீ"))
+    ("O" "[")
+    ("P" "]")
+    ("A" "௹")
+    ("S" "௺")
+    ("D" "௸")
+    ("F" "ஃ")
+    ("K" "\"")
+    ("L" ":")
+    (":" ";")
+    ("\"" "'")
+    ("Z" "௳")
+    ("X" "௴")
+    ("C" "௵")
+    ("V" "௶")
+    ("B" "௷")
+    ("M" "/"))
+  "Mapping for miscellaneous characters.")
+
+;; உயிர்
+;; vowel
+(mapc (pcase-lambda (`(,vowel-key ,vowel))
+        (quail-defrule vowel-key vowel))
+      tamil99-vowels)
+
+(mapc (pcase-lambda (`(,consonant-key ,consonant))
+        ;; அகர உயிர்மெய்
+        ;; consonant with agaram (அ)
+        (quail-defrule consonant-key consonant)
+        ;; மெய்யொற்று பின் அகர உயிர்மெய்
+        ;; pulli on double consonant
+        (quail-defrule (concat consonant-key consonant-key)
+                       (vector (concat consonant "்" consonant)))
+        (mapc (pcase-lambda (`(,vowel-key ,vowel-modifier))
+                ;; உயிர்மெய்
+                ;; vowel+consonant
+                (quail-defrule (concat consonant-key vowel-key)
+                               (vector (concat consonant vowel-modifier)))
+                ;; மெய்யொற்று பின் உயிர்மெய்
+                ;; vowel+consonant after double consonant
+                (quail-defrule (concat consonant-key consonant-key vowel-key)
+                               (vector (concat consonant "்" consonant vowel-modifier))))
+              tamil99-vowel-modifiers))
+      tamil99-consonants)
+
+(seq-mapn (pcase-lambda (`(,mellinam-consonant-key ,mellinam-consonant)
+                         `(,vallinam-consonant-key ,vallinam-consonant))
+            ;; மெல்லினம் பின் வல்லினம்
+            ;; vallinam after mellinam
+            (quail-defrule (concat mellinam-consonant-key vallinam-consonant-key)
+                           (vector (concat mellinam-consonant "்" vallinam-consonant)))
+            (mapc (pcase-lambda (`(,vowel-key ,vowel-modifier))
+                    ;; மெல்லின ஒற்றொட்டிய வல்லினம் பின் உயிர்மெய்
+                    ;; vowel+consonant after mellinam-vallinam consonant
+                    (quail-defrule (concat mellinam-consonant-key vallinam-consonant-key vowel-key)
+                                   (vector (concat mellinam-consonant "்" vallinam-consonant vowel-modifier))))
+                  tamil99-vowel-modifiers))
+          tamil99-mellinam-consonants
+          tamil99-vallinam-consonants)
+
+;; பிற வரியுருக்கள்
+;; other characters
+(mapc (pcase-lambda (`(,key ,translation))
+        (quail-defrule key translation))
+      tamil99-other)
+
 ;; Probhat Input Method
 (quail-define-package
  "bengali-probhat" "Bengali" "BngPB" t
-- 
2.37.3

bug#58070: [PATCH 0/1] Add tamil99 input method

[Visuwesh]

[ I'm sending through webmail since msmtp fails to send the message,
apologies for any mishaps.  ]

[சனி அக்டோபர் 15, 2022] Arun Isaac wrote:

>> Which patch is that?  AFAIR, the discussion wasn't completed, or at
>> least I didn't hear an agreement that your IM should be installed as
>> the only one.
>
> In https://issues.guix.gnu.org/58070#25 , I made the case that
> Visuwesh's implementation does not have enough information to work
> consistently. So, I thought the matter was settled. But sure, let's wait
> for Visuwesh to chime in.

I currently don't have enough time to really evaluate the differences
between our layouts however, my layout can lead to really unexpected
results in certain cases and it is not tested well enough.  So I would
prefer for Arun's patch to go in.

One comment: why not use link to the Tamil99 keyboard layout spec [1]
and change "vowel+consonant after mellinam-vallinam consonant" to say
"vowel+consonant after hard-soft consonant" like it says in the spec to
help future maintainers who will read this code?

>> In addition, I'd rather we had Tamil input methods in a single file,
>> so how about adding your input method to indian.el?
>
> The indian.el file is likely to get very crowded in the future. But
> sure, I'll move tamil99 into indian.el. Patch follows in a separate mail
> soon.

I don't think it is too crowded, FWIW.  The input methods are sectioned
off based on the language.

1. http://www.tamilvu.org/ta/tkbd-index-341488 (direct link
   http://www.tamilvu.org/tkbd/Tamil_Unicode_G.O.zip).

bug#58070: [PATCH 0/1] Add tamil99 input method

[Arun Isaac]

> One comment: why not use link to the Tamil99 keyboard layout spec [1]
> and change "vowel+consonant after mellinam-vallinam consonant" to say
> "vowel+consonant after hard-soft consonant" like it says in the spec to
> help future maintainers who will read this code?

Sure, will do. I'll send an updated patch tonight.

bug#58070: [PATCH v3] Add tamil99 input method

[Arun Isaac]

* lisp/leim/quail/indian.el: Require pcase and seq.
("tamil99"): New input method.
* etc/NEWS: Mention new tamil99 input method.
---
 etc/NEWS                  |   3 +
 lisp/leim/quail/indian.el | 161 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 164 insertions(+)

diff --git a/etc/NEWS b/etc/NEWS
index 3d1af8bd6f..bcdc991ea3 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -1279,6 +1279,9 @@ The default input method for the Tamil language environment is now
 change the input method's translation rules, customize the user option
 'tamil-translation-rules'.
 
+---
+*** New tamil99 input method for the Tamil language
+
 \f
 * Changes in Specialized Modes and Packages in Emacs 29.1
 
diff --git a/lisp/leim/quail/indian.el b/lisp/leim/quail/indian.el
index 431d8369c1..84a3c7cd7e 100644
--- a/lisp/leim/quail/indian.el
+++ b/lisp/leim/quail/indian.el
@@ -30,6 +30,8 @@
 
 ;;; Code:
 
+(require 'pcase)
+(require 'seq)
 (require 'quail)
 (require 'ind-util)
 
@@ -699,6 +701,165 @@ is."
  "tamil-inscript-digits" "Tamil" "TmlISD"
  "Tamil keyboard Inscript with Tamil digits support.")
 
+;; Tamil99 input method
+;;
+;; Tamil99 is a keyboard layout and input method that is specifically
+;; designed for the Tamil language. Vowels and vowel modifiers are
+;; input with your left hand, and consonants are input with your right
+;; hand. See https://en.wikipedia.org/wiki/Tamil_99
+;;
+;; தமிழ்99 உள்ளீட்டு முறை
+;;
+;; தமிழ்99 தமிழுக்கென்றே உருவாக்கப்பட்ட விசைப்பலகை அமைப்பும் உள்ளீட்டு முறையும்
+;; ஆகும். உயிர்களை இடக்கையுடனும் மெய்களை வலக்கையுடனும் தட்டச்சிடும்படி
+;; அமைக்கப்பட்டது. https://ta.wikipedia.org/wiki/%E0%AE%A4%E0%AE%AE%E0%AE%BF%E0%AE%B4%E0%AF%8D_99
+;; காண்க.
+
+(quail-define-package
+ "tamil99" "Tamil" "தமிழ்99"
+ t "Tamil99 input method"
+ nil t t t t nil nil nil nil nil t)
+
+(defconst tamil99-vowels
+  '(("q" "ஆ")
+    ("w" "ஈ")
+    ("e" "ஊ")
+    ("r" "ஐ")
+    ("t" "ஏ")
+    ("a" "அ")
+    ("s" "இ")
+    ("d" "உ")
+    ("g" "எ")
+    ("z" "ஔ")
+    ("x" "ஓ")
+    ("c" "ஒ"))
+  "Mapping for vowels.")
+
+(defconst tamil99-vowel-modifiers
+  '(("q" "ா")
+    ("w" "ீ")
+    ("e" "ூ")
+    ("r" "ை")
+    ("t" "ே")
+    ("a" "")
+    ("s" "ி")
+    ("d" "ு")
+    ("g" "ெ")
+    ("z" "ௌ")
+    ("x" "ோ")
+    ("c" "ொ")
+    ("f" "்"))
+  "Mapping for vowel modifiers.")
+
+(defconst tamil99-hard-consonants
+  '(("h" "க")
+    ("[" "ச")
+    ("o" "ட")
+    ("l" "த")
+    ("j" "ப")
+    ("u" "ற"))
+  "Mapping for hard consonants (வல்லினம்).")
+
+(defconst tamil99-soft-consonants
+  '(("b" "ங")
+    ("]" "ஞ")
+    ("p" "ண")
+    (";" "ந")
+    ("k" "ம")
+    ("i" "ன"))
+  "Mapping for soft consonants (மெல்லினம்).")
+
+(defconst tamil99-medium-consonants
+  '(("'" "ய")
+    ("m" "ர")
+    ("n" "ல")
+    ("v" "வ")
+    ("/" "ழ")
+    ("y" "ள"))
+  "Mapping for medium consonants (இடையினம்).")
+
+(defconst tamil99-grantham-consonants
+  '(("Q" "ஸ")
+    ("W" "ஷ")
+    ("E" "ஜ")
+    ("R" "ஹ"))
+  "Mapping for grantham consonants (கிரந்தம்).")
+
+(defconst tamil99-consonants
+  (append tamil99-hard-consonants
+          tamil99-soft-consonants
+          tamil99-medium-consonants
+          tamil99-grantham-consonants)
+  "Mapping for all consonants.")
+
+(defconst tamil99-other
+  `(("T" ,(vector "க்ஷ"))
+    ("Y" ,(vector "ஶஂரீ"))
+    ("O" "[")
+    ("P" "]")
+    ("A" "௹")
+    ("S" "௺")
+    ("D" "௸")
+    ("F" "ஃ")
+    ("K" "\"")
+    ("L" ":")
+    (":" ";")
+    ("\"" "'")
+    ("Z" "௳")
+    ("X" "௴")
+    ("C" "௵")
+    ("V" "௶")
+    ("B" "௷")
+    ("M" "/"))
+  "Mapping for miscellaneous characters.")
+
+;; உயிர்
+;; vowel
+(mapc (pcase-lambda (`(,vowel-key ,vowel))
+        (quail-defrule vowel-key vowel))
+      tamil99-vowels)
+
+(mapc (pcase-lambda (`(,consonant-key ,consonant))
+        ;; அகர உயிர்மெய்
+        ;; consonant symbol (consonant combined with the first vowel அ)
+        (quail-defrule consonant-key consonant)
+        ;; மெய்யொற்று பின் அகர உயிர்மெய்
+        ;; pulli on double consonant
+        (quail-defrule (concat consonant-key consonant-key)
+                       (vector (concat consonant "்" consonant)))
+        (mapc (pcase-lambda (`(,vowel-key ,vowel-modifier))
+                ;; உயிர்மெய்
+                ;; vowelised consonant
+                (quail-defrule (concat consonant-key vowel-key)
+                               (vector (concat consonant vowel-modifier)))
+                ;; மெய்யொற்று பின் பிற உயிர்மெய்
+                ;; vowelised consonant after double consonant
+                (quail-defrule (concat consonant-key consonant-key vowel-key)
+                               (vector (concat consonant "்" consonant vowel-modifier))))
+              tamil99-vowel-modifiers))
+      tamil99-consonants)
+
+(seq-mapn (pcase-lambda (`(,soft-consonant-key ,soft-consonant)
+                         `(,hard-consonant-key ,hard-consonant))
+            ;; மெல்லினம் பின் வல்லினம்
+            ;; hard consonant after soft consonant
+            (quail-defrule (concat soft-consonant-key hard-consonant-key)
+                           (vector (concat soft-consonant "்" hard-consonant)))
+            (mapc (pcase-lambda (`(,vowel-key ,vowel-modifier))
+                    ;; மெல்லின ஒற்றொட்டிய வல்லினம் பின் உயிர்மெய்
+                    ;; vowelised consonant after soft-hard consonant pair
+                    (quail-defrule (concat soft-consonant-key hard-consonant-key vowel-key)
+                                   (vector (concat soft-consonant "்" hard-consonant vowel-modifier))))
+                  tamil99-vowel-modifiers))
+          tamil99-soft-consonants
+          tamil99-hard-consonants)
+
+;; பிற வரியுருக்கள்
+;; other characters
+(mapc (pcase-lambda (`(,key ,translation))
+        (quail-defrule key translation))
+      tamil99-other)
+
 ;; Probhat Input Method
 (quail-define-package
  "bengali-probhat" "Bengali" "BngPB" t
-- 
2.37.3

bug#58070: [PATCH v3] Add tamil99 input method

[Eli Zaretskii]

> From: Arun Isaac <arunisaac@systemreboot.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,
> 	58070@debbugs.gnu.org
> Date: Tue, 18 Oct 2022 23:30:59 +0530
> 
> * lisp/leim/quail/indian.el: Require pcase and seq.
> ("tamil99"): New input method.
> * etc/NEWS: Mention new tamil99 input method.

Thanks, installed.