APEL-Diet: Road to APEL-Lite

[Shuhei KOBAYASHI]

Katsumi Yamaoka <yamaoka ＠ jpl.org> writes:
> 例えば Emacs 19.29 と 20.3 あたりの境界をしっかり確認して取捨選択
> を行なうのは、なかなかに大変な作業になるのではないかと思います。

あ, ここは 19.29 や 20.3 での完全な対応を求めるつもりはありません.
19.34 や 20.7 でちゃんと動けばいい.
19.29 や 20.3 を目安に切り捨てよう, です.

> 強いて言えば、Emacs 21.3 と XEmacs 21.4 以上だけを対象にした非常
> に軽い APEL だけをいきなり作る、

あれ, まだ 20.7 は切り捨てるわけにはいかないのでは?
;; セキュリティを口実に切り捨てたいけど.

[apel-ja: 00825]
> もういい加減に Gnus は Emacs 20 対応をやめて欲しいと思っています。
> もちろんそれは、あるメジャーなシステムで Emacs 21 が満足にその機
> 能を発揮できない問題を解消してからで良いのですけれど。

この「メジャーなシステム」が何なのかわかりませんが, Emacs 20/21 の
両方を維持しているディストリビューションはまだいくつかありますよね.
;; Debian, FreeBSD はそうらしい.


> それと、昨年の 4月以来なんだかわけがわからなくなっている XEmacs
> 21.5 への対応も、少なくともぼくには重い話。

はい. 私にも XEmacs のことはわかりません. (21.5 に限らず)
使っている人がなんとかしなければいけません.


> 古い Emacs への対応を順次削っていくだけだから、機械的な作業だけで
> 済んでしまうかというと、たぶんそんなことはなくて、

それでは (19.29 や 20.3 は目安に過ぎないという前提↑で)

> 強いて言えば、Emacs 21.3 と XEmacs 21.4 以上だけを対象にした非常
> に軽い APEL だけをいきなり作る、

こちらの方はずっと簡単なのですか?
いや, 実は簡単だと思っています. APEL 20(仮称)も同じくらい簡単だと.
;; Emacs 20.7 と 21.3 は APEL から見て大差はないはず.


> 00828 を拝見したときから思っていたのは、「誰がやるの?」でした。

> 作業は大変だけれども見返り、というか、みんなが喜ぶ新しい機能が
> 追加されるわけでもなく、放っておいたらこの話には誰も乗ってこな
> いかもしれない。

そして, 放っておいたら APEL には誰も手を出せなくなってしまう.
少なくとも私はまだなんとかなると思っています.


ところで,

> [apel-ja: 00705] はすでに一年近く前の話なんですねえ。

私がこの議論を続けなかったのは, それを考えるのは私の仕事ではなく,
APEL を利用しているパッケージの開発者の仕事だと思っているからです.

-- 
Shuhei KOBAYASHI