help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Swapping default input method: why so complicated?


From: Ilya Zakharevich
Subject: Re: Swapping default input method: why so complicated?
Date: Wed, 08 Dec 2010 15:36:27 -0000
User-agent: slrn/0.9.8.1pl1 (Linux)

  [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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]