Re: UTF-2000-MULE (Re: semi? remi? wremi? semi-pgpgpg?)

北目>> M-x wl すると、 北目>> End of stream: "internal input stream" 北目>> とでてしまいます。 北目>> APEL FLIM WEMI は CVSで取得した最新のもので wlは 2.0.1 です。 北目>> Signaling: (end-of-file "internal input stream") 北目>> load-internal("elmo-util" nil t nil utf-8) 山岡> 下司の勘繰りです。(^^;;) 山岡> elmo-util.el で (re-search-forward "[\C-＠-\C-?]+" nil t) してみる 山岡> と756 行目に "ふくまれる" と書いてありますね。これが原因かどうかわ 山岡> かりませんが、ぼくの経験上は elisp のファイルに日本語を書いておく 山岡> とことごとくだめになりました。 山岡> 例えば "Chiyoda" を "千代田" で置き換えようとしたらだめだったし 山岡> egg.elには和文中文韓文が入り乱れているのでまったくだめ、という具合。 山岡> (^^;;) うむむ、XEmacs 自体に含まれる大量の非 ASCII 文字入り file は OK なんです が（それがだめだと、そもそも XEmacs を built できないはず）。 ところで、いずれにせよ、UTF-2000 は現段階では実用のものではないし、使っ てうれしい点はないはずです。 ;; 主な目的は内部表現を変えても見掛け上今の MULE と同等に扱えることを実 ;; 証するのと、内部表現を変える上で問題となる点を洗い出すことです。 ;;; とりあえず、regexp.c が鬼門だということは良く判りました(^_^; ;;;; ちなみに非 1 byte 固定長の世界に移行すると、Bufbyte* 問題、byte じゃ ;;;; ないのに bytecode 問題、file system interface 問題などさらに続々興 ;;;; 味深い問題が起こってくるみたいです。楽しみですね。(^_^;;; また、今後は内部表現を 1 byte / 2 byte / 4 byte 固定長切替方式にした UCS-2000 に移行する予定です。で、今度時間ができたら取り合えず 1byte:7bit / 4byte:31bit 固定長切替方式の実装をでっちあげるつもりです。 これがとりあえず動いたら 1byte:8bit / 2byte:16bit / 4byte:32bit 化を目指 します。 ;; もちろん、より本質的な問題も。ただ、こちらは前人未踏の地なので、時間 ;; がかかるでしょう。 -- moto % 今は Thai 特別版を使っています