*.elc compatibility between mule and nomule

[Shuhei KOBAYASHI]

Katsumi Yamaoka <yamaoka ＠ jpl.org> writes:
> Emacs と XEmacs の compatibility 確保は、今後もずっと必要でしょうね。
> でもそれは、かならずしも APEL が担う必要は無いし、実際に日本以外では
> ほとんどアテにされていません。

日本では Nemacs, Mule の 2/4, XEmacs-MULE (Emacs 18-20 と XEmacs 20/21)
を並行してサポートする必要があったからこそ APEL が必要だったという話で,

> ぼくも含めて、APEL をもっと積極的に使ってもらうための努力が足りなかっ
> たのだろうなあ、とは思います。結果論ですが。

今や最新の Emacs と XEmacs しか使われないから APEL は重要ではなくなった
ということです. (日本以外では最初からそうだった)

そもそも emu/ のうち poe 系に関しては, 最新の API を古い emacsen に提供
するという目的で作られているので(ちょっと嘘?), 古い emacsen を切り捨てた
ら poe は不要になるのが理想なのです. (実際には Emacs/XEmacs の問題が残る)

  上野さんは Riece 0.0.2 で push/pop をわざわざ廃止して APEL free を
  宣言しましたが, push/pop と butlast は Emacs 21 以降 lisp/subr.el
  に含まれている(だからこそ poe に追加された; ちょっと嘘)ものなので,
  Emacs 20.7 を切り捨てることでも APEL free にできたはずです.
  (あるいは APEL free が目的なら APEL の代わりに CL を使えばよかった)

poem/pces は MULE API, coding-system API のためのものですが, 差異を吸収
する他に抽象化という目的もあります.  as-binary 系関数で抑制すべき変数の
一覧を個々のパッケージで管理するより, 一箇所にまとめてしまった方がよい,
といったことです. poem/pces はこの目的ではまだ価値があるかもしれません.


Yuuichi Teranishi <teranisi ＠ gohome.org> writes:
> そういう、APEL をアテにしてないプログラムは
> xxx-xmas.el とか xxx-e21.el のようなのをアプリケーションごとに
> つくって吸収してるってことですかね。

APEL を使用している場合でも xxx-xmas.el や xxx-e21.el の中に APEL 依存
部を閉じ込めておくのが APEL のうまい使い方だったと思いますけど.

-- 
Shuhei KOBAYASHI