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

2003年 6月 18日 (水) 18:17:10 JST

守岡です。

御無沙汰しております。

今日の問題の少なからぬ部分の作った者としてはうまく反応できないのを心苦
しく思っております。また、APEL 10.5 の release にご尽力くださった皆様
ありがとうございます。

さて、

>>>>> In [apel-ja : No.00835] 
>>>>>	"寺" = teranisi ＠ gohome.org (Yuuichi Teranishi) wrote:

APEL-Lite? の対象ですが、

寺> At 16 Jun 2003 06:17:53 +0900,
寺> Shuhei KOBAYASHI wrote:
寺> > 
寺> > teranisi ＠ gohome.org (Yuuichi Teranishi) writes:
寺> > > ここでいう APEL-20 と APEL-Lite の違いが、
寺> > > (手元に [apel-ja: 00705] が残ってない、というのもあって)
寺> > > いまいち分かっていないのですが、
寺> > > APEL-20 が、Emacs 20.7-21.3 と XEmacs 21.4 以降
寺> > > (Mule/Non-Mule/UTF-2000?)  を対象とした Emacs-21 API 相当の提
寺> > > 供を目的とするとすると、APEL-20 と APEL-Lite には、ほとんど差
寺> > > がないってことはないでしょうか？

insert-file-contents-literally が存在し（Mule 機能を持つ時 binary 入力
として動く）character indexing な Emacs/XEmacs を対象とするのが良いの
ではないかと思います。

GNU Emacs の場合、事実上 GNU Emacs 20.7 以降をサポートするので良いと思
います。

寺> > ;; XEmacs 21.4 以降ですか? XEmacs 21.1 はつい最近まで stable 扱
寺> > ;; いでは?

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

寺> ;; …とすると、XEmacs 21.1 以降の Mule/Non-Mule/UTF-2000? が対象、
寺> ;; ですかね?
寺> ;; (XEmacs はコードネームが世界旅行だった頃は
寺> ;;  楽しく追っかけしてましたが、その後の事情にはどうも疎いです…)

;; 余談ですが、XEmacs UTF-2000 は XEmacs CHISE に改称しました。最近は、
;; 姉妹品の Ruby/CHISE とか Perl/CHISE もあります。libchise というのも
;; 細々とやってます。

寺> たしかに、luna は APEL にあるといいですね。

寺> FLIM は PORTABLE な LEMI の一モジュールに相当するという位置づけに
寺> なる(?)なら、mcharset も FLIM に移動したらいいような気がしますが、
寺> どうなんでしょう。

私もこれに賛成です。

XEmacs CHISE や Unicode-Emacs など Mule charset に依存しない新たな 
Mule 実装にうまく対応するには mcharset や eword-encode を大改造する必
要があると思うのですが、APEL にあるとやりにくいと思います。

また、MIME charset によって Mule charset/coding-system の差異を吸収す
るという目的は APEL-Lite では不要になると思います。

FLIM だけの問題ならさっさと FLIM 1.15? を release してしまえば良いだけ
だと思うのですがいかがでしょうか？

>>>>> In [apel-ja : No.00840] 
>>>>>	"小林さん" = Shuhei KOBAYASHI <shuhei ＠ aqua.ocn.ne.jp> wrote:
小林さん> teranisi ＠ gohome.org (Yuuichi Teranishi) writes:

小林さん> > 従来の APEL アプリケーションは変更しなくて済むことが前提、
小林さん> > (API は変更しない) ということでしょうか。

小林さん> これは大前提, と私は思っていましたが.

小林さん> > Old Emacsen 対応をなくすことで、
小林さん> > * すべての内容が不要となるファイルは削除する
小林さん> > * 一部でも内容が残るファイルは削除しない
小林さん> > という風にするということでしょうか。

小林さん> そのようなことを考えていました.

ABI というのか、*.elc の互換性に関する必要な条件を明確化できたら良いと
思います。例えば、XEmacs without Mule と XEmacs with Mule で *.elc が
共有できるとか。

不必要な macro は使わず、macro を使う場合は必ず ABI というか展開される
表現を明確化するのが良いと思います。

この作業のために現在と ABI 非互換になるのが問題ですが、エイヤッとやっ
てしまうのが良いのではないかと思うのですがいかがでしょうか？

;; luna を APEL に含める場合、luna に関しても同様の作業をやるのが望ま
;; しいと思います。

小林さん> それから追加の規則.

小林さん>     (EMU 系ではない) APEL 系の
	      alist,calist,path-util,filename,install
小林さん>     その他には手を付けない.    

小林さん> これはもともと version 依存性が低いことと, old emacsen と共
小林さん> 有しているsite-lisp/ に install される可能性があるためです.

LEMI で emacs-lisp/ に置いているものから broken.el と static.el を除い
たものに対応しますね。tm 時代の tl/ 相当というか。

ところで、broken.el と static.el をここに含めるのはいかがでしょうか。

小林さん> それと個人的には

小林さん>     emu.el 関連(emu-mule,richtext,tinyrich)には手を付けず
小林さん>     放置したい.  (invisible.el もここに含まれるかな?)

小林さん> というのがあります. これらは obsolete 扱いだったと思いますので. 

思い切って削りたい気もするのですが、放置が賢明かも知れませんね。

emu.el 廃止宣言をしたい気もするけど。

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