Muß es sein ?

 
 
 
Lousy version 0
---------------

Lousy is a sort of skk clone.  Its facility is very limited for my
personal use, so:

;; Normal people do not use lkk.  Use skk instead. 

but some of those (e)lisp geeks may like it.

The name `Lousy' is just a sort of developer code, and it may be
changed in future, when I think it's right to have more decent name,
or if I was convinced that enough feature had been implemented, and
it's not just lousy anymore.

`l' of `lkk' may stand for various concept on the authour's whim.
Even `lkk' prefix in file/variable/function/command name may be
changed in future versions.

Lousy is written on emacs-20.5 and mule-2.3@19.34.  Perhaps it works
on plain mule-2.3 (emacs-19.28) too (I hope). You don't need apel, or
patched custom.el to run Lousy.

The current codes won't work on Nemacs/Demacs/emacs-18.xx.  See the
trace of an incomplete porting old lkk.el into Demacs included in the
./experimental/dos/ directory.



New feature
-----------

Lousy is a sort of SKK subset, and basic key bindings are almost the
same as that of SKK, but several new features are implemented.

  1. New (physical) dictionary (file) format

     lkk took sexp as the expression of an skk dictionary record, so
     the *physical* dictionary format is different from ~/.skk-jisyo.

     However, the lkk dictionary format is the exactly same as that of
     skk *in logic*.  An lkk dictionary can contain exactly the same
     information as an skk dictionary does.  Only the difference is
     that a record of the lkk dictionary file is a pure lisp sexp (like
     skkdic.el for kkc.el -- it ain't an skk dict anymore, though).
     Apparently lkk dictionary format is out of the skk spec, but I
     think this is still an skk dictionary.

     Upside: Any string can be stored in data fields -- (concat "\057")
             sort of trick is not needed anymore.  A record can be
             directly eval'ed by read() function family.

     Downside: The physical dictionary file is bulky in size (about 30%
               larger than equivalent .skk-jisyo), current lkk can read
               compressed dictionary via jka-compr (or sort of) if it
               is available.

      See file 00TECH-NOTE for more detailed info on the dictionary
      file format.

  2. The lkk dictionary can be accessed through two methods: 

     lkk-dict-buffer, and
     lkk-dict-alist

     These methods can be selected by setting variable `lkk-dict-method'
     to one of these (alternative is lkk-skk-dict-buffer, but this method
     is incomplete yet).

     The former is the default, and the same as of skk: the dictionary
     is read into an emacs buffer, and updated there as file image.
     This is perhaps a fastest and safest method.

     In the latter method, the dictionary is loaded up into two big
     alists `lkk-big-dict' and `lkk-big-dict-okuri'.  There may not be
     many practical merits of this method except that programmer can
     feel that he is really in a lisp system, but not so slow as you
     may expect.

     Standard .lkk-dict can't be loaded directly by functions like
     load, load-file etc.  If such loading method is preferred, go over
     to dump-lkk.el, and see what it can do.


  3. lkk-full-auto mode (aka lkk-elettronico)

     Automatically completes hiragana yomi of kanji, or any string in
     the buffer incrementally on entering new hiragana character.  You
     can toggle the mode by C-TAB (lkk-toggle-full-auto).  Perhaps
     most of non-X terminal can't input C-TAB `character', so binding
     to other key sequence may be convenient in non-X environment.

     The completion starts on hiragana yomi exceeding
     lkk-full-auto-hchar-threshold which defaults 1 -- meaning the
     completion starts when you hit 2nd hiragana).

     Current lkk just completes things by dabbrev or loose search on
     lkk dictionary.  I am planning to write a more adaptive sort of
     completion program.

     At least in mule-2.3@emacs-19.34, and emacs-20.[2-6], the
     standard dabbrev.el is damaged and can't be used for dabbrev'ing
     Japanese text.  You have to install dabbrev.el included in plain
     mule-2.3 (19.28 based), or M-? (dabbrev-expand) or the lkk-elettronico
     won't work as expected.

     I guess the lkk-full-auto might be a biggest controversy
     against `skk-concept' -- if such `concept' ever exists.  It seems
     to me that most of skk users hate this `automatic' sort of stuff.

     This feature is turned off by default.
     

  4. [double-M-SPC] sort of virtual keymap can be used for SPC and TAB,
     or any other key (with an appropriate setup).

     I implemented this facility because there's not so many keys are
     left for us in emacs.

     I am using [double-M-SPC] to fireup lkk, and double-/triple-C-SPC for
     dabbrev expanding, or save-buffer().

     Downside of this facility is that a single key `root' part of the
     key sequence corresponding to the defined multiple-click key
     event should inevitably be delayed.  So, it may not be good idea
     to bind plain keyclicks such as [double-SPC, or TAB] (without C-,
     M- modifier) to a multiple click command.
        
     Turned off by default.  See docstring of `lkk-inhibit-multiple-keyclick'.
     The `lkk-multiple-click-threshold' variable defaults 180 ms --
     that is the delay should be elapsed before a single-keyclick status
     is fixed -- which may be too small for some users.



