bug#52245: Wishlist: cycle input methods

bug#52245: Wishlist: cycle input methods

[Tor Kringeland]

This was suggested by Robert Pluim and discussed in bug#52173.

Basically, extend `toggle-input-method' to cycle through multiple input
methods, which would be very useful for multilingual writing.

bug#52245: Wishlist: cycle input methods

[Robert Pluim]

>>>>> On Thu, 02 Dec 2021 16:30:18 +0100, Tor Kringeland <tor.a.s.kringeland@ntnu.no> said:

    Tor> This was suggested by Robert Pluim and discussed in bug#52173.
    Tor> Basically, extend `toggle-input-method' to cycle through multiple input
    Tor> methods, which would be very useful for multilingual writing.

Having slept since then 😊, Iʼve come up with a slightly different
variant.

`default-input-method' is currently either nil or an input method to
use for `toggle-input-method'. Extend it to allow it to be a list to
cycle through, containing either

- input-method symbols
- the symbol 'input-method-history

So you could have eg

'(latin-prefix input-method-history czech)

If input-method-history contained 'polish, then cycling would go

latin-prefix -> polish -> czech -> no input method

Robert
-- 

bug#52245: Wishlist: cycle input methods

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Thu, 02 Dec 2021 16:49:56 +0100
> Cc: 52245@debbugs.gnu.org
> 
> `default-input-method' is currently either nil or an input method to
> use for `toggle-input-method'. Extend it to allow it to be a list to
> cycle through, containing either
> 
> - input-method symbols
> - the symbol 'input-method-history
> 
> So you could have eg
> 
> '(latin-prefix input-method-history czech)
> 
> If input-method-history contained 'polish, then cycling would go
> 
> latin-prefix -> polish -> czech -> no input method

That's okay, but we should have this as an optional behavior, so that
people could still toggle only between some input method and no input
method with a single C-\, even if they defined a list of them.

bug#52245: Wishlist: cycle input methods

[Robert Pluim]

>>>>> On Thu, 02 Dec 2021 20:14:00 +0200, Eli Zaretskii <eliz@gnu.org> said:

    Eli> That's okay, but we should have this as an optional behavior, so that
    Eli> people could still toggle only between some input method and no input
    Eli> method with a single C-\, even if they defined a list of them.

It would be optional: people who choose to customize
default-input-method to a list get the behaviour, people who leave it
as a symbol donʼt. I donʼt see why weʼd need to add
yet-another-variable to essentially say "ignore this request you've
made via this other variable".

Robert
-- 

bug#52245: Wishlist: cycle input methods

[André A. Gomes]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Date: Thu, 02 Dec 2021 16:49:56 +0100
>> Cc: 52245@debbugs.gnu.org
>>
>> `default-input-method' is currently either nil or an input method to
>> use for `toggle-input-method'. Extend it to allow it to be a list to
>> cycle through, containing either
>>
>> - input-method symbols
>> - the symbol 'input-method-history
>>
>> So you could have eg
>>
>> '(latin-prefix input-method-history czech)
>>
>> If input-method-history contained 'polish, then cycling would go
>>
>> latin-prefix -> polish -> czech -> no input method
>
> That's okay, but we should have this as an optional behavior, so that
> people could still toggle only between some input method and no input
> method with a single C-\, even if they defined a list of them.

I agree, but there's a minor detail.  C-\ should not toggle between nil
and the last selected input method, but between the last selected input
method and `default-input-method`, which might be non-nil.


--
André A. Gomes
"Free Thought, Free World"

bug#52245: Wishlist: cycle input methods

[André A. Gomes]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Thu, 02 Dec 2021 20:14:00 +0200, Eli Zaretskii <eliz@gnu.org> said:
>
>     Eli> That's okay, but we should have this as an optional behavior, so that
>     Eli> people could still toggle only between some input method and no input
>     Eli> method with a single C-\, even if they defined a list of them.
>
> It would be optional: people who choose to customize
> default-input-method to a list get the behaviour, people who leave it
> as a symbol donʼt. I donʼt see why weʼd need to add
> yet-another-variable to essentially say "ignore this request you've
> made via this other variable".

If I understand correctly, we're not discussing variables but commands.
Eli urges that it's import to keep C-\ as a toggle, and to add another
command to cycle the ring.  Seems fair to me, so that the old behaviour
is preserved.

Let's continue the discussion since I find this feature valuable.


--
André A. Gomes
"Free Thought, Free World"

bug#52245: Wishlist: cycle input methods

[Robert Pluim]

>>>>> On Tue, 07 Dec 2021 15:57:55 +0000, André A. Gomes <andremegafone@gmail.com> said:

    André> Robert Pluim <rpluim@gmail.com> writes:
    >>>>>>> On Thu, 02 Dec 2021 20:14:00 +0200, Eli Zaretskii <eliz@gnu.org> said:
    >> 
    Eli> That's okay, but we should have this as an optional behavior, so that
    Eli> people could still toggle only between some input method and no input
    Eli> method with a single C-\, even if they defined a list of them.
    >> 
    >> It would be optional: people who choose to customize
    >> default-input-method to a list get the behaviour, people who leave it
    >> as a symbol donʼt. I donʼt see why weʼd need to add
    >> yet-another-variable to essentially say "ignore this request you've
    >> made via this other variable".

    André> If I understand correctly, we're not discussing variables but commands.
    André> Eli urges that it's import to keep C-\ as a toggle, and to add another
    André> command to cycle the ring.  Seems fair to me, so that the old behaviour
    André> is preserved.

We can keep C-\ as a toggle, 100% identical to how it works today. All
people who have customized `default-input-method' to a single value
have to do is nothing whatsoever.

If weʼre now saying we want a separate command that cycles through a
list of input methods, then we might as well add a separate user
option for that list (and then we could add *another* user option
called input-method-toggle-or-cycle to indicate which command should
be used for C-\)

I guess we could also have C-u C-u C-\ mean 'cycle', but thatʼs
unergonomic.

Robert
-- 

bug#52245: Wishlist: cycle input methods

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  tor.a.s.kringeland@ntnu.no,
>   52245@debbugs.gnu.org
> Date: Tue, 07 Dec 2021 17:30:19 +0100
> 
>     André> If I understand correctly, we're not discussing variables but commands.
>     André> Eli urges that it's import to keep C-\ as a toggle, and to add another
>     André> command to cycle the ring.  Seems fair to me, so that the old behaviour
>     André> is preserved.
> 
> We can keep C-\ as a toggle, 100% identical to how it works today. All
> people who have customized `default-input-method' to a single value
> have to do is nothing whatsoever.
> 
> If weʼre now saying we want a separate command that cycles through a
> list of input methods, then we might as well add a separate user
> option for that list (and then we could add *another* user option
> called input-method-toggle-or-cycle to indicate which command should
> be used for C-\)
> 
> I guess we could also have C-u C-u C-\ mean 'cycle', but thatʼs
> unergonomic.

The use case that I have in mind is this: even if the user customized
the list of input methods to include more than just one, there could
be situations where the user needs to use just one input method when
typing.  In such situations, it would be good to have a way of
toggling, like we do now, instead of cycling through all the other
methods.

Any reasonable solution to this use case would be welcome.  I'm
working with systems which allow you to do something like that, and it
frequently annoys me to have to cycle through all the keyboard layouts
I defined, just to be able to toggle between US English and some other
language.  So I wish that Emacs didn't have such an annoying problem,
if possible.

bug#52245: Wishlist: cycle input methods

[Robert Pluim]

>>>>> On Tue, 07 Dec 2021 19:11:45 +0200, Eli Zaretskii <eliz@gnu.org> said:
    >> If weʼre now saying we want a separate command that cycles through a
    >> list of input methods, then we might as well add a separate user
    >> option for that list (and then we could add *another* user option
    >> called input-method-toggle-or-cycle to indicate which command should
    >> be used for C-\)
    >> 
    >> I guess we could also have C-u C-u C-\ mean 'cycle', but thatʼs
    >> unergonomic.

    Eli> The use case that I have in mind is this: even if the user customized
    Eli> the list of input methods to include more than just one, there could
    Eli> be situations where the user needs to use just one input method when
    Eli> typing.  In such situations, it would be good to have a way of
    Eli> toggling, like we do now, instead of cycling through all the other
    Eli> methods.

    Eli> Any reasonable solution to this use case would be welcome.  I'm
    Eli> working with systems which allow you to do something like that, and it
    Eli> frequently annoys me to have to cycle through all the keyboard layouts
    Eli> I defined, just to be able to toggle between US English and some other
    Eli> language.  So I wish that Emacs didn't have such an annoying problem,
    Eli> if possible.

Hmm, so how about:

- default-input-method is an atom
  ⇒ C-\ behaves as a toggle

- default-input method is a list
  ⇒ C-\ cycles through them and back to nil
  ⇒ C-\ with a prefix arg behaves as today, prompting
    for an input method. C-\ again deactivates the input method

- C-u C-u C-\ just unconditionally deactives the current input method,
  regardless of the value of default-input-method. Or would 'any
  negative prefix arg' suit better?

I now think having the history automatically be part of the list of
values to cycle through would not be a good idea: that history can get
large, and it can contain duplicates (by default), so trying to reach
the end of your default-input-method list could be annoying.

Robert
-- 

bug#52245: Wishlist: cycle input methods

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: andremegafone@gmail.com,  tor.a.s.kringeland@ntnu.no,
>   52245@debbugs.gnu.org
> Date: Wed, 08 Dec 2021 10:40:01 +0100
> 
>     Eli> The use case that I have in mind is this: even if the user customized
>     Eli> the list of input methods to include more than just one, there could
>     Eli> be situations where the user needs to use just one input method when
>     Eli> typing.  In such situations, it would be good to have a way of
>     Eli> toggling, like we do now, instead of cycling through all the other
>     Eli> methods.
> 
>     Eli> Any reasonable solution to this use case would be welcome.  I'm
>     Eli> working with systems which allow you to do something like that, and it
>     Eli> frequently annoys me to have to cycle through all the keyboard layouts
>     Eli> I defined, just to be able to toggle between US English and some other
>     Eli> language.  So I wish that Emacs didn't have such an annoying problem,
>     Eli> if possible.
> 
> Hmm, so how about:
> 
> - default-input-method is an atom
>   ⇒ C-\ behaves as a toggle
> 
> - default-input method is a list
>   ⇒ C-\ cycles through them and back to nil
>   ⇒ C-\ with a prefix arg behaves as today, prompting
>     for an input method. C-\ again deactivates the input method

Sounds good, but I don't understand how you will pull out the trick in
the last sentence.  How will Emacs know to "just deactivate" instead
of cycling?

bug#52245: Wishlist: cycle input methods

[Robert Pluim]

>>>>> On Wed, 08 Dec 2021 15:26:05 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Hmm, so how about:
    >> 
    >> - default-input-method is an atom
    >> ⇒ C-\ behaves as a toggle
    >> 
    >> - default-input method is a list
    >> ⇒ C-\ cycles through them and back to nil
    >> ⇒ C-\ with a prefix arg behaves as today, prompting
    >> for an input method. C-\ again deactivates the input method

    Eli> Sounds good, but I don't understand how you will pull out the trick in
    Eli> the last sentence.  How will Emacs know to "just deactivate" instead
    Eli> of cycling?

Similar to how it knows to toggle today, by storing an "I was
activated via prefix" state in a defvar-local state variable.

What did you think of the C-u C-u C-\ suggestion to mean "always
deactivate"? Or do you feel itʼs unnecessary?

Robert
-- 

bug#52245: Wishlist: cycle input methods

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: andremegafone@gmail.com,  tor.a.s.kringeland@ntnu.no,
>   52245@debbugs.gnu.org
> Date: Wed, 08 Dec 2021 14:44:25 +0100
> 
> >>>>> On Wed, 08 Dec 2021 15:26:05 +0200, Eli Zaretskii <eliz@gnu.org> said:
> 
>     >> From: Robert Pluim <rpluim@gmail.com>
>     >> Hmm, so how about:
>     >> 
>     >> - default-input-method is an atom
>     >> ⇒ C-\ behaves as a toggle
>     >> 
>     >> - default-input method is a list
>     >> ⇒ C-\ cycles through them and back to nil
>     >> ⇒ C-\ with a prefix arg behaves as today, prompting
>     >> for an input method. C-\ again deactivates the input method
> 
>     Eli> Sounds good, but I don't understand how you will pull out the trick in
>     Eli> the last sentence.  How will Emacs know to "just deactivate" instead
>     Eli> of cycling?
> 
> Similar to how it knows to toggle today, by storing an "I was
> activated via prefix" state in a defvar-local state variable.

Hmm... so just C-\ to activate is not enough to cause the toggle back?

> What did you think of the C-u C-u C-\ suggestion to mean "always
> deactivate"? Or do you feel itʼs unnecessary?

Given the above, some way of turning off the input method is
necessary, I think.

bug#52245: Wishlist: cycle input methods

[Robert Pluim]

>>>>> On Wed, 08 Dec 2021 16:29:18 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>

    Eli> Sounds good, but I don't understand how you will pull out the trick in
    Eli> the last sentence.  How will Emacs know to "just deactivate" instead
    Eli> of cycling?
    >> 
    >> Similar to how it knows to toggle today, by storing an "I was
    >> activated via prefix" state in a defvar-local state variable.

    Eli> Hmm... so just C-\ to activate is not enough to cause the toggle back?

No, because you need to distinguish "Iʼm cycling through
default-input-method" from "previous invocation used prefix", since in
the former you need to look up the current input method in
default-input-method and then activate the next one.

Hmm, what do we expect for the following sequence, assuming
default-input-method of '(a b c), and no input method activated.

1. C-\ ; activates a
2. C-u C-\ d RET ; activates d
3. C-\ ; back to a, I guess
4. C-\ ; activates b

Or do we want step 3 to be 'deactivate input method'?

    >> What did you think of the C-u C-u C-\ suggestion to mean "always
    >> deactivate"? Or do you feel itʼs unnecessary?

    Eli> Given the above, some way of turning off the input method is
    Eli> necessary, I think.

Escape hatches are always good, especially if we end up with confusing
behaviour :-)

Robert
-- 

bug#52245: Wishlist: cycle input methods

[John Ankarström]

Eli Zaretskii <eliz@gnu.org> writes:

> The use case that I have in mind is this: even if the user customized
> the list of input methods to include more than just one, there could
> be situations where the user needs to use just one input method when
> typing.  In such situations, it would be good to have a way of
> toggling, like we do now, instead of cycling through all the other
> methods.
>
> Any reasonable solution to this use case would be welcome.  I'm
> working with systems which allow you to do something like that, and it
> frequently annoys me to have to cycle through all the keyboard layouts
> I defined, just to be able to toggle between US English and some other
> language.  So I wish that Emacs didn't have such an annoying problem,
> if possible.

IIRC Windows 10 handles this by implementing the input method list as a
stack of sorts, so that Win-Space selects an input method similarly to
how Alt-Tab selects a window. Pressing Win-Space once is a toggle, but
pressing Win-Space consecutively (while holding Win) cycles through all
input methods.

Emacs could do something similar. A single C-\ could toggle between the
two input methods at the top of the list, whereas any number of
consecutive C-\'s could cycle the list. The implementation would just
need to check last-command.

bug#52245: Wishlist: cycle input methods

[André A. Gomes]

John Ankarström <john@ankarstrom.se> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> The use case that I have in mind is this: even if the user customized
>> the list of input methods to include more than just one, there could
>> be situations where the user needs to use just one input method when
>> typing.  In such situations, it would be good to have a way of
>> toggling, like we do now, instead of cycling through all the other
>> methods.
>>
>> Any reasonable solution to this use case would be welcome.  I'm
>> working with systems which allow you to do something like that, and it
>> frequently annoys me to have to cycle through all the keyboard layouts
>> I defined, just to be able to toggle between US English and some other
>> language.  So I wish that Emacs didn't have such an annoying problem,
>> if possible.
>
> IIRC Windows 10 handles this by implementing the input method list as a
> stack of sorts, so that Win-Space selects an input method similarly to
> how Alt-Tab selects a window. Pressing Win-Space once is a toggle, but
> pressing Win-Space consecutively (while holding Win) cycles through all
> input methods.
>
> Emacs could do something similar. A single C-\ could toggle between the
> two input methods at the top of the list, whereas any number of
> consecutive C-\'s could cycle the list. The implementation would just
> need to check last-command.

Could be a possibility indeed.

Let me raise a concern on this topic.  In Emacs, nil is what we call the
default OS-level IM (or the one dictated by the keyboard firmware).  But
this presents an issue since it both means "the nil input method", which
in itself might be english-us, and that `default-input-method' is
unbound.

I propose thinking about what we have today (no IM cycling, just the
toggle) and see if we need changes before moving on with the more
general case.

Let's think about a simple case - using 2 IMs.  Today you can't easily
go from input method A to B with C-\, unless either A or B is nil.  This
is because `default-input-method' is a buffer-local variable, and it
changes as the user selects IMs.

I suggest that `default-input-method' should be set to "default" and
shouldn't be mutated.  When already in use, fallback to the IM history
ring.  Yes, this requires some re-writing.


--
André A. Gomes
"Free Thought, Free World"

bug#52245: Wishlist: cycle input methods

[Juri Linkov]

>> I guess we could also have C-u C-u C-\ mean 'cycle', but thatʼs
>> unergonomic.
>
> The use case that I have in mind is this: even if the user customized
> the list of input methods to include more than just one, there could
> be situations where the user needs to use just one input method when
> typing.  In such situations, it would be good to have a way of
> toggling, like we do now, instead of cycling through all the other
> methods.
>
> Any reasonable solution to this use case would be welcome.  I'm
> working with systems which allow you to do something like that, and it
> frequently annoys me to have to cycle through all the keyboard layouts
> I defined, just to be able to toggle between US English and some other
> language.  So I wish that Emacs didn't have such an annoying problem,
> if possible.

I have the same problem that cycling more than 2 keyboard layouts
is annoying.  It would be possible to avoid such a problem in Emacs
by using numeric prefix arguments, e.g.:

  C-1 C-\  activates the first input methods in the list of input methods
  C-2 C-\  second
  C-3 C-\  third
  ...
  C-0 C-\  deactivates the currently active input method

bug#52245: Wishlist: cycle input methods

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Robert Pluim <rpluim@gmail.com>,  andremegafone@gmail.com,
>   tor.a.s.kringeland@ntnu.no,  52245@debbugs.gnu.org
> Date: Thu, 23 Dec 2021 20:02:33 +0200
> 
>   C-1 C-\  activates the first input methods in the list of input methods
>   C-2 C-\  second
>   C-3 C-\  third
>   ...
>   C-0 C-\  deactivates the currently active input method

The problem with this system is that the user needs to remember which
IM is the first and which the second.

bug#52245: Wishlist: cycle input methods

[Juri Linkov]

>>   C-1 C-\  activates the first input methods in the list of input methods
>>   C-2 C-\  second
>>   C-3 C-\  third
>>   ...
>>   C-0 C-\  deactivates the currently active input method
>
> The problem with this system is that the user needs to remember which
> IM is the first and which the second.

The user already needs to remember the sequence of configured keyboard layouts
to be able to cycle them without looking at the indicator of the current layout.
The problem that makes such cycling annoying is that when the user forgets
what is the current layout, cycling selects a wrong layout.  Using a number
to select the layout avoids such a problem.