名前問題

[守岡知彦 / MORIOKA Tomohiko]

>>>>> In [chise-ja : No.00089] 
>>>>>	"Stephen" = "Stephen J. Turnbull" <stephen ＠ xemacs.org> wrote:

tomo>> XEmacs UTF-2000 は既に "Unicode Inside" ですよ。

Stephen> もちろん。でも「プラスアルファ」。つまり、私のやりたいのは
Stephen> MULEコードを廃止し、内部コードとしてUnicodeを導入することだけ
Stephen> ですが、文字プロパティーなどのUTF-2000の独特的な機能は（自分
Stephen> が）考えておりません。

だとすると、XEmacs UTF-2000 0.2 頃の code を手直しすれば OK ですね。

ただ、私の理解では現在の Unicode をちゃんと扱うには Unicode Database
が使えないとまずいのではないかと思います。

実際、半田さんの Emacs Unicode の場合、XEmacs UTF-2000 の文字属性テー
ブルに似た機構が設けられているみたいです。


tomo>> mapping もいろいろ使えます。CCL を使わない mapping ベースの
tomo>> coding-system もそのうち実現する予定です。

Stephen> これは21.5ではある程度も実現できました。UTF-2000の正確さはま
Stephen> だないはずですが、unicode.orgテーブルは直接に読み込めますので
Stephen> 簡単に直せるでしょうか。

なるほど。

tomo>> Wing さんのパッチはなかなか出て来ませんでしたね。今はもう結
tomo>> 構安定しているんでしょうか？

Stephen> 21.5 Muleは安定ですが、Unicode機能には多少な改善が必要ですね。
Stephen> 基本構造は安定、詳細（テーブルなど）のことです。でもGCに大き
Stephen> な変更を行い、ほかの機能もどんどん修正しています。特にJerry
Stephen> Jamesさん等によるELL/DSOを基準かする計画がUTF-2000に役立つと
Stephen> 思っています。

ELL/DSO というのは何でしょうか？ dynamic loading 機構のようなものでしょ
うか？


tomo>> それは認識しています。また、Mac OS X でも動かしたいと思って
tomo>> いますし。

Stephen> MacOS/X ポートはすでに（今週月曜日ぐらい ;-) ）ブランチにチェッ
Stephen> クイン済です。

21.5 の方は比較的最近だったのですか。

tomo>> ところで、glibc 2.3 用の従来型ダンプは入らないんでしょうか？

Stephen> 今reviewerの気持はpdumpの改善を進めてunexecを廃止する方がよい
Stephen> と思います。現在、MacOS/X, Cywgin, Windows NTとglibc 2.3シス
Stephen> テムには正しいunexecがなく、逆にまだ「システムZにダンプができ
Stephen> るため」のパチは全く必要なかったです。M-x
Stephen> all-hail-olivier-martin-and-kyle RET.  (^^)

それは妥当な方針だと思います。

Stephen> もし、誰かにやる気があればもちろんパチは受付しますが…

tomo>> 例えば、XEmacs UTF-2000（仮称）を XEmacs 本家の CVS の 
tomo>> branch に入れて開発することは可能でしょうか？

Stephen> 原則として可能と思いますが、まずWingさん等に相談が必要と思います。

私としてはどうしてもということではないので、気が向いたらどうぞ。

tomo>> とりあえず、すぐに merge するのは無理だとしても。

Stephen> でも、私の理解している範囲なら完全な merge は無理なんです。つ
Stephen> まり、UTF-2000は言語学者に必要な機能と文字の精密な正確さを用
Stephen> いるがほとんどの利用者（特に異邦人）には構いませんでしょう。
Stephen> Hrvoje等は絶対反対と思いますね。

Stephen> 私が考えているのは31-bit Lisp文字を導入して[1]UTF-32の使わな
Stephen> い空間に旧MuleコードとUTF-2000に必要な文字集合を入れて、その
Stephen> 取扱に必要な最低の機能を幹に加えて、そのほかをパケージ・DSOに
Stephen> 入れる方法が適当です。守岡さんはどう思われますか。

ひところの XEmacs UTF-2000 は文字定義を全部 dump してとても大きなもの
でしたが、現在のは比較的コンパクトですし、Mule 関連の Lisp code を改良
することによってもっとコンパクトにできると思います。

また、現在の XEmacs UTF-2000 の中枢である文字属性テーブルは、Unicode
実装的にいえば、従来の char-table を Unicode に合わせて実装しなおした
ものです。多分、これは必須でしょう。

とすると、現在（あるいは昔の）XEmacs UTF-2000 の code を元に（大部分の）
文字定義を取り除いたもの（+ もしかすると Unicode Database & UniHan
Database 読み取り用 code を付加したもの）を作れば、ほぼ Turnbull さん
の望みのものになる気がします。

それから、UTF-2000 とは文字集合ではないので、それ自体にはそのために必
要な符号化文字集合はありません（あ、でも code をダンスじゃなくて文字列
で書いてるので、ISO 646 IRV は必要かも:-)）。漢字統合が前提である限り、
現在の Unicode は多分 Mule で使っていた全ての文字を表現可能だと思いま
す（何しろ現在でも約 7 〜 8 万字漢字が入ってて、近い将来あと 1 万字以
上増えるので）。


ところで、現在の CHISE プロジェクトの方向性に沿って、XEmacs 側から見る
とコンパクトな Unicode 実装に見えて、実は UTF-2000 機能を持つという構
成は可能かも知れないという気もしてます。極論ですが、XEmacs から Mule
charset も coding-system もみーんななしにして、単に文字が UCS-4, 文字
列・バッファが UTF-8 である非 Mule XEmacs を作ります。coding-system は
iconv のような外部のプログラムを呼ぶかその手のライブラリを link します。
あと、どうしても文字属性が必要な局面がきっと出て来ますが、それも外部プ
ログラムないしはライブラリに任せます。そして、それを libchise が提供す
れば全体としては XEmacs UTF-2000 と同等になると思います。文字に関する
知識だけでなく、coding-system や CCS に関する知識も管理するようにすれ
ば、データベースをいじることによって coding-system や CCS が定義できま
す。もちろん、そうした処理は Emacs Lisp から呼び出せるでしょう。そうす
ると、XEmacs 自体は coding-system や CCS がなくても事実上使えるように
なると思います。ただ、多分、ひとつ問題になるのは font の問題で、もし非
Unicode encoding の font を使いたいとするなら display engine で工夫が
必要です。もし、Unicode encoding の font を使い、複雑なグリフ処理を必
要とする script を排除するなら非常に簡単な構成が可能でしょう。あるいは、
外部の display engine に任すように設計しなおすかかな？

;; うーん、Windows のメモ帳みたい。(^_^;

-- 
===『幾千億の分子に分かれても ========================================
     決して忘れない。    
     この宇宙が終るまで』              守岡 知彦 (MORIOKA Tomohiko)
====================== Email: <tomo ＠ kanji.zinbun.kyoto-u.ac.jp> ======