Namazu-devel-ja(旧)

[Tadamasa Teranishi <yw3t-trns@xxxxxxxxxxxxxxx>]

寺西です。

Yukio USUDA wrote:
> 
> 互換性は維持しておくもののPerl5.8のメリット（当面は速度？）
> を元に移行を促し（メリットがみつからないと積極的に移行しない
> ですよね）そのうえで将来の移行状況を視野に入れてindexをUTF-8
> 化できる準備を整える。といった感じでしょうか？

たぶん Perl5.8 対応版と indexのutf-8化版 は分けた方が良いと
思います。
 
> indexのutf-8化は内部処理eucのままでもできるかもしれないですが
> 内部処理utf-8化しないと多言語対応にむかわないでしょうし、
> 内部utf-8化まではPerl5.8のみにする理由は弱いと思います。

いえ、nkf, lv 等をインストールする必要がなくなるだけで、
十分メリットだと思います。
少なくともエンドユーザは、インストールしなければならない
ソフトウェアが減って楽になりますから。

> 段階を踏んでやるのがよいのか一度にやってしまうのがよいのか
> 難しいですね。

indexのutf-8化というのが非常に大変だと思いますので、Perl5.8 対応版
とは別ブランチで良いのではないかと思います。
分けたからといって、二度手間ということもないかと思います。
 
> ただ、コード変換はどこが責任をもってするのか？、変換前コード名の
> 特定はどこでするのか？というところを整理したほうがよいと思ってい
> ます。

この辺りの仕様は決めないといけないですね。
 
> 現状はコード変換は原則 mknmz内、場合によってfilterモジュール内
> となっています。これはfilterモジュールが
> 　・モジュールに渡される前のコード変換
> 　・モジュールから渡した後のコード変換
> の必要の有無をpre_codeconv,post_codeconvとして1or0で事前に登録
> しているためだと思います。
...
> Ｃ．コード変換はフィルターモジュール内で責任をもって完了させる。
> 　　post_codeconvは参照しない。
...
> また、codeconv.plでのラッパーを充実させて使いやすくして文書化し
> てしまえばＣがよい。（一太郎のファイルが１つのバイナリファイル

フィルタプログラムをいろいろ修正した経験からすると、C が良いと
思います。 
-- 
=====================================================================
寺西 忠勝(TADAMASA TERANISHI)  yw3t-trns@xxxxxxxxxxxxxxx
http://www.asahi-net.or.jp/~yw3t-trns/index.htm
Key fingerprint =  474E 4D93 8E97 11F6 662D  8A42 17F5 52F4 10E7 D14E