From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Hin-Tak Leung Newsgroups: gmane.emacs.devel Subject: Re: a few MULE criticisms Date: Thu, 15 May 2003 20:49:14 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <3EC3EF3A.8070902@yahoo.co.uk> References: <3EC2A0FA.1040007@yahoo.co.uk> <3EC3098C.2000809@yahoo.co.uk> <87of24439m.fsf@tleepslib.sk.tsukuba.ac.jp> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1053028126 16747 80.91.224.249 (15 May 2003 19:48:46 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 15 May 2003 19:48:46 +0000 (UTC) Cc: Kenichi Handa Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu May 15 21:48:42 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19GOef-00042v-00 for ; Thu, 15 May 2003 21:44:41 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19GOmg-0002ei-00 for ; Thu, 15 May 2003 21:52:58 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 19GOfC-00022P-03 for emacs-devel@quimby.gnus.org; Thu, 15 May 2003 15:45:14 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 19GOea-0001oY-00 for emacs-devel@gnu.org; Thu, 15 May 2003 15:44:36 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 19GOeW-0001fu-00 for emacs-devel@gnu.org; Thu, 15 May 2003 15:44:33 -0400 Original-Received: from smtp017.mail.yahoo.com ([216.136.174.114]) by monty-python.gnu.org with smtp (Exim 4.10.13) id 19GOe9-0001G1-00 for emacs-devel@gnu.org; Thu, 15 May 2003 15:44:09 -0400 Original-Received: from unknown (HELO yahoo.co.uk) (hintak?leung@62.253.153.130 with plain) by smtp.mail.vip.sc5.yahoo.com with SMTP; 15 May 2003 19:43:58 -0000 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en, en-us Original-To: "Stephen J. Turnbull" In-Reply-To: <87of24439m.fsf@tleepslib.sk.tsukuba.ac.jp> Original-cc: emacs-devel@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:13907 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:13907 Stephen J. Turnbull wrote: >>>>>>"Hin-Tak" == Hin-Tak Leung writes: > > > Hin-Tak> The more prefered methods are either > Hin-Tak> pronounciation+intonation (which is probably "input 4 > Hin-Tak> keystrokes, scroll a list of 20") > > Quail already offers at least one of these. > > Hin-Tak> There are a few methods which matches by shape (i.e. how > > Quail offers a couple of these, too. Yes, I am aware of that. (I think the emacs documentation mentioned that many of the Chinese related input method tables were copied from cxterm, which was the most popular [the only?] way of doing Chinese at that time in history <1994). But having just the input tables is not quite enough... > Hin-Tak> a character is written), but as I explained, the right- > Hin-Tak> hand-side of a chinese character is usually the more > Hin-Tak> distinct side but the right half is usually written last; > > I suppose it wouldn't help much for input methods to simply reverse > the order. Then you'd still need wildcards for the (less frequent, > but not so rare) case where the left side is more distinctive, right? Indeed no. A majority(?I think) has a left-right division where the right part is more distinctive, but as you suggest, a sizable part is the reverse; and there are ones which have a top-bottom division (for which again, the bottom part I believe is often the more distinctive half); and still others which don't have any obvious internal divisions. The more popular methods tend to be ones in which the choices are narrowed down quickly and evenly as one more keystroke is added to the sequence. > Hin-Tak> Also, it is not uncommon to switch between input methods > Hin-Tak> frequently to arrive at different characters, say 5-10 > Hin-Tak> times within a medium-size sentence. Binding the switch > Hin-Tak> to function keys to enable fast-switching is quite > Hin-Tak> necessary to type at any reasonable speed. (And Japanese > Hin-Tak> users probably don't switch input methods as frequently > Hin-Tak> as Chinese users would do...) > > Note that in certain applications, such as programming code that > produces Japanese strings (eg, XML or TeX), the input method may be > toggled on and off many times in a medium sized "sentence". But it > sounds like you mean several different methods, not (for example) > switching from geometric to phonetic and back several times. So you'd > need several keybindings, instead of just one for the toggle. Yes, for Japanese usage, the predominant way is some variant of phonetic (by pronounciation) mappings, with a quick toggle to ASCII when these are needed. I personally use ChangJie (a shape-based mapping) most of the time, but I do use a few others, one of the pronounciation-based ones, and if I am really desparate, even the one for English-translation. (i.e. typing "apple" and expecting the chinese character for that fruit!). > Also it sounds like which methods are preferred varies a lot by user. > Is the number of commonly used methods small enough (say 5 or 6) that > all can be bound to function keys at once? Or are there enough that > each user should be able to configure his own preferences to reduce > the number of hot-keys required? Indeed. I have touched upon this before. e.g. particularly the pronounciation-based ones, due to the size of the Chinese-speaking region (e.g. a fictious non-stop consumer commercial flight touching Beijing-Taiwan-Hong Kong-Singapore would take 8-12 hours), people pronounce the same character differently according to where they come from - that's already 4 *popular* pronounciation-based system :-). and we haven't started on the shape-based ones yet... > In fact the server-based input methods for Japanese usually do provide > function key access to methods like a special list of symbols, input > via JIS code, user dictionary, etc. Yes, to much of my envy ... population-wise, the Chinese is so much bigger, and yet in the issue of computer over-all localization the Japanese is so much more advanced. The civil war and the political turmoils within China until the late 80's has done much harm to the general education and technology advances (in addition to other social/economical problems).