Installation
------------

1. Byte-compile and copying *.el, *.elc

  Example1 (manually):

  1) C-x d RET here in this source directory.
  2) Hit %m \.el$ RET (dired-mark-files-regexp used here to mark all *.el).
  3) Hit L on (dired-do-load used here).
     If error is reported, hit L again. Normally it will scceed for the
     second trial.
  4) Hit B y (dired-do-byte-compile used here).

and copy lkk.el* to your emacs's load-path (re-mark and  C (dired-do-copy)
may be easy).

  Example2 (using make, you may have to be root):

  mule-2.3:
        make emacs=/usr/bin/mule elispdir=/usr/local/lib/mule/site-lisp install

  emacs-20.x, mule-2.3@19.34 etc.:
        make emacs=/usr/local/bin/emacs elispdir=/usr/local/share/emacs/site-lisp

  Install into your private elispdir:

        make emacs=youremacs elispdir=~/elisp


2. Create dictionary file

Current Lousy has no facility to hatch an empty dictionary automatically.

If lkk styled dictionary is preferred, 

        make install-dict

This installs ~/.lkk-dict converted from your current ~/.skk-jisyo.
`make install-dict' overwrites ~/.lkk-dict without warning.  Watch out if
you issue the second `make install-dict'.

An *SKK* styled dictionary will be directly loaded in future version,
but this facility is incomplete yet (you can try it out some of it, though.
See what current lkk-skk-dichead.el can do).


3. ~/.emacs setup

