2008/6/5 Kenichi Handa <handa@m17n.org>:
> In article <9d644d9b0806040914v46839e87v48afdff983c3980e@mail.gmail.com>, "Jihyun Cho" <jihyun.jo@gmail.com> 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...
>
> (1)
>
> ;; 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.
>
> (2)
>
> (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
> character"?
>
> The same for hangul2-input-method-moum,
> hangul3-input-method-cho, hangul3-input-method-jung,
> hangul3-input-method-jong.
>
> In hanja-util.el...
>
> (1)
>
> ;; List of current conversion status.
> (defvar hanja-conversions
>  nil)
>
> What format does it have?
>
> (2)
>
> (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
> handa@ni.aist.go.jp
>

Oh. I don't know that a char-table.
I modified a structure of hanja-table and adjusted comments.

"Maybe" in hangul2-input-method-jaum, hangul2-input-method-moum,
hangul3-input-method-cho, hangul3-input-method-jung,
hangul3-input-method-jong are deleted. It is checked by a calling
function. Therefore, always satisfies the conditions.

The diff file is too large. So I attached .el files.