Re: OKURI-NASI

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> I currently synch SKK-JISYO.L against upstream once a month [but there
> has been no changes to this file since December last year].  It should
> be easy to include a step recreating the generated file and committing
> that too, if that's what we want.

It is extra work, though, and any work that can be avoided is nice.  😀

Doing some very light profiling here, a lot of the time is taken up by
skkdic-get-entry, which is just lookup-nested-alist.  My guess is that
if somebody took a look ja-dic-cnv.el, this algorithm could be made
substantially more efficient by using other data structures than an
extremely long nested alist.

But I have really no idea what it's really doing, so it's a bit daunting
to start poking at the code.  And my guess is that's why nobody else
has, either, since not many people currently hacking at Emacs has the
required domain knowledge.

;;; Commentary:

;; SKK is a Japanese input method running on Mule created by Masahiko
;; Sato <masahiko@sato.riec.tohoku.ac.jp>.  Here we provide utilities
;; to handle a dictionary distributed with SKK so that a different
;; input method (e.g. quail-japanese) can utilize the dictionary.

;; The format of SKK dictionary is quite simple.  Each line has the
;; form "KANASTRING /CONV1/CONV2/.../" which means KANASTRING (仮名文
;; 字列) can be converted to one of CONVi.  CONVi is a Kanji (漢字)
;; and Kana (仮名) mixed string.
;;
;; KANASTRING may have a trailing ASCII letter for Okurigana (送り仮名)
;; information.  For instance, the trailing letter `k' means that one
;; of the following Okurigana is allowed: かきくけこ.  So, in that
;; case, the string "KANASTRINGく" can be converted to one of "CONV1く",
;; CONV2く, ...

Well, that doesn't sound all that complicated, eh?

(I'm hoping to entice somebody to see this as a fun challenge.  😀)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no