From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Visuwesh Newsgroups: gmane.emacs.bugs Subject: bug#58070: [PATCH] Add tamil99 input method Date: Tue, 27 Sep 2022 07:19:17 +0530 Message-ID: <87ill98u3m.fsf@gmail.com> References: <20220925100020.13229-1-arunisaac@systemreboot.net> <20220925100244.13482-1-arunisaac@systemreboot.net> <87h70vsmyd.fsf@gmail.com> <87ill9ony7.fsf@systemreboot.net> 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="18666"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: 58070@debbugs.gnu.org To: Arun Isaac Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Sep 27 03:52:12 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 1oczlc-0004cn-64 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 27 Sep 2022 03:52:12 +0200 Original-Received: from localhost ([::1]:43638 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oczlb-000894-64 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 26 Sep 2022 21:52:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39914) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oczlS-00088D-Pi for bug-gnu-emacs@gnu.org; Mon, 26 Sep 2022 21:52:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52993) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oczlS-0006xx-GX for bug-gnu-emacs@gnu.org; Mon, 26 Sep 2022 21:52:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oczlS-0000A0-C8 for bug-gnu-emacs@gnu.org; Mon, 26 Sep 2022 21:52:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Visuwesh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 27 Sep 2022 01:52: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.1664243475544 (code B ref 58070); Tue, 27 Sep 2022 01:52:02 +0000 Original-Received: (at 58070) by debbugs.gnu.org; 27 Sep 2022 01:51:15 +0000 Original-Received: from localhost ([127.0.0.1]:52065 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oczkh-00008h-C7 for submit@debbugs.gnu.org; Mon, 26 Sep 2022 21:51:15 -0400 Original-Received: from mail-pj1-f65.google.com ([209.85.216.65]:40640) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oczkc-00008R-Gr for 58070@debbugs.gnu.org; Mon, 26 Sep 2022 21:51:13 -0400 Original-Received: by mail-pj1-f65.google.com with SMTP id h8-20020a17090a054800b00205ccbae31eso1676205pjf.5 for <58070@debbugs.gnu.org>; Mon, 26 Sep 2022 18:51:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:references :message-id:date:in-reply-to:subject:cc:to:from:from:to:cc:subject :date; bh=sVP3J4TKjt6QDz3e6vxMjFzYZ/3Gi/JDZIMDy7BqJ4w=; b=eIxHV2vXJSexHfMeEUzeymtfJJEfJEdICfB1yqSJ0X8KFVMZtsBY8CNAjC1FKVPQAF sl14NXkD6HpZ5t9K7H454opHvMy/J4LLEKDwPDjGvtZDFU3slyX7zNoznx79sv8jdNMW ZAELylyMDzV8foVQePdYSw047EvslFekagPEMCPCgX6HxnZUjqJJTxXRvQmIRQ03+M4n cKM3RrSHIaiTsFhsqH4NrXU/zdL/eQlabs6mRaKa22apwAWArY/Lqm2CJN3R0tuzmbZN gJY50f3PuSk/t8tCa/0UOokI4ALz75r59ybG0bf4suoShIlraFsA+2+MEYYMSwkvq/6+ wBPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:references :message-id:date:in-reply-to:subject:cc:to:from:x-gm-message-state :from:to:cc:subject:date; bh=sVP3J4TKjt6QDz3e6vxMjFzYZ/3Gi/JDZIMDy7BqJ4w=; b=xW33F7MRu/WKtpnWbQwIdZHj1WisGx7nkYZJADj+oXnYwZUiS6948xfWLRDTBegLaD wzn0LYaLpKB8QnrOvJVQUqI4Lz2HgUYftY12ovhQWEks/dhD9wJuHX71/XyxvbcexmSE NtOWRXXpI3HlAjB9NViyvTpZKbUucM2+itiiUPhsHMmniHn7sl3qSZPskFzYNbKZeQRD yMjQmAHuZxsncBTy+f3iS51NBZOUCIwtusJv0ymwAWJ0FyqctKIHo5GHFsesQjpThjGW R6oKtIV7EtYJ3NdSaF+valwKrhSZhS+OdpO98JrPxE7kiZjuLTo0dnF53x+gDG50tihm R7fw== X-Gm-Message-State: ACrzQf20moglug6t9dgS1eE9OqglX2IFTU70An5Dk2VYZPhQTwf9bKM+ WVjCITl13i2z61QnhnlXIfk= X-Google-Smtp-Source: AMsMyM4sDNNMZgLWFsrHBs/W05ovbNwnOOUTaAXNrsIBMOvB/1w7nIXFVEfP3kgTTFaa6fIEfxRJkA== X-Received: by 2002:a17:90b:1c07:b0:202:ff6e:6015 with SMTP id oc7-20020a17090b1c0700b00202ff6e6015mr1802862pjb.210.1664243463481; Mon, 26 Sep 2022 18:51:03 -0700 (PDT) Original-Received: from localhost ([115.240.90.130]) by smtp.gmail.com with ESMTPSA id c198-20020a621ccf000000b0052d4cb47339sm180606pfc.151.2022.09.26.18.51.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Sep 2022 18:51:02 -0700 (PDT) In-Reply-To: <87ill9ony7.fsf@systemreboot.net> (Arun Isaac's message of "Tue, 27 Sep 2022 02:25:28 +0530") 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:243685 Archived-At: [=E0=AE=9A=E0=AF=86=E0=AE=B5=E0=AF=8D=E0=AE=B5=E0=AE=BE=E0=AE=AF=E0=AF=8D = =E0=AE=9A=E0=AF=86=E0=AE=AA=E0=AF=8D=E0=AE=9F=E0=AE=AE=E0=AF=8D=E0=AE=AA=E0= =AE=B0=E0=AF=8D 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! ;-)=20 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. =20 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 =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. 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.=20 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.