[Top][All Lists]

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

Re: [PATCH] Improving hangul input module

From: Kenichi Handa
Subject: Re: [PATCH] Improving hangul input module
Date: Thu, 05 Jun 2008 16:24:27 +0900
User-agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/23.0.60 (i686-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

In article <address@hidden>, "Jihyun Cho" <address@hidden> writes:

> I have adjusted comments and docstring.
> My English is not good.
> If you can not be understood, let me know it.

Thank you I've just committed your change with some
improvement.  Please check if my understanding is correct
with the latest code.

But there are a few places I still don't understand.

In hangul.el...


;; Current input character buffer. Store separated hangul character.
;; First and second index of vector stored "Choseong".
;; Third and forth index of vector stored "Jungseong".
;; Fifth and sixth index of vector stored "Jongseong".
(defvar hangul-queue
  (make-vector 6 0))

I don't understand 2nd to 4th lines.


(defsubst hangul2-input-method-jaum (char)
  "Store hangul jamo indice CHAR in `hangul-queue'.
Maybe, it is a Hangul 2-Bulsik jaum.
This function processes a Hangul 2-Bulsik jaum.
Unless the function inserts CHAR to current input queue,
commit current character and then start next character.
The Hangul 2-Bulsik is composed of `jaum' and `moum'."

"Maybe" is strange.  If CHAR is not a "Hangul 2-Bulsik
jaum", what it will be.

In what condition, it doesn't insert CHAR to the queue.

What does "start next character" mean?  Where is the "next

The same for hangul2-input-method-moum,
hangul3-input-method-cho, hangul3-input-method-jung,

In hanja-util.el...


;; List of current conversion status.
(defvar hanja-conversions

What format does it have?


(defun hanja-filter (condp lst)
  "Return list.
It contains true elements to evaluate CONDP with each element from LST."

I don't understand it.

By the way, why do you use a hash-table for hanja-table?
Isn't a char-table more efficient?  And, the value is now
"(CHAR) or (CHAR . STRING)", but most of elements are
(CHAR).  I think it's a waste of cons cells.  How about
changing the format to "CHAR or (CHAR . STRING)"?  It seems
easy to handle the changed format in hangul-to-hanja-char.

Kenichi Handa

reply via email to

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