XEmacs and APEL

[Katsumi Yamaoka]

>>>>> In [apel-ja : No.00691] 守岡知彦さん wrote:

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

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

守岡さん> ところで、上記の山岡さんの文を見ると、あたかもどこか別の人が
守岡さん> （ないしは場所で）APEL の policy に関する意志決定が行われる
守岡さん> ように感じられますが、もし本当にそう思われているとしたらそれ
守岡さん> はどうかと思います。

ある意味でそう思っているところもあります。たぶんぼくは上記のよう
な疑義を出したときに、そういう仕様で作られたプログラムの作者の人
は何らかの方針に従って設計したはずだから、それに関する反応が作者
ご本人か関係者の方から教えていただける、と期待していたのでしょう。

ぼく自身は、何かの重要な決定に際して投票と結果の発表などをその都
度行なうような手間は必要無いと考えている一方で、ちょっとした話の
中で重要な決定が行なわれてしまったのを見のがしているかもしれない
という不安も持っています。別に自己弁護するつもりはないのですが、
自分が知らないうちに何かが合意されたことになって決まっているかも
しれないし、そのときは重要性がわからなくて知らん顔していたかもし
れません。

で、これほど重要な仕様なのだから、何かの決まりがあったんじゃない
か、と。

でもよく考えると、その仕様の重要性に気が付いたのは、実はぼくが最
初かもしれないのですね。おそらくそういう場合にぼくが行なうべきだっ
たのは、改めて合意の確認を行なう、もしその仕様に問題があるならば
代案を出して合意を求める、ということでした。あるいは過去の記事を
取り寄せ直して関連項目を探ることだったかもしれません。反省します。

守岡さん> APEL の policy は APEL mailing lists での議論に基づいて現
守岡さん> maintainer の皆様が決めるべきことだと思います。この際、私の
守岡さん> 若気の至りというか誤った判断、あるいは、現在の環境に合わない
守岡さん> 部分は改めて頂けたら良いなあと思います。

というわけで、基本的にはみんなの合意を尊重する、または尊重したい、
というのがぼくの意志です。ですが、このところあまりに反応が無いの
で外堀 (XEmacs) に石を投げてみたのでした。:-p

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

APEL のコードを書くことも APEL を使わないで何とかすることも、と
もに脳内麻薬の生成を刺激します。:)
ただ、APEL の用途の中で大きな比重を占めている FLIM や SEMI、はて
は Wanderlust や T-gnus などで使う上で問題が無い、というだけ理由
でこのコミュニティの現在の不活性状態が続いているのだとしたら、先
行きは暗いでしょう。ぼくだって他人のことは言えなくて、ひところの
ような意欲が今では無くなってしまいました。

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

;; ぼくも emacs-w3m というソフトウェアでいろいろ経験しました。

[...]

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

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

うーむ、できれば。ですが、現在の XEmacs の maintainers は、そう
いうことに極めて消極的であるように見えます。完璧に仕上げたコード
を提出しても、無視されてしまう公算が大であろうと踏んでいます。

山岡> SEMI や FLIM が公に汎用 MIME パッケージになる日は来るのでしょう
山岡> か?

守岡さん> 「公に」ということが何を意味するのかは判らないんですが、

ずいぶん失礼なことを書いてしまいました。^^;; ごめんなさい。

守岡さん> GNU Emacs 21 収録ということであれば、

はい、その意味で書いていました。

守岡さん> 既にライセンス上の問題は解決しているので、作業する人がいれば
守岡さん> 可能だと思います。そして、私は実際にある程度作業しましたし、
守岡さん> その一部（RMAIL の MIME 化の準備）は GNU Emacs 21.1 以降に既
守岡さん> に反映されています。ただ、Gnus を FLIM/SEMI で置き換えるとい
守岡さん> うのは既に現実的ではないと思っています。

なるほど。Gnus についてはもちろんおっしゃるとおりだと思います。
XEmacs の人たちが「汎用 MIME パッケージが無い」と書いていたのを
見て、漠然と広範な MUA の存在というものを想像してしまいましたが、

守岡さん> GNU Emacs 21 にFLIM/SEMI を収録するとしたら、それは RMAIL
守岡さん> （と mh-e） のMIME 化を目的としたものになるでしょう。

現実はそういうことなのですね。

;; そういう意味では Wanderlust の存在はかなり貴重なんですねえ。

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

守岡さんの具体的な計画案 (出来れば下請け指示書みたいなもの :-)
を出していただければ、協力者はたくさん現れるのではないでしょうか。
たぶん Emacs 18 からはじまって、すべての版の Emacs を持っている
ような必要は無いでしょう。それは従来の APEL を見直す目を養うため
の貴重なきっかけになるであろうし、逆に守岡さんへの提案もできるか
もしれません。

;; でも最終的に FSF への paper work が問題になってしまうんでしょ
;; うか。最近は ChangeLog に「From 誰」と書いて author は正規の
;; 人、というのがかなり許されてしまっているようではありますが。

[...]

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

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

そうですね。また機会を改めて出してみようと思います。

[...]

守岡さん> APEL-Lite とかやります？

それでも良いのですが、例えば broken や static は APEL を差し置い
て単独で FSF Emacs に編入したら、とも考えます。

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

で、もう一つ luna という汎用パッケージも独立させる。というふうに
APEL を APEL という一固まりではなくて、それぞれが幸せな嫁入りを
するのもありかなあ、と。いや、言ってみているだけで、現実にはいろ
んな作業が必要でしょうけれども。
-- 
Katsumi Yamaoka <yamaoka ＠ jpl.org>