[PATCH 0/1] Add tamil99 input method

  • Done
  • quality assurance status badge
Details
5 participants
  • Arun Isaac
  • Eli Zaretskii
  • Robert Pluim
  • Stefan Kangas
  • Visuwesh
Owner
unassigned
Submitted by
Arun Isaac
Severity
wishlist
A
A
Arun Isaac wrote on 25 Sep 2022 12:00
(address . bug-gnu-emacs@gnu.org)(name . Arun Isaac)(address . arunisaac@systemreboot.net)
20220925100020.13229-1-arunisaac@systemreboot.net
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
A
A
Arun Isaac wrote on 25 Sep 2022 12:02
[PATCH] Add tamil99 input method
(address . 58070@debbugs.gnu.org)(name . Arun Isaac)(address . arunisaac@systemreboot.net)
20220925100244.13482-1-arunisaac@systemreboot.net
* 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

Toggle diff (222 lines)
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
+
* 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
E
E
Eli Zaretskii wrote on 25 Sep 2022 12:13
Re: bug#58070: [PATCH 0/1] Add tamil99 input method
(name . Arun Isaac)(address . arunisaac@systemreboot.net)(address . 58070@debbugs.gnu.org)
83bkr3n4nk.fsf@gnu.org
Toggle quote (6 lines)
> 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!

Toggle quote (5 lines)
> 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.
A
A
Arun Isaac wrote on 25 Sep 2022 13:16
(name . Eli Zaretskii)(address . eliz@gnu.org)(address . 58070@debbugs.gnu.org)
87sfkfpuuc.fsf@systemreboot.net
Toggle quote (2 lines)
> Yes, I've sent the assignment request form off-list.

I've filled the form and sent it to assign@gnu.org. Thanks!
V
V
Visuwesh wrote on 25 Sep 2022 13:38
Re: bug#58070: [PATCH] Add tamil99 input method
(name . Arun Isaac)(address . arunisaac@systemreboot.net)(address . 58070@debbugs.gnu.org)
87h70vsmyd.fsf@gmail.com
[?????? ?????????? 25, 2022] Arun Isaac wrote:
Toggle quote (46 lines)
> +(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: tamil99.el
E
E
Eli Zaretskii wrote on 25 Sep 2022 15:59
(name . Visuwesh)(address . visuweshm@gmail.com)
8335cfmu5h.fsf@gnu.org
Toggle quote (8 lines)
> 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.
V
V
Visuwesh wrote on 25 Sep 2022 16:14
(name . Eli Zaretskii)(address . eliz@gnu.org)
87leq7r163.fsf@gmail.com
[?????? ?????????? 25, 2022] Eli Zaretskii wrote:

Toggle quote (7 lines)
>> 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. ]
E
E
Eli Zaretskii wrote on 25 Sep 2022 16:23
(name . Visuwesh)(address . visuweshm@gmail.com)
83y1u7leh9.fsf@gnu.org
Toggle quote (16 lines)
> 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?

Toggle quote (3 lines)
> 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?
V
V
Visuwesh wrote on 25 Sep 2022 16:38
(name . Eli Zaretskii)(address . eliz@gnu.org)
87edvzr02i.fsf@gmail.com
[?????? ?????????? 25, 2022] Eli Zaretskii wrote:

Toggle quote (21 lines)
>> 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.

Toggle quote (5 lines)
> 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.

Toggle quote (8 lines)
>> 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.

E
E
Eli Zaretskii wrote on 25 Sep 2022 17:55
(name . Visuwesh)(address . visuweshm@gmail.com)
83v8pbla96.fsf@gnu.org
Toggle quote (14 lines)
> 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.
A
A
Arun Isaac wrote on 26 Sep 2022 22:55
(name . Visuwesh)(address . visuweshm@gmail.com)(address . 58070@debbugs.gnu.org)
87ill9ony7.fsf@systemreboot.net
Hi,

Toggle quote (7 lines)
> 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

Toggle quote (3 lines)
> 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.

Toggle quote (4 lines)
> 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.

Toggle quote (4 lines)
> 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
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
A
A
Arun Isaac wrote on 26 Sep 2022 22:59
(address . 58070@debbugs.gnu.org)
87fsgdonru.fsf@systemreboot.net
Toggle quote (12 lines)
>> > 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.
V
V
Visuwesh wrote on 27 Sep 2022 03:49
(name . Arun Isaac)(address . arunisaac@systemreboot.net)(address . 58070@debbugs.gnu.org)
87ill98u3m.fsf@gmail.com
[???????? ?????????? 27, 2022] Arun Isaac wrote:

Toggle quote (12 lines)
> 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.

Toggle quote (13 lines)
>> 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.