Minimum setup is not so difficult.  Include this sort of codes in ~/.emacs:

        (define-key global-map "\C-xJ" 'lkk-mode)
        ;; Otherwise, if you don't use skk anymore:
        ;;      -- I think (null (good idea)) yet --
        ;; (define-key global-map "\C-xj" 'lkk-mode)
        ;; (define-key global-map "\C-xC-j" 'lkk-mode)
        (autoload 'lkk-mode "lkk" nil t)

or additionally:

        (setq lkk-load-hook (lambda ()
                              ;; (load "~/.lkkrc")    ; if you have such file
                              (require 'lkk-isearch)  ; simple isearch support
                              (require 'lkk-skklib)   ; for `Classic' j-today
                              (require 'lkk-skkserv)  ; if skkserv needed
                              (require 'lkk-jchunk)   ; for M-H,D,F,B,T etc.
                              ;; (require 'lkk-bogo)  ; for developer
                              ;; (require 'lkk-debug) ; for developer
                              ))

You can use lkk-load-hook, lkk-mode-hook etc.


4. Fire up Lousy

Hit C-xJ (or other key you've bound to lkk-mode).  Most of key basic
bindings in lkk-mode are almost the same as those in skk.

Hit C-TAB (or M-x lkk-toggle-full-auto on console), try some input Japanese
characters or kanji conversion, and see what happens.  Perhaps it's better
to try out in a not-empty buffer.

If you want to use [double-M-SPC] to turn on/off lkk-mode, add these

  (progn
    ;; Must setq your reall (single-)M-SPC command here, or you'll lose.
    (setq lkk-fireup-old-command 'just-one-space)
    (global-set-key [?\M- ] 'lkk-fireup))

  (autoload 'lkk-fireup "lkk" nil t)
  (add-hook
   'lkk-mclick-load-hook
   (lambda ()
     ;; My preferred binding to fireup lkk. lkk-toggle-lkk-mode is called
     ;; by lkk-fireup().  Complicated ?
     (define-key lkk-multiple-click-map [double-M-SPC] 'lkk-toggle-lkk-mode)
     ))

in your ~/.emacs.  Perhaps the lkk setup section of my ~/.emacs is included
in the package as _emacs, which may include other knowhow to use lkk-mclicdk.el.



Document, Customizing...
------------------------

(C-u) M-x lkk-apropos RET, sweep the buffer with mouse pointer and
click [mouse-2] on a highlighted keyword of your interest.
M-x lkk-apropos-command RET, and M-x lkk-apropos-variable RET
may be used to apropos interactive commands and variable only if
corresponding functions are implemented in your emacs.

Further bang [mouse-2] on `lkk' in the raised `*Help*' buffer (if it
had `Defined in' section) shows the genuine entity of the whole
document (this may work only in emacs-20.xx).

I will never write a texi for this, sorry.

To customize a variable, try out setting preferred value with

 (setq lkk-xxxx yyyy)

using ESC ESC/ESC-:/M-: (eval-expression) or lisp-interaction-mode
enabled *scratch* buffer.  Do not modify variables having "internal
use" in their docstring, for they are built on-the-fly.

I will never support the M-x customize crap, sorry.

Lot of facilities may be still lacked, and some of them will never be
implemented ever.  See road map below, or file TODO-NOT-TODO.



Current status
--------------

A lot of codes for kanji `conversion' (is this a right word of `henkan' ?)
engine is lacked, and there are a lot of unfound bugs, but I can manage
to live only with lkk these days.

On lkk-sit-back (aka lkk-kakutei), the dictionary is updated almost as
you expect.  New `okuri-ari' data can be generated out of an existing
record.

There is no skk-auto-okuri sort of conversion -- the conversion
without specifying okurigana position.  The auto-okuri was always a
headache in skk history.  I will never implement this to save my time
and the size of this package, because the skk logical dictionary
format lacks grammatical info at all and it is impossible to achieve
decent hit rate.  Instead, you can register a word for daily use
including okurigana part as a non-okuri record as we did in old days,
which is the most simple and reliable way to convert without
specifying okurigana position.

Experimental `the recursive registering', and data-purge facility are
working.  The skk-like reucursive registering might be removed if any
better dictionary edit mode is conceived in future.  I guess it is
more comfortable than editing something in a narrow minibuffer,
especially for the geeks.

skkserv interface functions and j-today (old skk-today command) are
not my codes from scratch, but borrowed from the `Classic' skk5.30.
The skk-derived codes are protected with GPL/GPL2.

Currently the data received from skkserv service is thrown away and
never used for updating dictionary (you can force to register a word
from server by the recursive registration, though).  The
add-data-from-server facility might not be implemented in future
versions as well.  My dictionary is fat enough because it is derived
from skk dictionary which has been brewed over a decade.  Instead I
may write a code to dump the records come from the server to an
auxiliary dictionary file.

Dictionary is not overwritten on ~/.lkk-dict (default value of
`lkk-dict'), but written onto ~/.lkk-dict.today (default value of
`lkk-dict-dump-file') on dictionary dump.

If overwrite dump is preferred you have to set these two variables to
point the same file.

I don't trust this beast so much yet, and I don't think I need to
update ~/.lkk-dict everyday. I am executing

#!/bin/ksh
cp -vp ~/.lkk-dict.today ~/.lkk-dict

sort of stuff in manual operation.  I know it doesn't apply to anybody --
it means just my dictionary is matured enough.

Further lkk does not dump dictionary on kill-emacs by default.  To
enable automatic dump on kill-emacs, you should setup
lkk-suicide-hook.

Otherwise setq variable `lkk-dump-dict-automatic' to
non-nil, which enables calling `lkk-dump-dict-on-idle' function
with an interval stored in lkk-dump-dict-timer (default 180sec).
The `lkk-dump-dict-on-idle' does not execute dump if emacs is not
idling more than `lkk-dump-dict-idle-timer' value (default 4sec).
You can use M-x lkk-dump-dict-with-timer RET to enable the auto-save
mode.



Road map
-------

TODO
        * Conversion by raw kanji code input.
        * lkk-dict-edit-mode
        * Write my version of server search, or j-today from scratch.
        * Reverse conversion into skk dictionary (looks easy).

NOT-TODO

        * NOT, full-featured lkk-isearch.el (C-s/C-r C-j instead).
        * Never support overwrite mode, vip mode (definitely), and
          picture mode (maybe).

	* skk-auto-okuri-process compatible -- if you really need the
	word, register it as non-okuri thing as in early skk Classics.


Sat Feb 19 16:05:37 2000
Fri Mar  3 11:17:44 2000
Wed Mar  8 01:09:38 2000
Mon Mar 13 11:20:37 2000
Mon Mar 20 19:07:11 2000
Sat Apr  8 14:53:35 2000
Fri Apr 21 20:37:26 2000
s.n.

With my biggest respecto to Masahiko Sato,
who has written SKK from SCRATCH.

In the way nobody ever thought of,
he deviced the skk dictionary format, and,
in the way nobody can mimic,
he chopped the record with j-compute-henkan-vectors().