From: Visuwesh <visuweshm@gmail.com>
To: Arun Isaac <arunisaac@systemreboot.net>
Cc: 58070@debbugs.gnu.org
Subject: bug#58070: [PATCH] Add tamil99 input method
Date: Tue, 27 Sep 2022 07:19:17 +0530 [thread overview]
Message-ID: <87ill98u3m.fsf@gmail.com> (raw)
In-Reply-To: <87ill9ony7.fsf@systemreboot.net> (Arun Isaac's message of "Tue, 27 Sep 2022 02:25:28 +0530")
[செவ்வாய் செப்டம்பர் 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.
next prev parent reply other threads:[~2022-09-27 1:49 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-25 10:00 bug#58070: [PATCH 0/1] Add tamil99 input method Arun Isaac
2022-09-25 10:02 ` bug#58070: [PATCH] " Arun Isaac
2022-09-25 11:38 ` Visuwesh
2022-09-25 13:59 ` Eli Zaretskii
2022-09-25 14:14 ` Visuwesh
2022-09-25 14:23 ` Eli Zaretskii
2022-09-25 14:38 ` Visuwesh
2022-09-25 15:55 ` Eli Zaretskii
2022-09-26 20:59 ` Arun Isaac
2022-09-27 6:25 ` Eli Zaretskii
2022-09-27 20:34 ` Arun Isaac
2022-09-26 20:55 ` Arun Isaac
2022-09-27 1:49 ` Visuwesh [this message]
2022-09-27 2:29 ` Visuwesh
2022-09-27 6:37 ` Eli Zaretskii
2022-09-27 7:34 ` Visuwesh
2022-09-27 7:53 ` Eli Zaretskii
2022-09-27 9:24 ` Robert Pluim
2022-09-27 9:40 ` Eli Zaretskii
2022-09-27 10:11 ` Visuwesh
2022-09-27 20:32 ` Arun Isaac
2022-09-27 6:23 ` Eli Zaretskii
2022-09-27 7:52 ` Visuwesh
2022-09-27 8:03 ` Eli Zaretskii
2022-09-27 10:15 ` Visuwesh
2022-10-12 8:40 ` Arun Isaac
2022-10-12 14:00 ` Eli Zaretskii
2022-10-15 8:23 ` Arun Isaac
2022-09-27 20:19 ` Arun Isaac
2022-09-27 20:26 ` Arun Isaac
2022-09-28 2:30 ` Eli Zaretskii
2022-09-25 10:13 ` bug#58070: [PATCH 0/1] " Eli Zaretskii
2022-09-25 11:16 ` Arun Isaac
2022-10-12 8:41 ` Arun Isaac
2022-10-12 13:55 ` Eli Zaretskii
2022-10-15 8:34 ` Arun Isaac
2022-10-15 9:16 ` bug#58070: [PATCH v2] " Arun Isaac
2022-10-15 14:42 ` bug#58070: [PATCH 0/1] " Visuwesh
2022-10-18 7:11 ` Arun Isaac
2022-10-18 18:00 ` bug#58070: [PATCH v3] " Arun Isaac
2022-10-19 11:41 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ill98u3m.fsf@gmail.com \
--to=visuweshm@gmail.com \
--cc=58070@debbugs.gnu.org \
--cc=arunisaac@systemreboot.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).