Toggle quote (4 lines)
> 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.

Toggle quote (14 lines)
>> 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!

Toggle quote (4 lines)
> 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...

Toggle quote (12 lines)
>> 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.

Toggle quote (4 lines)
> 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.

Toggle quote (6 lines)
> [...]
> 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.
V
V
Visuwesh wrote on 27 Sep 2022 04:29
(name . Arun Isaac)(address . arunisaac@systemreboot.net)(address . 58070@debbugs.gnu.org)
87wn9psg6k.fsf@gmail.com
[???????? ?????????? 27, 2022] Visuwesh wrote:

Toggle quote (13 lines)
>> 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. ]

Toggle quote (5 lines)
>> [...] 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

Toggle diff (13 lines)
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)) ??)
E
E
Eli Zaretskii wrote on 27 Sep 2022 08:23
(name . Arun Isaac)(address . arunisaac@systemreboot.net)
83sfkdjpyf.fsf@gnu.org
Toggle quote (16 lines)
> 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.

Toggle quote (5 lines)
> 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.

Toggle quote (26 lines)
> 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?
E
E
Eli Zaretskii wrote on 27 Sep 2022 08:25
(name . Arun Isaac)(address . arunisaac@systemreboot.net)
83r0zxjpuu.fsf@gnu.org
Toggle quote (9 lines)
> 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.
E
E
Eli Zaretskii wrote on 27 Sep 2022 08:37
(name . Visuwesh)(address . visuweshm@gmail.com)
83o7v1jpb0.fsf@gnu.org
Toggle quote (16 lines)
> 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.
V
V
Visuwesh wrote on 27 Sep 2022 09:34
(name . Eli Zaretskii)(address . eliz@gnu.org)
87pmfhe0dj.fsf@gmail.com
[???????? ?????????? 27, 2022] Eli Zaretskii wrote:

Toggle quote (11 lines)
>> 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.
V
V
Visuwesh wrote on 27 Sep 2022 09:52
(name . Eli Zaretskii)(address . eliz@gnu.org)
87leq5dzkt.fsf@gmail.com
[???????? ?????????? 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.

Toggle quote (11 lines)
>> 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

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.

Toggle quote (2 lines)
> 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.

Toggle quote (5 lines)
> 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).

Toggle quote (14 lines)
>
>> 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*.
E
E
Eli Zaretskii wrote on 27 Sep 2022 09:53
(name . Visuwesh)(address . visuweshm@gmail.com)
83h70tjls4.fsf@gnu.org
Toggle quote (11 lines)
> 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?

Toggle quote (4 lines)
> 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.
E
E
Eli Zaretskii wrote on 27 Sep 2022 10:03
(name . Visuwesh)(address . visuweshm@gmail.com)
83edvxjlav.fsf@gnu.org
Toggle quote (20 lines)
> 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?

Toggle quote (10 lines)
> > 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.
R
R
Robert Pluim wrote on 27 Sep 2022 11:24
(name . Eli Zaretskii)(address . eliz@gnu.org)
87zgel891f.fsf@gmail.com
Toggle quote (2 lines)
>>>>> 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
--
E
E
Eli Zaretskii wrote on 27 Sep 2022 11:40
(name . Robert Pluim)(address . rpluim@gmail.com)
838rm5jgt2.fsf@gnu.org
Toggle quote (14 lines)
> 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.

Toggle quote (7 lines)
> 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.
V
V
Visuwesh wrote on 27 Sep 2022 12:11
(name . Eli Zaretskii)(address . eliz@gnu.org)
87h70tdt4a.fsf@gmail.com
[???????? ?????????? 27, 2022] Eli Zaretskii wrote:

Toggle quote (18 lines)
>> 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.

Toggle quote (4 lines)
> 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.

Toggle quote (3 lines)
> 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.

Toggle quote (8 lines)
>> 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.
V
V
Visuwesh wrote on 27 Sep 2022 12:15
(name . Eli Zaretskii)(address . eliz@gnu.org)
87czbhdsxf.fsf@gmail.com
[???????? ?????????? 27, 2022] Eli Zaretskii wrote:

Toggle quote (21 lines)
>> 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.

Toggle quote (12 lines)
>> > 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.
A
A
Arun Isaac wrote on 27 Sep 2022 22:19
(address . 58070@debbugs.gnu.org)
874jwso9iy.fsf@systemreboot.net
Toggle quote (5 lines)
> 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.
A
A
Arun Isaac wrote on 27 Sep 2022 22:26
(name . Eli Zaretskii)(address . eliz@gnu.org)
871qrwo976.fsf@systemreboot.net
Toggle quote (8 lines)
>> 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.

