tlug: edict.el 0.9.7 for XEmacs >= 20.3 BETA release

["Stephen J. Turnbull" <turnbull@example.com>]

... will occur shortly.  If you're using XEmacs >= 20.5 (ie, a recent
beta version of XEmacs) packaged versions are now available at

   http://turnbull.sk.tsukuba.ac.jp/Tools/Xemacs/packages/edict/

The relevant file is edict-1.01-pkg.tar.gz.  The source package is
edict-1.01-src.tar.gz; this isn't going to be very useful unless
you're an XEmacs developer.  The other files in that directory may or
may not reflect the current state of the sources; depends on how
recently I've done `cvs update .'.  The files in that directory are
currently synched with the packages.  The dictionary itself is not
included: get that at ftp://ftp.cc.monash.edu.au/pub/nihongo.

The general release will probably happen not very long before the TLUG
meeting on Saturday.  (I'm hoping people will try it before then,
that's why I'm jumping the gun. ;-)  This is waiting on a way to install
on XEmacs 20.3 and 20.4 conveniently.  It does work with no source
changes (but they have to be re-byte-compiled).  If you know how to
deal with Lisp files (it's not that hard), you can just unpack the
edict-1.01-src.tar.gz and mv the *.el to where XEmacs can find them.
README.XEmacs has some hints.

FSF Emacs 20.x will probably get done sometime like within the month.
I don't even have a copy installed at the moment :-) so I can't guess
how much functionality may get lost, or how hard it will be to
restore.

If this package doesn't work for you and you want to keep trying with
the old sources:

>>>>> "Craig" == Craig Oda <craigoda@example.com> writes:

    Craig> From: "Andrew S. Howell" <andy@example.com>

    >> I tried your edict.el, but no luck. If I look up a English
    >> word, says it finds it, but the buffer just displays gomi. I
    >> guess its not setting the character set correctly.

Yup.  Mule often loses badly on that kind of thing.  You can try

(setq file-coding-system-alist
      (cons '("edict$" . euc-jp) file-coding-system-alist))

in .emacs, but this doesn't always work for me.  The package handles
this by generalizing the edict-dictionaries variable to use similar
notation, and taking Mule by the throat and forcing it to give you the 
requested coding system.

    Craig> This is my .emacs:

    Craig>  (setq kanji-flag t) (setq kanji-process-code 1)

I think this whole sequence is a NOP; the symbol MULE is not bound in
any XEmacs, never was and never will be.  As far as I know both XEmacs
and FSF Emacs now use the idiom (cond ((featurep 'mule) ...)).

    Craig>  (cond ((boundp 'NEMACS) (setq kanji-display-code 3))
    Craig> ((boundp 'MULE) (set-display-coding-system *euc-japan*)))

    Craig>  (cond ((boundp 'NEMACS) (setq kanji-fileio-code 3))
    Craig> ((boundp 'MULE) (set-default-file-coding-system
    Craig> *iso-2022-jp*)))

    Craig>  (cond ((boundp 'NEMACS) (setq kanji-input-code 3))
    Craig> ((boundp 'MULE) (set-keyboard-coding-system *euc-japan*)))

In modern Emacsen (>20.0, definitely XEmacs and possibly FSFmacs) the
set-*-coding-system functions are pretty much NOPs.  You can get badly
hosed with default-file-coding-system, too; Mule often thinks it's
smarter than you are.  The *code-sys* notation is no longer supported
on XEmacs, or possibly FSFmacs, as far as I know.

It's been so long I can't be sure about all that from memory, so:

Read the mans before using the above.

---------------------------------------------------------------
Next TLUG Meeting: 11 April Sat, Tokyo Station Yaesu gate 12:30
Featuring Tague Griffith of Netscape i18n talking on source code
---------------------------------------------------------------
a word from the sponsor:
TWICS - Japan's First Public-Access Internet System
www.twics.com  info@example.com  Tel:03-3351-5977  Fax:03-3353-6096