SKK is still simple, but expandable

[Mikio Nakajima]

  こんばんは、中島＠あさひねっとです。

＃ tm-ja ＠ chamonix.jaist.ac.jp は apel-ja と emacs-semi-ja に分割された
＃ ので、ポストしても配送されないはずです。残念ながら今の apel-ja は
＃ member しか投稿できないようになっているのですが、守岡さんにお願いし
＃ ましたので、すぐにでも member 以外の方も投稿できるようになるはずで
＃ す。

At Wed, 03 Nov 1999 23:31:54 +0900,
Masahiko Sato wrote:
 
> 中島さんのご意見は，私が予期していた範囲のもので，おっしゃることは理解
> しているつもりです．

  当方は複数の方から色々言われていささか混乱しておりますので、少し整理
したいと存じます。

1. SKK の機能は simple であるべきだ、というご指摘。

(1)元々が simple だったのだからそれ以上の機能は不要だ、というご指摘に
   対しては、simple な核に、個人のニーズに応じて追加機能をプラスできる
   構成になっております、というのがぼくの回答です。

   個人のニーズに応じた機能を足してゆける、という点では、9.6 及び 10.x
   は 8.6 以前の SKK よりも向上しているはずです。

(2)まだまだ核を simplify できるはずだ、というご意見があれば、simplify
   できるようにしようと努力するつもりでおります。

(3)自分は幹のところだけが欲しい、という要望があるのであれば、そういう
   ニーズがあれば独自に実現されてはいかがですか、というのがぼくの回答
   です。


2. ファイル構成が複雑だというご指摘。

(1)SKK に機能を加えてゆこうとする輩がいる限り、特殊機能を追加するファ
   イルは増える一方です。その意味ではファイル構成は単純化できません。
   ファイル構成の単純化を図るために全てを skk.el につっこむという旧来
   の方式を取れないことはありませんが、機能を simplify して欲しい、と
   いう要求と根本的に矛盾しており、この方式を取れる可能性はないと考え
   ております。

(2)APEL に依存している限り、またある程度の Emacsen をサポートする限り、
   ファイル構成がある程度複雑化することは否めません。


3. APEL に関するご指摘。

(1)APEL に依存するのが不安だ、というご指摘に対しては、中、長期的に見て、
   独自にやる方がもっと quality 的には劣ると思います、というのがぼくの
   回答です。

(2)APEL の全部に依存するわけじゃないので、必要なところだけ取って欲しい、
   というご指摘に対しては、必要であればできますが、インストーラーの改
   善を含めて作業が必要です、というのがぼくの回答です。


> そのためには APEL のコードをおおいに利用させてもらうのがよいと考えてい
>              !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> ます．決して，APEL に依存してもらわないでもらいたいということではあり
> ません．ただ，末端のユーザが APEL のソースを skk と別途入手しないとい
> けないのは不便だと考えます．それに，松下さんも言われたように，APEL の
> ソースの一部に skk が依存しているのですから，全部は不要なわけです．

  この部分を読むと佐藤先生は、APEL の必要なファイルだけを SKK に同封す
るのが良いとお考えのようですが、

At Tue, 02 Nov 1999 22:26:34 +0900,
Masahiko Sato wrote:
 
> From: Kenji Rikitake <kenji ＠ k2r.org>
> Subject: SKK is simple and I hope it would be
> Date: Sun, 31 Oct 1999 13:15:26 +0900 (JST)
> 
> > 個人的にはSKKには基本的に9.6m以上の機能は期待していません。EmacsもMule以
> > 上の機能は一切期待していないので、手元の環境は極めて古い状態のままです。
> > 私個人は、より機能を「減らした」SKKのvariantをまとめられないかと思ってい
> > たりします。まあこれは手間暇かかる作業なので、個人的な優先度は低いです。
> > 
> > SKKは余計なことをしないのが最大の利点だと思っています。機能の拡張は必要
> > だと思う人がいる限り大いに結構ですが、そうでない人達には簡単に切り離して
> > 捨てることができるような構造ができるといいですね。
> 
> 同感です．skk-develop で同趣旨の提案をしようと思っていたところですが，
> 大変そうなので躊躇していました．
> 
> 重要なご指摘だと思いますので，実現できるように努力したいと思います．

この部分を読むと機能的に限定して欲しい、と読めてしまい、一体どちらが本
意なのかぼくには分りかねます。


  皆さんの発言の主旨の第一義を捕えるならば、

力武さんは「simple な機能があればそれで十分なので、機能的に幹と枝に分
けてディストリビューションを構成して欲しい」

土屋先生は「ファイル構成が単純であることが望ましい」

松下さんは「APELに依存することが不安だ」

そして、佐藤先生のご主旨は、ぼくから見れば基本的に土屋先生の主旨に乗り
ながら、力武さんの主旨の一部である「simple な機能があればそれで十分」
という本音が見え隠れしているように思えます。

何だかこういう皆さんのリクエストを上手く調和させ SKK の将来を担う自信
がなくなってきました。時期 SKK の候補となるものをとりあえずぼくが一番
近い距離で管理していることが問題の発端のような気がします。

で、本来的には気が進まないのですが、SKK 10.x を Ring server Openlab に
託そうと準備中です。CVS server の使い方も知らないし、ぼく自身勉強しな
がらの開設になると思うので、しばらく時間が必要でしょうが、そこでぼく自
身が本来的に自分がベストだと思う道を進みながら、その variant ができる
ことを拒まないようしようと思います。Openlab が開設されたらアナウンスい
たしますので、有志はそれぞれ cvs をお使いになって variant の開発などを
ご自由にされて下さい。

そんなに色々な variant に SKK を名告られては迷惑だ、本家、佐藤家が許さ
ん、ということであれば名称の変更も検討いたします。

-- 
中島幹夫 <minakaji ＠ osaka.email.ne.jp>
　　　　 <minakaji ＠ pdx.ne.jp> (急ぎのときはこちらへ)
http://www.asahi-net.or.jp/~gy2m-nkjm/