itrans input methods and motion keys

itrans input methods and motion keys

[Visuwesh]

Dear all,

I'm posting this in emacs-devel instead of filing a bug report since I
want this to get a bit more attraction.  I'm also CCing Sameer Singh in
hopes that he can give insight into the non-Tamil side of things.

Currently, the itrans input methods are defined using the function
quail-define-indian-trans-package in lisp/leim/quail/indian.el.  This
function calls quail-define-package with a nil SIMPLE argument which
steals the commonly used motion keys C-f, C-b, C-n, C-p.  AFAICT from
what I read in quail a year or so ago, this argument is more useful for
the Chinese and the Japanese input methods but not so much for simple
IMs like the itrans one which only does transliteration.  Besides, even
if an IM has one to many translation i.e., if "a" can be translated to
"a->" and "a->>", and the SIMPLE argument is non-nil, one can use the
number keys to select the alternate translation.

Since the nil value of SIMPLE argument gives no real benefit in the case
of tamil-itrans IM, I would like to change it to t so that we can get
the motion keys back.  However, I have only ever used the Tamil IM and
thus have no idea about the other languages.  Then we can adjust the
quail-define-indian-trans-package function to pass a custom SIMPLE
argument instead.

Re: itrans input methods and motion keys

[समीर सिंह Sameer Singh]

