From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Arun Isaac Newsgroups: gmane.emacs.bugs Subject: bug#58070: [PATCH] Add tamil99 input method Date: Tue, 27 Sep 2022 02:25:28 +0530 Message-ID: <87ill9ony7.fsf@systemreboot.net> References: <20220925100020.13229-1-arunisaac@systemreboot.net> <20220925100244.13482-1-arunisaac@systemreboot.net> <87h70vsmyd.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40081"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 58070@debbugs.gnu.org To: Visuwesh Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Sep 26 22:56:21 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ocv9I-000ACt-E5 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 26 Sep 2022 22:56:21 +0200 Original-Received: from localhost ([::1]:38046 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ocv9H-0002wr-FX for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 26 Sep 2022 16:56:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46418) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocv90-0002wi-PP for bug-gnu-emacs@gnu.org; Mon, 26 Sep 2022 16:56:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52819) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ocv90-0007K9-8n for bug-gnu-emacs@gnu.org; Mon, 26 Sep 2022 16:56:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ocv90-0007WV-1H for bug-gnu-emacs@gnu.org; Mon, 26 Sep 2022 16:56:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Arun Isaac Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 26 Sep 2022 20:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58070 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 58070-submit@debbugs.gnu.org id=B58070.166422574228890 (code B ref 58070); Mon, 26 Sep 2022 20:56:02 +0000 Original-Received: (at 58070) by debbugs.gnu.org; 26 Sep 2022 20:55:42 +0000 Original-Received: from localhost ([127.0.0.1]:51897 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ocv8g-0007Vu-9A for submit@debbugs.gnu.org; Mon, 26 Sep 2022 16:55:42 -0400 Original-Received: from mugam.systemreboot.net ([139.59.75.54]:47146) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ocv8b-0007Vh-Hc for 58070@debbugs.gnu.org; Mon, 26 Sep 2022 16:55:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=systemreboot.net; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=TgncSpRpvRC9xhznl76nXPefP4HSxrQggN5QO7nm+dI=; b=FrjO7Vigo/Qo0voCL5SU8U4ex8 tHheqwv4seabi+3cMTDyZz4VZJFrKi4JIaqsHoqk2qBLlYFkgSeP0YOTlQRDWQ/Hpc7u2hgxkZIUO gsVH85SnfQmTDbQXhUjvvp30l5hdofM84NC6m6nIGxX0YQrTjUwQ0SwvR/3zSRVI1gl6hMe0mej0+ kaMtAaanXu0V9yc8T8qR8K84FI5bQHQY4e+LFpPtC/vGY6c1XulmKRrzhCIF5Q8TJiDROe0iTwaCt t+RslxH8iAVKnVOSfZJlVGJlrEexV7ifjVslNYJUks8ZVDkhWvlvgNFcI/tT0k2HrX0pG3DBx6QM7 rzQeBLVw==; Original-Received: from [192.168.2.1] (port=52944 helo=steel) by systemreboot.net with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1ocv8W-000bPQ-2j; Tue, 27 Sep 2022 02:25:32 +0530 In-Reply-To: <87h70vsmyd.fsf@gmail.com> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:243677 Archived-At: 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 =E0=AE=95=E0=AE=BF (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=CC=80| 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 =E0=AE=95=E0=AE=BF| and press backspace, I get: =E0=AE=95| But, I want the whole "user-perceived character" (=E0=AE=95=E0=AE=BF) delet= ed 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