From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ilya Zakharevich Newsgroups: gmane.emacs.help Subject: Re: Swapping default input method: why so complicated? Date: Wed, 17 Nov 2010 09:57:33 +0000 (UTC) Organization: U.C. Berkeley Math. Department. Message-ID: References: <87zktabnjy.fsf@lifelogs.com> <87fwv170n4.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1291892039 3860 80.91.229.12 (9 Dec 2010 10:53:59 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 9 Dec 2010 10:53:59 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Dec 09 11:53:55 2010 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PQe8J-00020O-9R for geh-help-gnu-emacs@m.gmane.org; Thu, 09 Dec 2010 11:53:55 +0100 Original-Received: from localhost ([127.0.0.1]:49536 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQe8I-0001xD-7N for geh-help-gnu-emacs@m.gmane.org; Thu, 09 Dec 2010 05:53:54 -0500 Original-Path: usenet.stanford.edu!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 120 Injection-Date: Wed, 17 Nov 2010 09:57:33 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="LlLjF8LevGdIZWbTvv+SXA"; logging-data="25778"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/TAZWLccIGhML134rFQRfj" User-Agent: slrn/0.9.8.1pl1 (Linux) Cancel-Lock: sha1:/vHgqTwg0hRUd9rkv7jfiHKHiqc= Original-Xref: usenet.stanford.edu gnu.emacs.help:182485 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:76971 Archived-At: [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 wrote: > On Mon, 15 Nov 2010 20:52:43 +0000 (UTC) Ilya Zakharevich 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