all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Hin-Tak Leung <hintak_leung@yahoo.co.uk>
Cc: emacs-devel@gnu.org
Subject: Re: a few MULE criticisms
Date: Thu, 15 May 2003 04:29:16 +0100	[thread overview]
Message-ID: <3EC3098C.2000809@yahoo.co.uk> (raw)
In-Reply-To: <200305150118.KAA04234@etlken.m17n.org>

Kenichi Handa wrote:
> At first, as far as I know, cemacs.el is a small program
> written by <simpson@math.psu.edu> that does just these
> things:
>   o make emacs 19 use standard-display-8bit
>   o rebind forward-char, delete-char, etc to functions that
>     pay attention to 8-bit chars.
> And, it works only in tty mode under a chinese terminal,
> e.g. cxterm.

That's correct.

<a lot of C-x RET, etc snipped>

Is there a central organized repository for these tips/etc
associated with leim? e.g. how to create a new leim file?
They aren't in the obvious places (i.e. the info files
that came with emacs).

>>(1) Associations: the ability to let the user choose the next possible
>>associated characters.
> 
> [...]
> 
>>for many years. This would most certainly require extending MULE with
>>the ability of loading distionaries of commonly used phrases in
>>various languages. And will make the leim package a lot bigger.
> 
> 
> I think this should be implemented by extending abbrev-mode
> so that it can associate an abbreviation with multiple
> words/phrases (is it possible already?)

At this point it is probably good to switch to Japanese examples...
What I meant is the ability to anticipate something like:

(a) if I input "Handa" (two characters in Japanese Kanji),
and because it is a common surname, the system somehow asks
whether I want to follow it with "san" (two characters in Japanese
gana - the honourable suffix, similar to the "Mr" prefix in English),
or the 2nd half of the name of famous historical figures
with that surname.

(b) Many of the usage of verbs in Japanese consists of one
or two Kanji characters, e.g. "carry", "bring", followed
by verb modifiers meaning "to", "did not", "forbidden to",
"please do", "please do not", etc which could be 5-6
characters long. The list of characters commonly used for
verbs is quite well defined (a few hundreds? still small by
comparison to the whole character set of a few thousands),
and the list of commonly used verb modifiers is even shorter
(maybe about 10?). Any of those in the 1st list is likely
to be followed by those in the 2nd list.

(c) "Ken" (one Japanese character) is often followed by
one specific character to form the phrase for "health".
(in addition to "Ken-ichi", a rather common first name),
and "ichi" (one character) is often followed by "ban"
(one character) to form "ichi-ban" (meaning "the best").

These might sound very demanding and critical - but association
can dramatically improve the speed of typing
by a factor of two or three... and association has been available
with some CJK input mechanism on either unix or other platforms
for years.

And it is not just about the speed of typing - sometimes
one just can't remember the precise keystrokes corresponding
to a certain lesser-used character, so one would rely on
association from more frequently-used ones (and delete
the more frequently-used one afterwards).

> When you type TAB while you are using an input method, Emacs
> shows the full list.  But, the method used in cxterm is not
> implemented, it's not easy.

I have figured that out. However a match by beginning and ending ("a*b")
or by ending ("*b") is quite important for Chinese inputs. TAB
(match by the beginning portion "a*") probably works alright
for Japanese, because a native Japanese speaker most probably
know how the character is pronounced (or at least know the
first one or two syllables of the phrase). But many of the
Chinese input methods (other than the Pinyi method,
"by pronounciation") function by character shapes, and the
distinctive/memorable part is often the right-hand side of
the character. In other words, the ending of the keystroke
sequence (or the 2nd half of the sequence), because the keystroke
sequence is usually coded according to how native writer
writes the different portion of a character (top-left,
bottom-left, top-right, bottom-right).

  parent reply	other threads:[~2003-05-15  3:29 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-14 20:03 a few MULE criticisms, cemacs, & current emacs segfaults by changes in GNU ld Hin-Tak Leung
2003-05-14 20:55 ` Jason Rumney
2003-05-14 22:05   ` a few MULE criticisms Hin-Tak Leung
2003-05-14 21:55 ` a few MULE criticisms, cemacs, & current emacs segfaults by changes in GNU ld Stefan Monnier
2003-05-15  2:03   ` a few MULE criticisms Hin-Tak Leung
2003-05-15  6:55     ` Jason Rumney
2003-05-15  1:18 ` a few MULE criticisms, cemacs, & current emacs segfaults by changes in GNU ld Kenichi Handa
2003-05-15  1:39   ` Luc Teirlinck
2003-05-15  3:29   ` Hin-Tak Leung [this message]
2003-05-15 10:06     ` a few MULE criticisms Hin-Tak Leung
2003-05-15 15:51       ` Stephen J. Turnbull
2003-05-15 19:49         ` Hin-Tak Leung
2003-05-15 21:29           ` Kevin Rodgers
2003-05-16  7:09           ` Stephen J. Turnbull
2003-05-16 11:43             ` Hin-Tak Leung
2003-05-17  7:32               ` Stephen J. Turnbull
2003-05-17 19:40                 ` Hin-Tak Leung
2003-05-15  7:03 ` a few MULE criticisms, cemacs, & current emacs segfaults by changes in GNU ld Stephen J. Turnbull
  -- strict thread matches above, loose matches on Subject: below --
2003-05-18  5:23 a few MULE criticisms Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3EC3098C.2000809@yahoo.co.uk \
    --to=hintak_leung@yahoo.co.uk \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.