XEmacs and APEL

[守岡 知彦 / MORIOKA Tomohiko]

>>>>> In [apel-ja : No.00688] 
>>>>>	"山岡さん" = Katsumi Yamaoka <yamaoka ＠ jpl.org> wrote:

山岡さん> ははは誤解でしたか。でもぼくがあまり整理されていない頭の中で
山岡さん> 漠然と思っていたのは、APEL はぼくが誤解していたような姿勢で
山岡さん> はマズいのではないかということでした。しかし、例えば

山岡さん>   *-maybe が compile-time に既に存在しているものに対して何も
山岡さん>   しないのは良いのだろうか?

山岡さん> のようなぼくの発言に対してまったくご意見がいただけなかったの
山岡さん> で、今さら言うまでもなく現状追認が正しい APEL の姿勢なのだろ
山岡さん> う、はたまた APEL はすでに時代遅れになっていて誰もあえて問題
山岡さん> 視していないのだと解釈し、それでもなお、ときどき APEL が原因
山岡さん> になっている障害が取りざたされるたびに、だんだん APEL の存在
山岡さん> が鬱陶しくなってきたのでした。

APEL の maintainer を降りて以来（というか、その前から）反応が悪くて申
し訳ないです。現 maintainer の皆様には感謝しております。ところで、上記
の山岡さんの文を見ると、あたかもどこか別の人が（ないしは場所で）APEL 
の policy に関する意志決定が行われるように感じられますが、もし本当にそ
う思われているとしたらそれはどうかと思います。APEL の policy は APEL
mailing lists での議論に基づいて現 maintainer の皆様が決めるべきことだ
と思います。この際、私の若気の至りというか誤った判断、あるいは、現在の
環境に合わない部分は改めて頂けたら良いなあと思います。

もちろん、現 maintainer の皆様には maintainer をやめる自由がありますし、
APEL を捨てるのもひとつの選択でしょう。また、必要がなければ APEL を使
わない方が良いと思いますし（簡単に APEL の利用・除去の支援をする tool
ってのがあると良いかも知れないですね）。

