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