APEL-Diet: Road to APEL-Lite (Re: *.elc compatibility between mule and nomule)

[守岡知彦 / MORIOKA Tomohiko]

守岡です。

>>>>> In [apel-ja : No.00853] 
>>>>>	"小林さん" = Shuhei KOBAYASHI <shuhei ＠ aqua.ocn.ne.jp> wrote:

小林さん> <http://www1.kaiho.mlit.go.jp/KOHO/reki/kyuu9700.htm> によると
小林さん> 7 月は 5, 11, 17, 23 が大安のようですね.

;; そういえば、７月は確か tiny-mime 10 周年のような気がするので、なん
;; か記念行事しますかね。


小林さん> tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡知彦 / MORIOKA
	  Tomohiko) writes:
小林さん> > insert-file-contents-literally が存在し（Mule 機能を持つ時
小林さん> > binary 入力として動く）character indexing な Emacs/XEmacs 
小林さん> > を対象とするのが良いのではないかと思います。

小林さん> [apel-ja: 00849] の "literal-test-file" を使う判定がまさにこ
小林さん> れですよね?

そうですね。


小林さん> | * この byte-compile 時に行なうことを意図した判定は間もなく
	      削除予定.
小林さん> |   (この部分は Emacs 20.7 では不要だけれど XEmacs ではどう
小林さん> |   だろうか?)

小林さん> > XEmacs に関しては具体的にどの時点になるかは良く判らないの
小林さん> > ですが、insert-file-contents-literally が binary 入力とし
小林さん> > て動き、CCLの bugが直った時点からのサポートにするのが楽な
小林さん> > 気がしますが、それって 21.4になるんでしたっけ？

小林さん> この部分に CCL の bug も関係するのですか?

いえ、insert-file-contents-literally の問題と CCL の問題はパラレルです。


小林さん> XEmacs 21.1 で pces-20.elc を作成して中身を確認できる人はい
小林さん> ませんか?  と思ったのですが, 普段使っていない環境に XEmacs
小林さん> 21.1.14 があったので自分で確かめてみました.

小林さん> XEmacs 21.1.14 は "literal-test-file" を用いた判定では

小林さん>     (defalias 'insert-file-contents-as-binary
小林さん>               'insert-file-contents-literally)

小林さん> の方が使われているようです.
小林さん> CCL の方は CCL_EOF_BLOCK が実行されない問題が報告されました.
小林さん> こちらは XEmacs 21.4 では問題がないようです. やはり 21.1 も
小林さん> 切り捨て?
小林さん> ;; APEL-Diet の基準は Mule 機能が安定しているかどうかにしま
小林さん> ;; しょうか?

うーん、CCL はこの先も変わるような気もするので、基準に使わない方が良い
かなという気もして来ました。とはいえ、21.1 ってどの程度使われてるんで
しょうね？利用者から見ると多分 21.4 に乗り換えるのにほとんど問題ないと
思うんですが。


小林さん> > LEMI で emacs-lisp/ に置いているものから broken.el と 
小林さん> > static.el を除いたものに対応しますね。tm 時代の tl/ 相当と
小林さん> > いうか。
小林さん> > 
小林さん> > ところで、broken.el と static.el をここに含めるのはいかが
小林さん> > でしょうか。

小林さん> broken.el と static.el を LEMI に含めたのが私には疑問なのですが...

broken.el は確か mel-q-ccl.el のためだけだったと思います。私が
mel-q-ccl.el を理解していないために削り切れなかったのです。

static.el は GNU Emacs と XEmacs の切替え code で必要だったような気が
してたんですが、今見ると、mime-view.el における
buffer-file-coding-system と file-coding-system の使い分けと、
mime-image.el における XEmacs 用 code と、pgg-parse.el における CCL 用
code だけで、どれも削れそうな感じですね。

まあ、broken.el や static.el 自身は portable なので、emacs-lisp/ 扱い
で良いかなとも思ったんですが、これらに頼るのは問題ではあるので微妙です。

小林さん> 現在 broken.el と static.el が EMU-ELS に含まれ, 結果として 
小林さん> emu/ に置かれるのは最初にこれらを byte-compile する必要があ
小林さん> るためです.

なるほど。

小林さん>     (defun compile-apel ()
小林さん>       (config-apel)
小林さん>       ;; Compile emu modules first.
小林さん>       (compile-elisp-modules emu-modules-to-compile	".")
小林さん>       (compile-elisp-modules apel-modules		"."))

小林さん> > > それと個人的には
小林さん> > >     emu.el 関連(emu-mule,richtext,tinyrich)には手を付けず
小林さん> > >     放置したい.  (invisible.el もここに含まれるかな?)
小林さん> > > というのがあります. これらは obsolete 扱いだったと思いますので. 
小林さん> > 思い切って削りたい気もするのですが、放置が賢明かも知れませ
小林さん> > んね。

小林さん> これは APEL-Diet のプロセスにおいては現状維持ということです.

了解です。

小林さん> ;; APEL の枠組を変える議論が盛り上がるのは半年は先という読み
小林さん> ;; は甘かった?

;; まあ、実装・検証の機運が盛り上がるかは別問題なので、半年は先という
;; のは現実的なのでは。
;; むしろ、枝を早めに作って作業・実験しやすいようにしとくのが良いかな
;; という気も。

-- 
┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━
││ ─ │  ─  ／    ─   ┼─     ┬                ─   ─┼ ┬┴─
┼┼─┼|〓━─┼ 守岡 知彦 (MORIOKA Tomohiko) <tomo ＠ m17n.org> ─ ─┬
┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━