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#56323: 29.0.50; [v2] Add new customisable phonetic Tamil input method Date: Sat, 02 Jul 2022 13:28:29 +0530 Message-ID: <87czeoj68q.fsf@gmail.com> References: <87pmiqe4da.fsf@gmail.com> <878rpdq99n.fsf@gmail.com> <83fsjldl2b.fsf@gnu.org> <87tu81osgp.fsf@gmail.com> <83czepdj0z.fsf@gnu.org> <87pmioq51w.fsf@gmail.com> <831qv4erwf.fsf@gnu.org> <87r134aiwd.fsf@gmail.com> <83mtdsc86u.fsf@gnu.org> 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="24200"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: 56323@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jul 02 09:59:30 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 1o7Y2M-0006A2-8k for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 02 Jul 2022 09:59:30 +0200 Original-Received: from localhost ([::1]:59454 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o7Y2J-0008Dl-Kc for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 02 Jul 2022 03:59:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49104) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o7Y1u-0008Dd-ET for bug-gnu-emacs@gnu.org; Sat, 02 Jul 2022 03:59:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45783) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o7Y1t-0008Mg-TI for bug-gnu-emacs@gnu.org; Sat, 02 Jul 2022 03:59:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1o7Y1t-0007yC-OB for bug-gnu-emacs@gnu.org; Sat, 02 Jul 2022 03:59:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Visuwesh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 Jul 2022 07:59:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56323 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 56323-submit@debbugs.gnu.org id=B56323.165674872030606 (code B ref 56323); Sat, 02 Jul 2022 07:59:01 +0000 Original-Received: (at 56323) by debbugs.gnu.org; 2 Jul 2022 07:58:40 +0000 Original-Received: from localhost ([127.0.0.1]:39680 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o7Y1Y-0007xa-7L for submit@debbugs.gnu.org; Sat, 02 Jul 2022 03:58:40 -0400 Original-Received: from mail-pl1-f193.google.com ([209.85.214.193]:41492) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o7Y1W-0007xL-3x for 56323@debbugs.gnu.org; Sat, 02 Jul 2022 03:58:39 -0400 Original-Received: by mail-pl1-f193.google.com with SMTP id c4so4319431plc.8 for <56323@debbugs.gnu.org>; Sat, 02 Jul 2022 00:58:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=+K8/43yf+mu+7kkxB0hgYZ2ZsLDZp51h0MCx6clanUE=; b=ciAckZ7u05ujUGpjk6T0w0eiUoI0dAN5VjCsbE6Ie3RXw8WZsatpPHzDfO1+YKjAmw Ijyw3kaoAiWY8ScyhTX88ysj7WPvKvLzPzIZB2syoM1AfVZP/6ZhxyCsKcZBYLcrxqYV ksmXQNJSMzPZmVVMZek4r4t1X+A5uQ6qkxvdronT4eX/jroFXujrArHoodBoqYqfmStS f1Wsh/U/j8AyP2Q6H6DFP1xhaOZaGIRQemx/AVKoDQT8m9w9vmFF3n8BWwXgiSdkeON4 kWzx46Q7yPz1WugsQ9txVb1okiYMh8n139PmANimBwmUyoOgfRQMGLETkTTDfpl89gXS 1cJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=+K8/43yf+mu+7kkxB0hgYZ2ZsLDZp51h0MCx6clanUE=; b=5l3QczUrncrf5cdsRhJ2o1qc7hNZP35prkScIlI/6AkcY86jGzgEdy3A78MCQtDRbw Iw7CzX/seBkpmiRiZspQjYWqEf0OVGAryJlBpJPcXyvGYYdal7iM0kWz+GuDa1cKluwI Voh+aZ7UrQUTrPcCXVfXXfpElHKsDDjlI3YnS5DFFxyMmfmkhAhGNv3kDgpQL9TfpxOc CfyaVbUYEvaKhfuEzDdbY4fhRpHvxKR77xiEdnCSCbtM0VbwnRd3v5UuVNpTqXym1avJ 5FJudG5sir++OVRW98U4oPgIUBgqWOkWw1aorr60BnPA+NraXuxs6/OvmQq1/QRvJfz7 XXNg== X-Gm-Message-State: AJIora/wLLyIxcBWrj0lJRgDPu20nUP/8XtM0EgHw9/G+13ZAYnFtqNP /P87deS5Z0N3klsbczdFIo8= X-Google-Smtp-Source: AGRyM1ueF2zG7uA7GidO+nkPMrKiC7Zzt2dp7zeiqN2SJ0+uq0SxeVHXCxPKXQLRgXj9BkdDJiwNsg== X-Received: by 2002:a17:90a:ff0d:b0:1ec:902b:e46e with SMTP id ce13-20020a17090aff0d00b001ec902be46emr23276306pjb.167.1656748712244; Sat, 02 Jul 2022 00:58:32 -0700 (PDT) Original-Received: from localhost ([49.204.136.62]) by smtp.gmail.com with ESMTPSA id g19-20020a62e313000000b0051ba8b742e4sm16932825pfh.69.2022.07.02.00.58.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 02 Jul 2022 00:58:31 -0700 (PDT) In-Reply-To: <83mtdsc86u.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 02 Jul 2022 09:58:17 +0300") 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:235858 Archived-At: [=E0=AE=9A=E0=AE=A9=E0=AE=BF =E0=AE=9C=E0=AF=82=E0=AE=B2=E0=AF=88 02, 2022]= Eli Zaretskii wrote: >> From: Visuwesh >> Cc: 56323@debbugs.gnu.org >> Date: Fri, 01 Jul 2022 22:07:38 +0530 >>=20 >> >> BTW, do you have any other code/documentation review? And what about >> >> the patch I posted in https://lists.gnu.org/archive/html/bug-gnu-emac= s/2022-06/msg02256.html? >> >> No rush but I would like to know if it can go in since it only addres= ses >> >> fallouts from the previous bug in this area. Thanks. >> > >> > It sounded to me like you are still working on the code, so I didn't >> > see a need to review it. If you have specific parts that you'd like >> > me to review nonetheless, please tell which parts are those. >>=20 >> Thanks. The patch I posted in >> https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-06/msg02256.html >> is done, and can be pushed to master if you see no problems. > > I installed it, thanks. > Thanks. >> Also, I would like to know if there's a better to write the :set >> function for the defcustoms tamil-vowel-translation, >> tamil-consonant-translation, tamil-misc-translation, tamil-native-digits >> without the boundp check chain below, >>=20 >> (defun tamil--set-variable (sym val) >> (set-default sym val) >> (when (and (boundp 'tamil-vowel-translation) >> (boundp 'tamil-consonant-translation) >> (boundp 'tamil-misc-translation) >> (boundp 'tamil-native-digits)) >> (tamil--update-quail-rules))) > > Why do you need a single function for all of them? Would a separate > setter function for each defcustom do the job? > Because it is harder to clear the old translation rules and add the new translation rules than clearing ALL translation rules and starting over again. When the user changes tamil-vowel-translation, then not only does the translation rule for the vowels change, we also need to change the translation rules for consonant+vowel pairs so that means we need to check if the consonant var is bound. (The translation rules for consonant+vowel pairs are auto-generated based on the rules for vowels and consonants.) Similarly, when the consonant defcustom changes, we need to change both the consonant and the consonant+vowel pair translation rules. Moreover, if the user decides to delete an extra consonant translation, then we need to smartly detect that and delete it from the current quail map. Instead of all this, a simple clear ALL+start over approach is much simpler. And since this approach doesn't take too much time, I don't think implementing the smarter approach would be worth it. Besides, even if this smart approach is easy to implement, quail-map structure is just too hard to manipulate by hand... > I also don't understand the need for the boundp tests -- the function > will live on the same indian.el file as the defcustoms, so if the > function is defined, the defcustoms are also bound, no? > IIUC, when we load indian.el, first, the vowel defcustom will be bound, then the consonant defcustom and so on. So this boundp test is needed, I think? See above for why the defcustoms have a "dependency" on each other. When the vowel defcustom is loaded, then its job _sometimes_ depends on the consonant defcustom being bound as well. I say sometimes because when we initially load the vowel defcustom, having a separate setter should be fine but when we change it after loading _all_ the other defcustoms (example in the Customize interface), we also need to access the consonant translation values and update the translation rules for consonant+vowel pairs. A big fat setter function that does everything at the cost of boundp checks is simpler AFAIU. >> I'm also doubtful about the current group being used for these >> defcustoms. Should I go ahead and make a new 'tamil' group and make it >> a subgroup of leim or i18n? > > It's okay to have a separate group, but what would be the subject of > this group? If it's just about input methods, the name had better > reflected that, and just "tamil" is too general for that. > I thought the subject could be "Translation rules for the Tamil input method." If you think the group name is too general, then "tamil-im" could work? >> And is the prefix tamil- okay or should I change it to something >> else? > > I see no problem with 'tamil-'. > Okay, thanks. >> Finally, I'm unsure if "List of input sequences to translate to ..." is >> clear. I think it sounds a mouthful and there should be a better way to >> put it. I think "translation rules" is quite nice but I'm afraid that >> it is too Quail specific and might not be well understood. > > I have no problem with that wording, but I wonder whether we should > have these defcustoms in the first place. What are the chances that > some user will want to change the sequences, and why would they want > that? I think the chances are quite high. As I tried to explain in the first mail, there are too many ambiguities when transliterating Tamil and sometimes there is no perfect transliteration for a character/consonant family. For example, the user in the wordpress article I linked chooses to translate =E0=AE=B2=E0=AF=8D as 'l' =E0=AE=B3=E0=AF=8D as 'll' and take the= penalty of having to type C-SPC at the right time: to write =E0=AE=B2=E0=AF=8D=E0=AE=B2 the sequence = would l C-SPC la since lla would translate to =E0=AE=B3. That user can take this penalty but I would rather translate =E0=AE=B3=E0= =AF=8D as L instead and not worry about C-SPC at all.=20=20 Bottom line, there is no one size fits all. These small annoyances can be dealt with when one writes Tamil rarely but for frequent writing, the flexibility this input method offers will be welcome IMO. The users _can_ update the quail-map themselves by hand but that becomes tricky and a REAL chore for a language like Tamil. [ FWIW, I add new translations and modify existing translations for the compose input method by setf-ing its quail map. That is hard enough already, and I definitely wouldn't wish someone to do it for the Tamil input method. Offering a defcustom is the least we can do to ease the pain of tweaking the translation rules. ] > P.S. Please in the future don't modify the Subject of the messages in > the same bug report: that makes it harder to find related messages at > least when using Rmail. Oops, sorry about that. I thought it would be easier to track the progress but I guess it misfired.