[-- Attachment #1: Type: text/plain, Size: 1565 bytes --]

I am sorry I do not use the itrans input methods, therefore do not know
much about it :(
So may I know why are motion keys disabled while typing in these input
methods?

Thanks.

On Tue, Jun 28, 2022 at 4:06 PM Visuwesh <visuweshm@gmail.com> wrote:

> Dear all,
>
> I'm posting this in emacs-devel instead of filing a bug report since I
> want this to get a bit more attraction.  I'm also CCing Sameer Singh in
> hopes that he can give insight into the non-Tamil side of things.
>
> Currently, the itrans input methods are defined using the function
> quail-define-indian-trans-package in lisp/leim/quail/indian.el.  This
> function calls quail-define-package with a nil SIMPLE argument which
> steals the commonly used motion keys C-f, C-b, C-n, C-p.  AFAICT from
> what I read in quail a year or so ago, this argument is more useful for
> the Chinese and the Japanese input methods but not so much for simple
> IMs like the itrans one which only does transliteration.  Besides, even
> if an IM has one to many translation i.e., if "a" can be translated to
> "a->" and "a->>", and the SIMPLE argument is non-nil, one can use the
> number keys to select the alternate translation.
>
> Since the nil value of SIMPLE argument gives no real benefit in the case
> of tamil-itrans IM, I would like to change it to t so that we can get
> the motion keys back.  However, I have only ever used the Tamil IM and
> thus have no idea about the other languages.  Then we can adjust the
> quail-define-indian-trans-package function to pass a custom SIMPLE
> argument instead.
>

[-- Attachment #2: Type: text/html, Size: 2016 bytes --]

Re: itrans input methods and motion keys

[Visuwesh]

[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]

[புதன் ஜூன் 29, 2022] समीर सिंह Sameer Singh wrote:

> I am sorry I do not use the itrans input methods, therefore do not know
> much about it :(
> So may I know why are motion keys disabled while typing in these input
> methods?
>

It is not that they are disabled but they are in conflict with the
keybindings in quail-translation-keymap so you no longer have access to
the motion keys.

Quail has facility to make use of a dictionary to insert text: the
Chinese and the Japanese input methods use these.  When such a facility
is used, the translation keymap is useful since you have to pick from
multiple translations for an input sequence, however, IME itrans is not
such a complex IM so not having it be a SIMPLE quail IM is annoying
since the quail-translation-keymap steals the motion keys.

If this is still not clear, you can think of a non-SIMPLE quail IM as
akin to the Google input tools.  You type in text, it presents multiple
translations of the text, then you select one.  But what happens in an
itrans method is simple transliteration for which a SIMPLE quail IM
should be good enough.

And reading the code more a bit, I think pushing the following patch
shouldn't bring in any new annoyances.  Can someone push it please?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Stop-itrans-input-methods-from-stealing-motion-keys.patch --]
[-- Type: text/x-diff, Size: 1217 bytes --]

From 493f0f63ddda2a3a8a360cec76c9f221aecac29d Mon Sep 17 00:00:00 2001
From: Visuwesh <visuweshm@gmail.com>
Date: Wed, 29 Jun 2022 17:42:18 +0530
Subject: [PATCH] Stop itrans input methods from stealing motion keys

The itrans input methods only do transliteration and as such don't
need any of the fancy features a non-SIMPLE quail package offers.
This change prevents the itrans IMs from stealing the motion keys.

See <https://lists.gnu.org/r/emacs-devel/2022-06/msg01212.html>.

* leim/quail/indian.el (quail-define-indian-trans-package): Make the
SIMPLE argument non-nil.
---
 lisp/leim/quail/indian.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/leim/quail/indian.el b/lisp/leim/quail/indian.el
index 8fffcc3511..a67af1cac5 100644
--- a/lisp/leim/quail/indian.el
+++ b/lisp/leim/quail/indian.el
@@ -43,7 +43,7 @@ quail-define-indian-trans-package
   ;; determining that this is a quail definition (it searches for
   ;; "(quail-define-package").
   (funcall #'quail-define-package pkgname lang title t doc
-	   nil nil nil nil nil nil t nil)
+	   nil nil nil nil nil nil t nil nil nil t)
   (maphash
    (lambda (key val)
      (quail-defrule key (if (= (length val) 1)
-- 
2.35.1

Re: itrans input methods and motion keys, itrans input methods and motion keys

[James Thomas]

Visuwesh wrote:

> the motion keys back.  However, I have only ever used the Tamil IM and
> thus have no idea about the other languages.  Then we can adjust the
> quail-define-indian-trans-package function to pass a custom SIMPLE
> argument instead.

There do not seem to be any ambiguous (multiple) transliterations in the
ITRANS specification [1] nor in any of the other tables (like 'aiba') in
ind-util.el, from a quick glance at the code. So you would be correct.
But in that case, couldn't the DETERMINISTIC argument also be set, as I
had done separately for malayalam-mozhi?

--
[1] https://en.wikipedia.org/wiki/ITRANS

Re: itrans input methods and motion keys, itrans input methods and motion keys

[Visuwesh]

[சனி ஜூலை 02, 2022] James Thomas wrote:

> Visuwesh wrote:
>
>> the motion keys back.  However, I have only ever used the Tamil IM and
>> thus have no idea about the other languages.  Then we can adjust the
>> quail-define-indian-trans-package function to pass a custom SIMPLE
>> argument instead.
>
> There do not seem to be any ambiguous (multiple) transliterations in the
> ITRANS specification [1] nor in any of the other tables (like 'aiba') in
> ind-util.el, from a quick glance at the code. So you would be correct.

Thanks.  I also came to that conclusion after reading the base-tables
for other languages.

> But in that case, couldn't the DETERMINISTIC argument also be set, as I
> had done separately for malayalam-mozhi?
>

Unfortunately, I'm not quite sure what it does.  I also cannot read
Malayalam at all so I cannot try to figure it out by trial and error (I
can at least read Devanagari a bit).  Can you explain what it does?


> --
> [1] https://en.wikipedia.org/wiki/ITRANS

[PATCH] Re: itrans input methods and motion keys

[James Thomas]

Visuwesh wrote:

> Unfortunately, I'm not quite sure what it does.  I also cannot read
> Malayalam at all so I cannot try to figure it out by trial and error (I
> can at least read Devanagari a bit).  Can you explain what it does?

From the docstring:

> DETERMINISTIC non-nil means the first candidate of translation is
> selected automatically without allowing users to select another
> translation for a key.

So if we've concluded that there is only one valid candidate for
translation of the current input (upto the last key), there would be no
harm is setting it. SIMPLE simply controls one of the keyboard
mechanisms for selecting any such alternative candidates. Someone who
uses Devanagari should probably test it and weigh in, though.

In any case I'd like to throw in a patch for a similar change to
malayalam-mozhi, which I've tested. :)

diff --git a/lisp/leim/quail/indian.el b/lisp/leim/quail/indian.el
index 23204c0cd3..d8cc94c676 100644
--- a/lisp/leim/quail/indian.el
+++ b/lisp/leim/quail/indian.el
@@ -633,7 +633,7 @@ indian-mlm-mozhi-update-translation
 (quail-define-package "malayalam-mozhi" "Malayalam" "MlmMI" t
                       "Malayalam transliteration by Mozhi method."
                       nil nil t nil nil nil t nil
-                      #'indian-mlm-mozhi-update-translation)
+                      #'indian-mlm-mozhi-update-translation nil t)

 (maphash
  (lambda (key val)


--

Re: [PATCH] Re: itrans input methods and motion keys

[Visuwesh]

[சனி ஜூலை 02, 2022] James Thomas wrote:

> Visuwesh wrote:
>
>> Unfortunately, I'm not quite sure what it does.  I also cannot read
>> Malayalam at all so I cannot try to figure it out by trial and error (I
>> can at least read Devanagari a bit).  Can you explain what it does?
>
> From the docstring:
>
>> DETERMINISTIC non-nil means the first candidate of translation is
>> selected automatically without allowing users to select another
>> translation for a key.
>
> So if we've concluded that there is only one valid candidate for
> translation of the current input (upto the last key), there would be no
> harm is setting it. SIMPLE simply controls one of the keyboard
> mechanisms for selecting any such alternative candidates. Someone who
> uses Devanagari should probably test it and weigh in, though.
>

Hmm, so SIMPLE disables the translation-keymap and DETERMINISTIC selects
the first candidate?  I wonder why they are mutually exclusive in the
first place...  Thanks for the explanation.

> In any case I'd like to throw in a patch for a similar change to
> malayalam-mozhi, which I've tested. :)
>
> diff --git a/lisp/leim/quail/indian.el b/lisp/leim/quail/indian.el
> index 23204c0cd3..d8cc94c676 100644
> --- a/lisp/leim/quail/indian.el
> +++ b/lisp/leim/quail/indian.el
> @@ -633,7 +633,7 @@ indian-mlm-mozhi-update-translation
>  (quail-define-package "malayalam-mozhi" "Malayalam" "MlmMI" t
>                        "Malayalam transliteration by Mozhi method."
>                        nil nil t nil nil nil t nil
> -                      #'indian-mlm-mozhi-update-translation)
> +                      #'indian-mlm-mozhi-update-translation nil t)
>
>  (maphash
>   (lambda (key val)
>
>
> --

Re: [PATCH] Re: itrans input methods and motion keys

[Visuwesh]

[சனி ஜூலை 02, 2022] James Thomas wrote:

> Visuwesh wrote:
>
>> Unfortunately, I'm not quite sure what it does.  I also cannot read
>> Malayalam at all so I cannot try to figure it out by trial and error (I
>> can at least read Devanagari a bit).  Can you explain what it does?
>
> From the docstring:
>
>> DETERMINISTIC non-nil means the first candidate of translation is
>> selected automatically without allowing users to select another
>> translation for a key.
>
> So if we've concluded that there is only one valid candidate for
> translation of the current input (upto the last key), there would be no
> harm is setting it. SIMPLE simply controls one of the keyboard
> mechanisms for selecting any such alternative candidates. Someone who
> uses Devanagari should probably test it and weigh in, though.
>

Hmm, so SIMPLE disables the translation-keymap and DETERMINISTIC selects
the first candidate?  I wonder why they are mutually exclusive in the
first place...  Thanks for the explanation.

> In any case I'd like to throw in a patch for a similar change to
> malayalam-mozhi, which I've tested. :)
>
> diff --git a/lisp/leim/quail/indian.el b/lisp/leim/quail/indian.el
> index 23204c0cd3..d8cc94c676 100644
> --- a/lisp/leim/quail/indian.el
> +++ b/lisp/leim/quail/indian.el
> @@ -633,7 +633,7 @@ indian-mlm-mozhi-update-translation
>  (quail-define-package "malayalam-mozhi" "Malayalam" "MlmMI" t
>                        "Malayalam transliteration by Mozhi method."
>                        nil nil t nil nil nil t nil
> -                      #'indian-mlm-mozhi-update-translation)
> +                      #'indian-mlm-mozhi-update-translation nil t)
>
>  (maphash
>   (lambda (key val)
>
>
> --

Re: [PATCH] Re: itrans input methods and motion keys

[Eli Zaretskii]

> From: James Thomas <jimjoe@gmx.net>
> Cc: emacs-devel@gnu.org
> Date: Sat, 02 Jul 2022 14:53:54 +0530
> 
> From the docstring:
> 
> > DETERMINISTIC non-nil means the first candidate of translation is
> > selected automatically without allowing users to select another
> > translation for a key.
> 
> So if we've concluded that there is only one valid candidate for
> translation of the current input (upto the last key), there would be no
> harm is setting it. SIMPLE simply controls one of the keyboard
> mechanisms for selecting any such alternative candidates. Someone who
> uses Devanagari should probably test it and weigh in, though.
> 
> In any case I'd like to throw in a patch for a similar change to
> malayalam-mozhi, which I've tested. :)

Thanks, installed.