;; 個人的には、細々と、時々思い出したようにやっている lemi (FLIM/SEMI 
;; の GNU Emacs への統合および RMAIL の MIME 化作業；
;; http://mousai.as.wakwak.ne.jp/projects/lemi/) で、APEL というか
;; POE/emu の問題点を実感しました。


山岡さん>> 1. XEmacs with Mule で byte-compile されているので、XEmacs
山岡さん>>    without Mule で使われた場合に齟齬を生じる。

小林さん> これは compile-time evaluation の使い方がまずいのが主な原因
小林さん> です.  XEmacs の with Mule と without Mule の判定を
小林さん> compile-time に行なってはいけません. と, 少し前に APEL のど
小林さん> こかに書いておいたはずです. ちなみに環境の判定(Meadow かどう
小林さん> かなど)も compile-time に行なってはいけません.

山岡さん> 小林さんの方針はまったく正しいと思います。

私もそう思います。


山岡さん>> 2. 古い std11.el と std11-parse.el が含まれていて、現在は
山岡さん>> FLIM に移設かつ一本化された std11.el と互換性が無い。

小林さん> これは XEmacs Package の tm が必要としているのかな?
小林さん> そうであればそちらに移すのが良いでしょうね.

山岡さん> なるほど、そうですね。tm-std11.el、prefix も tm-std11- にして。

できれば、XEmacs Package の tm を FLIM/SEMI に、RMAIL を GNU Emacs 21
に基づいたもので置き換えるのが良いと思います。かつて、Martin に作業を
してもらってたんですが、逃げられてしまいました。(;_;)


山岡さん> ところで、MIME 機能では Gnus が世界中のパワーを結集して独走
山岡さん> してしまい、VM も追い付いたようですが、SEMI や FLIM が公に汎
山岡さん> 用 MIMEパッケージになる日は来るのでしょうか?  そしてそれが実
山岡さん> 現した暁には APEL という名前は無くなって、一部の機能だけが 
山岡さん> SEMI や FLIM に編入されるのですよね?  もしそうだとすれば 
山岡さん> XEmacs の APEL packageも tm に入れてしまい (と言うか大昔の形
山岡さん> 態に戻してしまい)、新しい汎用 MIME パッケージに対応していな
山岡さん> い旧式のソフトウェアだけが tmを使う、というのも合理的ではな
山岡さん> いかと思います。

「公に」ということが何を意味するのかは判らないんですが、GNU Emacs 21
収録ということであれば、既にライセンス上の問題は解決しているので、作業
する人がいれば可能だと思います。そして、私は実際にある程度作業しました
し、その一部（RMAIL の MIME 化の準備）は GNU Emacs 21.1 以降に既に反映
されています。ただ、Gnus を FLIM/SEMI で置き換えるというのは既に現実的
ではないと思っています。GNU Emacs 21 に FLIM/SEMI を収録するとしたら、
それは RMAIL（と mh-e） の MIME 化を目的としたものになるでしょう。

なお、私はここのところあんまり時間が取れなくて、lemi および RMAIL の
MIME 化作業は止まっています。poe/emu 除去作業は大体終っていると思うの
ですが、残った部分をどうするかとか、APEL と併用する場合の問題とかが残っ
ています。できれば皆様の御助力を頂きたいです。とりあえず、この件では私
は恐らく大部分の方が興味がなくてなおかつ必要不可欠でかつ結構面倒な
RMAIL の書き換え作業を優先して行っております。そういう訳で、それ以外の
部分を主導してくださる方がいらっしゃったら大変うれしいです。また、現実
的には、そうした人的リソースがなければ GNU Emacs への収録は実現しない
と思います。


山岡さん>> またつい最近では、mcs-xm.elc において defsubst で定義されて
山岡さん>> いる関数 encode-mime-charset-string が、XEmacs without Mule 
山岡さん>> でbyte-compile した liece などの他のプログラムに埋め込まれ
山岡さん>> てしまうために害を及ぼす問題の対策が行なわれました。

小林さん> この問題は function inlining が主な原因です. たとえ 
小林さん> load-time に定義を変えるようにしても defsubst している限りは
小林さん> 問題が起こります.

山岡さん> そうですね。そしてぼくの不正確な印象としては、-maybe や 
山岡さん> brokenを使っている部分も含めて compile-time に決まってしまう
山岡さん> 内容が多く、それらが APEL の方針を代表しているように見えたの
山岡さん> でした。

よしんばそれが「APEL の方針」としても、それが問題なら変えた方が良いと
思います。


山岡さん>> 将来の XEmacs には三つの選択肢があるのではないだろうか:

山岡さん>> 1. APEL をそれぞれの版の XEmacs に含める。

山岡さん>> 2. APEL を XEmacs パッケージから外す。APEL が必要なユーザは、
山岡さん>>    自分でインストールしなければならない。

山岡さん>> 3. 可搬性を持たせるために、性能を犠牲にしてすべての APEL の
山岡さん>>    モジュールを書き直す。

小林さん> 1. は既に否定されていて,

山岡さん> これは意図通り。:-p

小林さん> 2. も APEL に依存する XEmacs Packages がいくつもあるので非現
小林さん> 実的なので,

山岡さん> ぼくは実はこれを押したかったのですが、XEmacs の連中の反応は
山岡さん> 意外に情けないものでした。良い機会だから目の上のこぶになって
山岡さん> いるAPEL を排斥するために関連パッケージを直そう、という動き
山岡さん> にはなりそうもありません。

小林さん> 3. でしょうね. 性能がそれほど犠牲になるかは私も疑問に思いま
小林さん> すけどね;-p

そう思います。

山岡さん> これにもあまり食い付いてくれませんでしたね。ぼくの理想はこれ
山岡さん> ですが、反面「お前やれ」って言われたらちょっと困るのが現状で
山岡さん> す。でも次の機会があったら「俺たちが全部やるから受け入れろ。
山岡さん> 最後まで面倒見る。ともかくブツができるまで四の五の言うな。」
山岡さん> と言ってみたいです (これは誰かの助けを借りないと英訳できそう
山岡さん> もないけど ^^;;)。

lemi では 2. と 3. の中間みたいな感じになっていると思います。lemi には
poe/emu は概ねないのですが、XEmacs 用の package の場合（というか完全な
APEL を実現する場合）、poem とかは (provide 'poem) だけみたいなのを基
本に、必要な機能を追加するという感じで良いんじゃないかと思います。技術
的にはそんなに難しい話ではないと思います。


小林さん> ただ, compile-time check を load-time check に書き換えるのが
小林さん> 難しい場合もあります.

小林さん>     (defun example ()
小林さん>       (static-if foo A B)
小林さん>       (static-if bar C D)
小林さん>       (static-if baz E F))

小林さん> を load-time check に書き直すと 8 通りの関数定義を用意するこ
小林さん> とになり, このようなものを書き換えるのは現実的ではないと思い
小林さん> ます.

山岡さん> そうですね。特にそういうものが Emacs 18 以上のすべてが対象だ
山岡さん> と非常に大変なわけですが、Gnus の先端がときどき脱線するよう
山岡さん> に Emacs 21 以上とか XEmacs 21.4 以上を対象にすると話はかな
山岡さん> り変わってくると思うのです。そういうバージョンの Emacsen だ
山岡さん> けを使うユーザは大きな勢力になっており、最近の Emacsen 専用
山岡さん> の APEL というのもあっても良い時代になったかもしれません。あ
山岡さん> るいは、わざわざ APEL という独立したパッケージに集約するまで
山岡さん> もない内容しか残らないかもしれません。

APEL-Lite とかやります？

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

小林さん> また, APEL には実際にファイルを作成して入出力関数の挙動を調
小林さん> べている部分がありますが, これも load-time check にするのは
小林さん> 問題があるでしょう.

小林さん> ということで,

小林さん>   3'. XEmacs Packages 用の APEL を別に作成する.
小林さん>       個々の compile-time check は個別対応.

小林さん> という方針でやってみるのが APEL を全体的に書き直すよりはまし
小林さん> かな, と.

私もそう思います。

-- 
守岡 知彦 (MORIOKA Tomohiko) <tomo ＠ kanji.zinbun.kyoto-u.ac.jp>