-*- indented-text -*- `Reload' if you are using WEB browser to see this. LKK 2000 technical note (Draft) ================================ 1. LKK DICTIONARY INTERFACE Here are a small SKK and LKK dictionaries storing equivalent entries: An example of SKK dictionary: =============================================== ;; okuri-ari できr /出来/[る/出来/]/[れ/出来/]/ かんがe /考/攷/[え/考/攷/]/ ;; okuri-nasi はどうほう /波動砲/ かんじ /漢字/感じ/幹事/ space /スペース/ てきとう /適当/ =============================================== An example of lkk dictionary (~/.lkk-dict(.el)): having the same entries: =============================================== ;; okuri-ari ("できr" ("出来") ("る" "出来") ("れ" "出来")) ("かんがe" ("考" "攷") ("え" "考" "攷")) ;; okuri-nasi ("はどうほう" "波動砲") ("かんじ" "漢字" "感じ" "幹事") ("space" "スペース") ("てきとう" "適当") =============================================== If an lkk dictionary is loaded in an emacs buffer, it is easily `read' into a variable. Try M-x eval-expression (setq junk-lkk-entry (read (current-buffer))) RET with placing cursor at the BOL of any entry above. Perhaps the most decent -- means fast and safe -- approach to LKK dictionary is to read it into a buffer, search yomi with straight search-forward(), then call `read' sort of function to read the hit entry into a variable. This method will be called `lkk-dict-buffer'. Dictionary update would be done with almost the same scheme in SKK, except that the entry is written on dict-buffer via prin1(). Further, LKK-DICTIONARY-FILE can be `read' into an big alist lkk-big-dict-head. Eg.: (setq lkk-big-dict-head (with-temp-buffer ; this works on emacs-20 only. (goto-char (point-min)) (save-excursion (insert "(") (save-excursion (insert ")")) ;; Insert file within the paren (insert-file-contents LKK-DICTIONARY-FILE)) (read (current-buffer)))) lkk dictionary of 390Kb - 15000 entries can be loaded into an alist in a scond or two (at worst) on Celeron 300A system. This method will be called `lkk-dict-alist'. Actually in the real `lkk-dict-alist' method, the entries is loaded into two alists for `okuri-ari' and `okuri-nasi'. Search can be done with straight assoc() -- strict match, or mapcar/while()+string-match() for loose match. Updating dictionary can be done in of various list operating schemes. Probably only two operations are needed: (1) (setq dict (delq (assoc (car new-entry)) dict)) (2) (setq dict (cons new-entry dict)) These are not so hard (slow) as you may expect (I hope). Drawback of `lkk-dic-alist' method is that it is not so fast and safe as `lkk-dict-buffer'. We can't use auto-save system of emacs to protect the dictionary -- must be dump the dictionary by explicit code. Further user can't peek or edit the dictionary on-the-fly without a certain interface (current lkk has no such interface yet). 2. LKK USER INTERFACE lkk user interface is rather lousy. For example, You can change the mode hitting / (lkk-start-/-convert) to `abbrev' mode even while ◇ is showing. The lousy implementation is half-intended, and some of them are due to my laziness as well, but I think I have to give the priority on user's (that's me) freedom rather than on integrity of the system. So, the lkk automaton may often go into wrong status and you may have to hit C-j (lkk-sit-back aka lkk-kakutei). At the same time it means that once C-j (lkk-sit-back aka lkk-kakutei) is hit the confusion will be remedied. Most of the tremendous number of user options as in today's SKK to customize the detail of kanji-conversion behaviour does not exist, and most of them will never been implemented. Too many options make the user as well as the developer unhappy. Here is a list of skk (10.49) variables and values on my daily emacs environment, and this may help to understand what happens on what timing of conversion in lkk: skk-allow-spaces-newlines-and-tabs t skk-auto-okuri-process t skk-auto-start-henkan t skk-convert-okurigana-into-katakana nil skk-delete-okuri-when-quit nil skk-egg-like-newline nil skk-henkan-okuri-strictly nil skk-henkan-strict-okuri-precedence nil skk-process-okuri-early nil because I write lkk codes so that I could feel comfortable. I don't know the meaning of most of the skk variables above, though. lkk is written for my personal use, and I am not interested in japanese linguistics / kanjistics at all. I am not interested whether lkk is /gramatically/linguistically/[kanjistically/politically]/ correct or not, but I just want to ease this pain in my daily writing. So don't persuade me that skk's such such facility should be also implemented in lkk too. Eg. I never use vi key bindings except in View-mode, so vip mode will never supported by my coding. X. Coding convension (Mostly for me, some are not obeyed, though) * Codes must be straight-ahead, simple, neat-and-clean, easily read, and maintained. I have to code lkk so that it can be read easily even by me a year older. * Don't write long functions anymore. If it is extremely long, say, two or three pages or more, there must be something wrong. Don't forget about dired-dd.el. * Never use read-char(), read-event(), or pushing things back into unread-command-* to code lkk engine. Keymap should be handled only by minor-mode-map-alist. * All functions communicate passing explicit args. Never rely on the existence of variable defined by let() within the callers except it is inevitable. * No autoload between the programs in the package to make things simple. * Kanji conversion functions should pass data only through list or string, and never use weird other sort of data structure. * Use only lisp packages provided by standard Emacs/Mule distribution, and do not rely on non-standard packages. * Never use the crap, custom.el. Who ever wants to `customize' something with that miserable USER interface ? * All add-on programs for lkk should be written as discrete elisp file which can be loaded via lkk-load-hook (or lkk-xxx-hook). * All the creation should be done all by myself at midnight, burning the midnight lamp -- actually its a light of CRT these days. Wed Mar 29 13:07:50 2000 Sat Apr 8 15:05:12 2000 s.n.