SKK is still simple, but expandable

[Mikio Nakajima]

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

To: skk ＠ sato.kuis.kyoto-u.ac.jp
Cc: tm Mailing List <tm-ja ＠ chamonix.jaist.ac.jp>

したのですが、tm-ja にはじかれてしまったので、apel-ja ＠ m17n.org のみ再
投稿です。

リプライ下さる方はお手数ですが、
  Cc: skk ＠ sato.kuis.kyoto-u.ac.jp
して下さい。

At Tue, 02 Nov 1999 22:59:45 +0900,
Masahiko Sato wrote:
 
> このミニマムを still simple と考えるかどうかですが，私は十分に複雑な構
> 成だと感じています．とくに，APEL のファイルを別のところから入手しない
> といけないのは面倒だと思います．
> 
> version 7 までは，skk.el と 辞書ファイルのふたつのファイルだけですんで
> いたのですから．
> 
> 私は，今でもそうですが，skk.el をバイトコンパイルしないでつかっていま
> す．したがって，辞書をバッファに読み込んで使うとすれば，ファイルをふた
> つすきなところに置いて，.emacs でファイルのありかを指定するだけでイン
> ストールが終了していました．
> (中略)
> ミニマムの構成を単純にすることが必要だと思います．ミニマムな構成を私も
> 理解できていなかったのですから，切り離してよいファイルがどれかがわから
> ないわけです．skk.el が必要なことは誰でもわかるでしょうから，それ以外
> はなくてもすむというのがミニマムだと考えます．
> (中略)
> たとえば，version 10 は現在の構成で完成させて，version 11 以降で，昔の
> ような simple な skk が核の部分にあって，その上に多様な機能から追加し
> たい機能を選べるようにできればと考えています．

  力武さんがおっしゃった発言内容は、機能がシンプルであるべきだ、という
意図が「第一義」だと理解しています (それだけだとは言っていません)。こ
のこととファイル構成がシンプルであるべきだ、という議論はごっちゃにする
と議論がややこしいので、ファイル構成がシンプルであるべき、という点を中
心にぼくの意見を述べます。


  SKK 10.x で APEL を採用した当時は APEL も今の姿からは程遠く (と言う
と守岡さんに失礼なのかもしれませんが)、Emacs 19.28 における add-hook
の LOCAL argument も、custom 関係も実装されていない状態でした。SKK で
add-hook の LOCAL argument を利用するからと言うことで小林さんが相当ご
苦労されてこれを実装されました。custom 関係もまたしかり。小林さんのみ
ならず、山岡さんにもずい分助けられました。

例えば、サポートする Emacsen をかなり狭い範囲に絞ることで SKK をまた元
のように APEL から切り離すことができますが、そういったことは皆さん望ま
ないはずです。ユーザーの立場からはできるだけ広範囲な Emacsen をサポー
トして欲しい、というリクエストはあるはずです。

SKK で必要な範囲だけ APEL に頼らずに SKK でやれば良いじゃないか、とい
う考え方もあります。では、はてさて、そのサポートが SKK ML だけで効果的
にやれるか、という問題に対しては少なくともぼくは懐疑的です。当 ML には
それ程広範囲な Emacsen を利用され、かつそれ程アクティブな方は現状いらっ
しゃらないからです。繰り返しになりますがその意味ではずい分と tm-ja ML
に助けられてきたと実感しています。


SKK の構成をミニマイズして欲しい、できれば APEL に依存してもらわないで
もらいたい、でも Emacsen はできるだけ広範囲にサポートして欲しい、とい
うのはぼくに言わせてもられば、それはないものねだりのように聞えます。そ
ういうミニマイズのサポートが常にできる人がメインテナーに就任されるので
あれば異議は留めませんが、結構な負担になり、かつその負担は、XEmacs と
FSFmacs が異なる道を歩む以上、益々増えること必至だと思います。


APEL の中心構成は、ぼくが希望しているよりはもっとずっとミニマイズして
ゆこう、という方向にあります。必要なパッケージが必要な分だけ require
できるように、という開発の方針が決められています。APEL の中身を知らな
い人が見たら色々ファイルが沢山あって、Emacs に余分な仕事を強いているの
ではないかと思われるかもしれませんが、そのファイル構成に反して、内容は
理想的なミニマムの状態に近いものと確信しております。

skk.el の本体の中に利用頻度が低いオプションがあってそれを切り離せない
か、という機能的な側面から見た検討はするつもりです。しかし、今から
APEL を切り離す方向は少なくともぼくには考えられません。

  反論があればお聞かせ願いたいと存じます。

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