Toggle quote (16 lines)
> 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.
A
A
Arun Isaac wrote on 27 Sep 2022 22:32
(name . Visuwesh)(address . visuweshm@gmail.com)(address . 58070@debbugs.gnu.org)
87wn9omud5.fsf@systemreboot.net
Toggle quote (7 lines)
> 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.
A
A
Arun Isaac wrote on 27 Sep 2022 22:34
(name . Eli Zaretskii)(address . eliz@gnu.org)
87tu4smu90.fsf@systemreboot.net
Toggle quote (7 lines)
>> 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.
E
E
Eli Zaretskii wrote on 28 Sep 2022 04:30
(name . Arun Isaac)(address . arunisaac@systemreboot.net)
83sfkci62e.fsf@gnu.org
Toggle quote (23 lines)
> 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.

Toggle quote (4 lines)
> 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.
A
A
Arun Isaac wrote on 12 Oct 2022 10:40
(address . 58070@debbugs.gnu.org)
87sfjte8pn.fsf@systemreboot.net
Toggle quote (4 lines)
> 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
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?
A
A
Arun Isaac wrote on 12 Oct 2022 10:41
Re: bug#58070: [PATCH 0/1] Add tamil99 input method
(name . Eli Zaretskii)(address . eliz@gnu.org)(address . 58070@debbugs.gnu.org)
87pmexe8mz.fsf@systemreboot.net
Toggle quote (4 lines)
>> 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!
E
E
Eli Zaretskii wrote on 12 Oct 2022 15:55
(name . Arun Isaac)(address . arunisaac@systemreboot.net)(address . 58070@debbugs.gnu.org)
831qrdcfk6.fsf@gnu.org
Toggle quote (12 lines)
> 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?
E
E
Eli Zaretskii wrote on 12 Oct 2022 16:00
Re: bug#58070: [PATCH] Add tamil99 input method
(name . Arun Isaac)(address . arunisaac@systemreboot.net)
83zge1b0qr.fsf@gnu.org
Toggle quote (16 lines)
> 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.

Toggle quote (3 lines)
> 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.
S
S
Stefan Kangas wrote on 13 Oct 2022 15:47
control message for bug #58070
(address . control@debbugs.gnu.org)
CADwFkm=gY+nRrE_wGnZqn6j8VqYvnwvodDYazLxQTUG6Ym+wbA@mail.gmail.com
severity 58070 wishlist
quit
A
A
Arun Isaac wrote on 15 Oct 2022 10:23
Re: bug#58070: [PATCH] Add tamil99 input method
(name . Eli Zaretskii)(address . eliz@gnu.org)
874jw58phd.fsf@systemreboot.net
Toggle quote (5 lines)
>> 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.
A
A
Arun Isaac wrote on 15 Oct 2022 10:34
Re: bug#58070: [PATCH 0/1] Add tamil99 input method
(name . Eli Zaretskii)(address . eliz@gnu.org)
871qr98oyy.fsf@systemreboot.net
Toggle quote (4 lines)
> 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.

Toggle quote (3 lines)
> 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.
A
A
Arun Isaac wrote on 15 Oct 2022 11:16
[PATCH v2] Add tamil99 input method
20221015091610.1941-1-arunisaac@systemreboot.net
* 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(+)

Toggle diff (195 lines)
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
+
* 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
V
V
Visuwesh wrote on 15 Oct 2022 16:42
Re: bug#58070: [PATCH 0/1] Add tamil99 input method
(name . Arun Isaac)(address . arunisaac@systemreboot.net)
CAN2Jav4PXZJ0cT84MJV7McoNqGtaXn5MnbDJbZ0jCB33v6GOMQ@mail.gmail.com
[ I'm sending through webmail since msmtp fails to send the message,
apologies for any mishaps. ]

[??? ???????? 15, 2022] Arun Isaac wrote:

Toggle quote (9 lines)
>> 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?

Toggle quote (7 lines)
>> 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.

A
A
Arun Isaac wrote on 18 Oct 2022 09:11
(name . Visuwesh)(address . visuweshm@gmail.com)
87h701ip1x.fsf@systemreboot.net
Toggle quote (5 lines)
> 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.
A
A
Arun Isaac wrote on 18 Oct 2022 20:00
[PATCH v3] Add tamil99 input method
20221018180059.22329-1-arunisaac@systemreboot.net
* 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(+)

Toggle diff (195 lines)
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
+
* 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
E
E
Eli Zaretskii wrote on 19 Oct 2022 13:41
(name . Arun Isaac)(address . arunisaac@systemreboot.net)
83fsfkyra1.fsf@gnu.org
Toggle quote (9 lines)
> 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.
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 58070@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 58070
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch