Re: Swapping default input method: why so complicated?

Re: Swapping default input method: why so complicated?

[Ted Zlatanov]

On Mon, 15 Nov 2010 08:08:34 +0000 (UTC) Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote: 

IZ> I'm trying to do what I consider a very typical requirement: swap two
IZ> values of default input method.  Unfortunately, I could not find any
IZ> documented solution (outside of info-manuals, just using f1 v and f1
IZ> f).  To get it working, I was forced to inspect the sources...  Is
IZ> there a simpler solution?

IZ> (defun my-cyr-switch-input-method ()
IZ>   "Switch cyrillic input method between cyrillic-yawerty and cyrillic-jcuken."
IZ>   (interactive)
IZ>   (let (n (o (or current-input-method
IZ>                  (car input-method-history)
IZ>                  default-input-method))
IZ>           (c current-input-method))
IZ>     (setq n (if (equal o "cyrillic-yawerty")
IZ>                 "cyrillic-jcuken"
IZ>               "cyrillic-yawerty"))
IZ>     (set-input-method n)
IZ>     (or c (set-input-method nil))
IZ>     (message "Toggled default input method to \"%s\"; toggle on/off by Ctrl-\\" n)))

I usually use `C-u M-x toggle-input-method' which queries and has a
history of past choices.  But it would be nice if there was a
`cycle-input-method' that cycled among several choices (or,
alternatively, `default-input-method' could be allowed to be a list and
then `toggle-input-method' could select the first element of the list
and then rotate the list).

Ted

Re: Swapping default input method: why so complicated?

[Ted Zlatanov]

On Mon, 15 Nov 2010 14:55:55 +0100 pjb@informatimago.com (Pascal J. Bourguignon) wrote: 

PJB> Ilya Zakharevich <nospam-abuse@ilyaz.org> writes:
>> I'm trying to do what I consider a very typical requirement: swap two
>> values of default input method.  Unfortunately, I could not find any
>> documented solution (outside of info-manuals, just using f1 v and f1
>> f).  To get it working, I was forced to inspect the sources...  Is
>> there a simpler solution?

PJB> What is complicated in typing  C-\  which is bound to
PJB> toggle-input-method by default?

PJB> You just use:

PJB>    M-x set-input-method RET cyrillic-yawerty RET
PJB>    M-x set-input-method RET cyrillic-jcuken RET

PJB> to select your two input methods, and then type C-\

That only toggles the last input method that was set.  Hence my
suggestion about cycling (by explicit command or implicitly by setting
the input method to a list).

Ted

Re: Swapping default input method: why so complicated?

[Stefan Monnier]

> I'm trying to do what I consider a very typical requirement: swap two
> values of default input method.  Unfortunately, I could not find any
> documented solution (outside of info-manuals, just using f1 v and f1
> f).  To get it working, I was forced to inspect the sources...  Is
> there a simpler solution?

I must say I do not really understand what you're trying to do, but to
change between two different values of default input methods, I'd do
something like:

   (defun my-foo ()
     (interactive)
     (setq default-input-method
           (if (eq default-input-method 'toto) 'titi 'toto)))

but that only affects the default method to use, not the method actually
in use.


        Stefan

Re: Swapping default input method: why so complicated?

[Ilya Zakharevich]

  [Please keep in mind that my rambling addresses two interrelated topics:

	  a) current deficiencies in programmatically modifying the
	     list of "active" input methods;

	  b) Possible ways to simplify (mega-) multi-lingual input. ]

On 2010-11-16, Ted Zlatanov <tzz@lifelogs.com> wrote:
> On Mon, 15 Nov 2010 20:52:43 +0000 (UTC) Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote: 
> IZ> So in this situation one needs two-level toggle: one between targets
> IZ> (Latin/Cyrillic), another between flavors for each target.  This gives
> IZ> one of the Emacs interface designs: it should be easy to allow people
> IZ> to code such multi-level switches programmatically, without a need to
> IZ> write monstrosities similar to what I did.
>
> I think that's a very unusual need.  Most people will be happy with
> cycling between input methods (if that).

Given that M$ (finally!) made it easy to do, I doubt your judgement.
For me, what you say looks like a self-fulfilling prophecy: as far as
this is hard to do, there will not be a large need.

Anybody who writes in languages using different scripts, cooperates
with other people (at physical proximity, so people may share a
physical keyboard), and generates a lot of math has similar needs.

  (They may not realize that the solution is "almost at hand", though.)

>  So I'd rather make you write one custom function than enable a
> complicated two-level setup for everyone.

But *this* is exaclty the point of my post!  It is SO complicated to
write such a function now: it looks like the behaviour of "builtin
switchers" is based on undocumented interaction of 3 pieces of
(undocumented?) data: current-stuff, history-list, and default-stuff
(see my code).

> IZ> Experience shows that for me, most other input needs would
> IZ> be satisfied by suitable prefix keys (for the duration of next
> IZ> character) for input of greek, hebrew, half a dozen of flavors of
> IZ> math.  The current Emacs approach (where one needs to type the long
> IZ> name of the encoding) does not fit the bills.  (Outside Emacs, I use
> IZ> F-keys to switch to one-char input methods; so F5 b inputs beta, and
> IZ> F6 + would input "union sign".  But in Emacs, they already bound for
> IZ> other repetitive stuff...)
>
> Just use Pascal's direct-set example.  That's the easiest solution to
> your needs, I think.

No go.  The needs (as I understand them after reading this thread)
require several "layers of history".

The problem is that some "input method switchings" are "better than
the others".  Some are intended to last for sentances/paragraphs; some
for input of a single word, and some for input of one char.  The fact
that nowadays ANY switching messes what the following switching would
do discourages switching.  AFAICS, the necessary layers of history
might be implemented along following lines:

  A) the topmost is (only occasionally active) for-one-character-only temporary
     input method.  When this character is input, this input method
     should go away.

     There is no strong need to store this method in any history. (But
     one may still want to introduce a separate history which does not
     interact with other two "layers".)

     Most of the time, the particular input method would be one of the
     lists B1, B2 below.

  B) The rest of time "the state of input" is either in

     B1) the "principal list of targets" (for me, it would be Latin
	 and Cyrillic), or in

     B2) "additional list of targets" (for me: Greek, flavors of math
	 alphabets, Hebrew, and ASCII-like-plotting Unicode-symbols).

     The INTENT of input methods for B1 is to be active for long time
     (a sentence, or a paragraph).  Input methods for B2 would be
     active for a short time (for a word; to input a standalone char,
     it may be better to do as in (A)).

     From the point of view of coding it, one of the differences
     between B1 and B2 is what C-\ (or whatever) should do: when in B2
     list, it should return to the last active B1 method;  when in B1,
     it should cycle through the B1 list.

     In short, one would use C-\ for several purposes: cycling B1
     list, AND returning to B1 list from the B2 list.  To switch to
     one of B2 encodings, one would need extra bindings (e.g., on Fn
     keys); some modifications of these keys would be used to switch
     to one-char input (as in A).

	[Hmm, I see that this mixing of two semantics of C-\ does not
	 "work intuitively" when there are more than 2 targets in the
	 B1 list.  Not surprising: I work with only two, so any
	 solution I may come with is biased to this situation...]

==========

But this is not all: what I discussed above are "targets" (think of
character repertoires); it must be also easy to switch particular
input methods for each target.  At some moment I know that "I want to
enter a greek word" - but this does not fix the input method; I may
want to experiment with a new one; or a collaborator may sit for a
minute at keyboard, and he may be more comfortable with a different
method than me.

The simplest implementation would be to allow an entry in the lists
above to be an array ["actual-input-method" "target"].  So it would be
the user's responsibility to write code which scans through all the
lists in question, and toggles/sets the input-method for one
particular target.

A cleaner implementation would be to have "symbolic names of targets"
in the lists for A/B1/B2 which are translated to an input method via
an associative array.

Ilya

Re: Swapping default input method: why so complicated?

[Ted Zlatanov]

On Wed, 17 Nov 2010 09:57:33 +0000 (UTC) Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote: 

IZ> On 2010-11-16, Ted Zlatanov <tzz@lifelogs.com> wrote:
>> On Mon, 15 Nov 2010 20:52:43 +0000 (UTC) Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote: 
IZ> So in this situation one needs two-level toggle: one between targets
IZ> (Latin/Cyrillic), another between flavors for each target.  This gives
IZ> one of the Emacs interface designs: it should be easy to allow people
IZ> to code such multi-level switches programmatically, without a need to
IZ> write monstrosities similar to what I did.
>> 
>> I think that's a very unusual need.  Most people will be happy with
>> cycling between input methods (if that).

