XEmacs and APEL

[守岡 知彦 / MORIOKA Tomohiko]

>>>>> [apel-ja : No.00705] にて
>>>>> “小林さん”= Shuhei KOBAYASHI <shuhei ＠ aqua.ocn.ne.jp> さま曰く:

小林さん> tomo ＠ m17n.org (守岡 知彦 / MORIOKA Tomohiko) writes:
小林さん> > APEL-Lite とかやります？

小林さん> 以下のような要求がありますよね, きっと.

小林さん>   RMAIL や mh-e
小林さん>   emacs21 に LEMI のみを導入した状態で動作しなければならない.

小林さん>   Wanderlust
小林さん>   emacs21 に APEL-Lite + LEMI を導入したものと
小林さん>   emacs20 に APEL + FLIM + SEMI を導入したものを同様に扱いたい.

小林さん>   SKK
小林さん>   emacs21 に APEL-Lite を導入したものと
小林さん>   emacs20 に APEL を導入したものと
小林さん>   emacs19 に APEL を導入したものを同様に扱いたい.

そうですね。


小林さん> > どっちかっていうと、luna を FLIM から分離して、APEL から 
小林さん> > poe/emu 系を除いたものと合わせて、旧 tl を継承する汎用ライ
小林さん> > ブラリ・パッケージにまとめるというのが良いかなと時々思った
小林さん> > りします。

小林さん> module の名前が変化したりすると, 今まで APEL/FLIM/SEMI を使
小林さん> 用していたものの多くが書き換えを強いられると思うので,
小林さん> APEL-Lite を作るにしても v21以前(Emacs の方は Mule 4.0 以前
小林さん> でも構わない?)用の code を取り除く程度にしておいた方が良い気
小林さん> がします.
小林さん> 例えば pcustom.el なども以下のような形で残す必要があるかもしれません

小林さん> [2 pcustom.el for APEL-Lite <application/emacs-lisp (7bit)>]

poe や poem なども同様な感じで残した方が良いかも知れませんね。

その際、poe を require した時、pym や static 等の poe 実現上利用してい
る機能の提供を保証しないことにしてはどうかと思います。

あと、product や apel-ver はどうしますか？（この点、LEMI package でも
悩み中です）APEL も API と実装を分離することになる訳ですよね？また、こ
の場合、版番号というより実装水準みたいなのが欲しいですよね？（require
すれば判るようにすれば要らないかな？）


小林さん> 中島さんの luna への関心を考えたりすると, luna は APEL の方
小林さん> が良いかなと思うこともありますが.
小林さん> ;; そうすると, APEL-Lite と LEMI の両方に luna が入ることになる?

その場合、luna を Emacs 本体に入れてもらうように交渉するのが良いんでしょ
うね。まあ、現状の LEMI package には APEL 由来の module が幾つか残って
いるので、invisible 消さないと。pccl も消したいけど、mel-q-ccl がいじ
れない。というか、誰か、Quoted-Printable と Q-encoding を builtin で書
き直して欲しいなあ。

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