unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Visuwesh <visuweshm@gmail.com>
Cc: 50143@debbugs.gnu.org, rameshnedunchezian@outlook.com
Subject: bug#50143: 28.0.50; Various issues with `tamil-itrans' input method
Date: Thu, 17 Feb 2022 19:30:40 +0200	[thread overview]
Message-ID: <83czjl1jun.fsf@gnu.org> (raw)
In-Reply-To: <87y229pxwt.fsf@gmail.com> (message from Visuwesh on Thu, 17 Feb 2022 16:23:06 +0530)

> From: Visuwesh <visuweshm@gmail.com>
> Cc: rameshnedunchezian@outlook.com,  50143@debbugs.gnu.org
> Date: Thu, 17 Feb 2022 16:23:06 +0530
> 
> >  1. For your items 1 and 3, just copy indian-tml-base-table to a new
> >     variable, modify it to include the two missing characters and
> >     replace the digits with nil, add a new variable similar to
> >     indian-tml-itrans-v5-hash, and compute its value like we do with
> >     indian-tml-itrans-v5-hash, but using the new table instead of
> >     indian-tml-base-table.  Then make a new input method, called, say,
> >     tamil-itrans-alt, which would use the new hash variable instead of
> >     indian-tml-itrans-v5-hash.  Submit these changes as patches to
> >     lisp/language/ind-util.el and lisp/leim/quail/indian.el.
> >
> 
> Does the attached patch look okay to you?

Yes, thanks.

> The names of the new input methods are bad.  IMO, tamil-itrans and
> tamil-inscript should ideally be renamed to tamil-itrans-digits and
> tamil-inscript-digits, and the new input methods should be tamil-itrans
> and tamil-inscript.  But I guess such a backwards incompatible change
> won't fly?

No, I think you can do the renaming.  The change is already
incompatible, because we will be changing the default input method, so
it will need a NEWS entry to tell how to get back old behavior, and in
that NEWS entry we can also tell users to switch to another input
method.

> >  2. For your item 2, submit a patch that fixes the docstring of the
> >     relevant input methods.
> 
> About item 2: according to the docstring of `quail-define-package',
> constructs of the form "\<VAR>" should be replaced by the VAR:
> 
>     DOCSTRING is the documentation string of this package.  The command
>     ‘describe-input-method’ shows this string while replacing the form
>     \<VAR> in the string by the value of VAR.  That value should be a
>     string.  For instance, the form \<quail-translation-docstring> is
>     replaced by a description about how to select a translation from a
>     list of candidates.
> 
> but this is not the case, I checked the code but don't see a
> substitution like this happen.  Maybe this should be fixed in
> `describe-input-method' instead?

If you can find the problem and fix i there, fine.  But fixing only a
small number of input methods with patches specific to those methods
is also fine.

Btw, the patch is already close to the limit of what we can accept
without copyright assignment, so would you like to start your legal
paperwork rolling at this time, so that we could in the future accept
more contributions from you?  If yes, I will send you the form to fill
and the instructions to go with that.

Thanks.





  reply	other threads:[~2022-02-17 17:30 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-21  9:25 bug#50143: 28.0.50; Various issues with `tamil-itrans' input method Ramesh Nedunchezian
2021-08-22  7:28 ` Eli Zaretskii
2022-02-15 12:01   ` Visuwesh
2022-02-16 17:36     ` Eli Zaretskii
2022-02-17  2:14       ` Visuwesh
2022-02-17  6:33         ` Eli Zaretskii
2022-02-17 10:53       ` Visuwesh
2022-02-17 17:30         ` Eli Zaretskii [this message]
2022-02-18  1:01           ` Visuwesh
2022-02-18  7:58             ` Eli Zaretskii
2022-03-13  5:51           ` Visuwesh
2022-03-13  5:59             ` Visuwesh
2022-03-13  6:35               ` Eli Zaretskii
2022-03-13  7:16                 ` Visuwesh
2022-03-13  8:23                   ` Eli Zaretskii
2022-03-13  9:01                     ` Visuwesh
2022-03-13  9: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=83czjl1jun.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=50143@debbugs.gnu.org \
    --cc=rameshnedunchezian@outlook.com \
    --cc=visuweshm@gmail.com \
    /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).