IZ> For me, what you say looks like a self-fulfilling prophecy: as far as
IZ> this is hard to do, there will not be a large need.

We seem to be stuck in a circular argument.  But let's look at your
needs and proposed solutions:

IZ> No go.  The needs (as I understand them after reading this thread)
IZ> require several "layers of history".

IZ> The problem is that some "input method switchings" are "better than
IZ> the others".  Some are intended to last for sentances/paragraphs; some
IZ> for input of a single word, and some for input of one char.  The fact
IZ> that nowadays ANY switching messes what the following switching would
IZ> do discourages switching.  AFAICS, the necessary layers of history
IZ> might be implemented along following lines:

IZ>   A) the topmost is (only occasionally active) for-one-character-only temporary
IZ>      input method.  When this character is input, this input method
IZ>      should go away.

IZ>      There is no strong need to store this method in any history. (But
IZ>      one may still want to introduce a separate history which does not
IZ>      interact with other two "layers".)

IZ>      Most of the time, the particular input method would be one of the
IZ>      lists B1, B2 below.

IZ>   B) The rest of time "the state of input" is either in

IZ>      B1) the "principal list of targets" (for me, it would be Latin
IZ> 	 and Cyrillic), or in

IZ>      B2) "additional list of targets" (for me: Greek, flavors of math
IZ> 	 alphabets, Hebrew, and ASCII-like-plotting Unicode-symbols).

IZ>      The INTENT of input methods for B1 is to be active for long time
IZ>      (a sentence, or a paragraph).  Input methods for B2 would be
IZ>      active for a short time (for a word; to input a standalone char,
IZ>      it may be better to do as in (A)).

IZ>      From the point of view of coding it, one of the differences
IZ>      between B1 and B2 is what C-\ (or whatever) should do: when in B2
IZ>      list, it should return to the last active B1 method;  when in B1,
IZ>      it should cycle through the B1 list.

IZ>      In short, one would use C-\ for several purposes: cycling B1
IZ>      list, AND returning to B1 list from the B2 list.  To switch to
IZ>      one of B2 encodings, one would need extra bindings (e.g., on Fn
IZ>      keys); some modifications of these keys would be used to switch
IZ>      to one-char input (as in A).

IZ> 	[Hmm, I see that this mixing of two semantics of C-\ does not
IZ> 	 "work intuitively" when there are more than 2 targets in the
IZ> 	 B1 list.  Not surprising: I work with only two, so any
IZ> 	 solution I may come with is biased to this situation...]

IZ> ==========

IZ> But this is not all: what I discussed above are "targets" (think of
IZ> character repertoires); it must be also easy to switch particular
IZ> input methods for each target.  At some moment I know that "I want to
IZ> enter a greek word" - but this does not fix the input method; I may
IZ> want to experiment with a new one; or a collaborator may sit for a
IZ> minute at keyboard, and he may be more comfortable with a different
IZ> method than me.

IZ> The simplest implementation would be to allow an entry in the lists
IZ> above to be an array ["actual-input-method" "target"].  So it would be
IZ> the user's responsibility to write code which scans through all the
IZ> lists in question, and toggles/sets the input-method for one
IZ> particular target.

IZ> A cleaner implementation would be to have "symbolic names of targets"
IZ> in the lists for A/B1/B2 which are translated to an input method via
IZ> an associative array.

I think that 99.99% of people and 99.9% of Emacs users will look at this
hugely complicated explanation and shake their head.  I say this with
the experience of supporting users (Emacs and general) for many years;
also I mention it because I proposed a similarly complicated scheme to
make `next-error' multilevel years ago because it was clear in my mind,
but when I looked at the pages of explanation I could only wonder how I
expected anyone to think it's suitable for general consumption.

My point is that if you can't explain a feature in a single sentence,
it's probably not useful for the vast majority of users.  But let me see
if I can abstract what I understand: you want to have an additional
"quick toggle" list of input methods that doesn't interfere with the
regular input method toggle and only lasts for a syntactical unit.  So
for instance the quick toggle list

'((char I1 I2)
  (word I2 I3)
  (t I4 I5))

would allow you to switch to I1 or I2 for a single character, I2 or I3
for a single word, and I4 and I5 would stick permanently.  In addition
you want to say that I4 should make I2 preferrable to the others for the
quick toggle operation.  Is that incorrect?

Ted