emacs-devel
[Top][All Lists]
Advanced

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

Re: a few MULE criticisms


From: Hin-Tak Leung
Subject: Re: a few MULE criticisms
Date: Thu, 15 May 2003 20:49:14 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312

Stephen J. Turnbull wrote:
"Hin-Tak" == Hin-Tak Leung <address@hidden> 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).






reply via email to

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