XEmacs and APEL

[tomo ＠ m17n.org]

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

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

XEmacs なんかだと Jamie や Chuck は、多分、答えてくれない訳で、ある程
度長続きした software は属人的ではなくなってくるんだと思います。また、
多くの人に属人的に見なされてしまうと、寿命が短くなっちゃうんじゃないか
と思います。

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

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

こういうことの制度化に問題があったのかも知れませんね。思うにもっと WWW
page を活用すれば良いのではないかと思います。幸い、APEL の WWW 頁は
APEL の commiter なら誰でも cvs.m17n.org:/cvs/root の www/elisp/APEL
をいじることにより変更することができます（これはこれで運用の仕方をちゃ
んと決める必要があるでしょうけど）。そこで、議論の結果とか News とかを
どんどん WWW 頁に記録していってはどうでしょうか？

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

困る人がいれば文句言うでしょうし、積極的に合意形成に動くのが良いような
気がします。特に現状では。


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

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

;; かつての私の気持を判って頂けたでしょうか？:-)


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

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

良くいえば枯れているということで、その事自体は悪いことではないと思いま
す。また、FLIM/SEMI は LEMI 化とそれに伴う古い Emacsen の切捨てによっ
て、APEL 依存度が下がっていることも一因かも知れませんけども。

;; あと、もしかすると、末端利用者は OS の package を使うことが多くなっ
;; てきて、source がどういう構成をしているかがどうでも良くなってきてる
;; からかも知れませんが。かくいう私も Emacsen でも Debian 度が徐々に高
;; くなってきている今日この頃。

いずれにせよ、問題が起こったのなら活性化する良い機会じゃないでしょうか？


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

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

まあ、それは XEmacs community の問題だし、仮に採用されなくても作ったも
のは役に立つと思います。


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

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

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

山岡さん> 現実はそういうことなのですね。

;; まあ、なんというか、一部影響力の大きい人達の中に RMAIL しか使わない・
;; 使えない人がいたりして、また、そういう人はえてして NetNews なんか読
;; まなかったりする訳で、Gnus は存在しないも同然、ってことはないか。
;; (^_^; まあ、RMAIL は大事なんですよ。それに最速だし、任意の property
;; が記事に付けられるし、ある意味最強ですね。まあ、今の主流の MUA とだ
;; いぶ使い方が違うので、乗り換える気にはなかなかなれないですけども。


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

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

過去に何回か出したような気がしますが、とりあえず、FLIM/SEMI から
poe/emu 依存 code を除去し、coding standard に則ってない部分を修正する
のが原則で、まず、leim のような GNU Emacs のための付加 package の形で
release し、その後、GNU Emacs との統合を行うという道程を考えています。

;; 少なくとも lemi の release までは担当したいと思っています。

現状は 

	http://mousai.as.wakwak.ne.jp/projects/lemi/

にある LEMI Package for GNU Emacs 21 を見てください。この directory 構
成は、GNU Emacs の source tree の lisp/ 以下にかぶさる形を想定していま
すが、現状で使う場合、site-lisp/ で展開して make することを想定してい
ます。

RMAIL に関しては know bug があります（これは lemi 側ではなくて、GNU
Emacs 側の部分ですが）。


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

;; 著作権者と作者は一般には一致しないので、ChangeLog は根拠にならない
;; と思いますが。ただ、assignment が書けない人、disclaimer が必要でか
;; つもらえない人は GNU Emacs に収録される code は書けないことには変わ
;; りはないと思います。なお、lemi package の installer とか directory
;; 構成の変更は直接 GNU Emacs に関係しないので、問題ないことにしたいと
;; 思います。

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