July 1999 - XEmacs-Beta-ja - XEmacs Mailing List Archives

Re: UTF-2000-MULE (Re: semi? remi? wremi? semi-pgpgpg?) 24 years, 10 months

Takuro KITAME

>>>>> At [tm(ja) / tm ML (日本語版)] 30 Jun 1999 17:22:20 +0900 >>>>> "KY" == Katsumi Yamaoka <yamaoka(a)ga.sony.co.jp> wrote... KY> XEmacs 21.2.17 については ftp://ftp.jpl.org/.secret/xemacs-21.2/ に、 KY> CVS で取得した最新の source への差分と、これをパッチした後で使う KY> UTF-2000 のパッチを置いてありますので、your own risk でどうぞ。とりあえず報告、なんですが(^^; えと、試してみたんですが、Wanderlustが起動できなくなってしまいました。 XEmacs 21.2.16 with UTF-2000-MULE や XEmacs 21.2.17 では平気だったんですが M-x wl すると、 End of stream: "internal input stream" とでてしまいます。 APEL FLIM WEMI は CVSで取得した最新のもので wlは 2.0.1 です。ちょっと時間がなくて追ってないんですが、とりあえず back traceをつけときます。 Signaling: (end-of-file "internal input stream") load-internal("elmo-util" nil t nil utf-8) load("elmo-util" nil t nil) require(elmo-util) byte-code("..." [require elmo-vars elmo-util emu std11 elmo-cache] 2) load-internal("elmo-msgdb" nil t nil binary) load("elmo-msgdb" nil t nil) require(elmo-msgdb) byte-code("..." [require elmo-vars elmo-msgdb elmo-cache elmo-util elmo-dop provide elmo2 featurep dbm gnudbm berkdb elmo-database "0.9.7" elmo-version current-load-list "ELMO" elmo-appname] 2) load-internal("elmo2" nil t nil binary) load("elmo2" nil t nil) require(elmo2) byte-code("..." [require elmo2 fboundp defgroup defcustom backquote (macro . #<compiled-function ... "...(2)" ... 1>) (macro . #<compiled-function ... "...(14)" ... 4>) wl-vars wl-util wl-on-xemacs wl-xmas wl-on-nemacs wl-nemacs wl-mule wl-folder wl-summary wl-thread wl-address wl-draft-mode-setup wl-draft wl-draft-key-setup wl-demo wl-highlight] 2) load-internal("wl" nil nil nil binary) load("wl" nil nil nil) command-execute(wl t) ad-Orig-execute-extended-command(nil) (setq ad-return-value (ad-Orig-execute-extended-command prefix-arg)) ) (let (ad-return-value) (setq ad-return-value (ad-Orig-execute-extended-command prefix-arg)) (skk-set-cursor-properly) ad-return-value) ) execute-extended-command(nil) call-interactively(execute-extended-command) -- Takuro KITAME / 北目拓郎 kitame(a)northeye.org -> http://northeye.org/ kitame(a)debian.org / kitame(a)debian.gr.jp -> http://www.debian.org/ kitame(a)linux.or.jp -> http://www.linux.or.jp/

2 participants
2 comments

Re: MULE or Mule (Re: Message with No Mime-Version: header) 24 years, 10 months

守岡知彦 / MORIOKA Tomohiko

>>>>> <1999Jul016744akhd.kose(a)wizard.tamra.co.jp> にて >>>>> “小関”= 小関吉則 (KOSEKI Yoshinori) <kose(a)wizard.tamra.co.jp> さま曰く: 守岡> なお、Emacs/MULE では昔は小関> ~~~~ 小関> Mule と MULE は使い分けているのでしょうか? 前述の message では使い分けていませんでした。小関> o MULE は "MULtilingual Enhancement to GNU Emacs"の意。小関> o Mule は MULE を実装した emacsen を差す。 ;; 他にも、m17n.org にある machine の名前とか、某所にある lab の名前とか、 ;; 多言語処理研究プロジェクトの名前? とか、身売りじゃないよとかいろいろ ;; あって紛らわしいんですが…(^_^;;; ;;; 最近の用法の頻度では、machine の名前が一番高いような気がする。小関> Mule の使用例 --- flim/README.ja より小関> > Emacs か Mule を使っているなら、FLIM のディレクトリーを小関> > load-path に追加してください。初期設定のまま導入したなら、次の小関> > ように subdirs.el を書くことができます。例: 小関> でもこの引用した3行上では小関> > load-path (Emacs と MULE 用) 小関> と書かれているんだな、これが。 emu_ja.ol という昔書いた文書では mule: 全ての多言語版 EMACS を指します。 MULE: Mule 1.* および Mule 2.* を指します。みたいに区別していたみたいですが（Mule は mule の文頭形）、『正しい』用法と適合していないみたいなのでこの区別は消えました。小関> http://www.etl.go.jp/~mule/MulePage.html 小関> を見ると Mule で統一しているようなんだけど。 emacs の ChangeLog に 1999-05-13 Ken'ichi Handa <handa(a)gnu.org> * international/mule-cmds.el: Change MULE to Mule in docstrings and menus. という用法があり、もしかすると最近 Mule に統一することに決まったのかも知れません。 ;; 但し、ここでの "Mule" の用法は多言語機能を指していると思います。 ;; また、今年の春に書かれた某文書では MULE (MULtilingual enhancement ;; of GNU Emacsen) だったような。でも、Emacs 20.3.11 には (defconst mule-version "4.0 (HANANOEN)" "\ Version number and name of this version of MULE (multilingual environment).") (defconst mule-version-date "1998.7.1" "\ Distribution date of this version of MULE (multilingual environment).") とかもあってなかなか油断できません。 ;; もしかすると、MULE (MULtilingual Environment) なのかも知れなかったり ;; して。まあ、一度聞いてみます（でも、過去に聞いた経験からすると、多分、統一見解や厳密な定義はないと思う(^_^;）。 ;; もう半田さんの頭の中では Mule 2.3 は 19.34 base になっていたりするみ ;; たいなので、なかなか油断できなかったりします。(^_^; 小関> ;; すみません。細かくて。でも気になると夜も眠れなくなるので小関> ;; 聞いてしまいます。なんとなく余計混乱させてしまったような気がしますが。(^_^;;; -- ===『幾千億の分子に分かれても ======================================== 決して忘れない。この宇宙が終るまで』守岡知彦 (MORIOKA Tomohiko) ======================================== Email: <tomo(a)etl.go.jp> ===== ;; PGP public key: http://www.etl.go.jp/~tomo/hiko/pgp.key

1 participants
0 comments

Re: UTF-2000-MULE (Re: semi? remi? wremi? semi-pgpgpg?) 24 years, 10 months

Hidekazu Nakamura

なかむらです。 ;;早速 xemacs-beta-ja にsubscribeしました。 ;;Followup-To: xemacs-beta-ja(a)xemacs.org としておきます。 >>> "Katsumi" == Katsumi Yamaoka <yamaoka(a)ga.sony.co.jp> writes: >>>>>> In <19990630170826.99253.1001(a)uinter.uis-inf.co.jp> >>>>>> Hidekazu Nakamura <u90121(a)uis-inf.co.jp> wrote: 中村> ここ最近 User-Agent: に UTF-2000-MULE というのがついて中村> いるメールを見掛けるようになりましたが、これはなにもの中村> なのでしょうか? Katsumi> 最近新設されたメーリングリスト xemacs-bata-ja に守 Katsumi> 岡さんが寄稿されたものです。以下に記事の冒頭部分を Katsumi> 添付...ありゃもう expire されてる。(^^;;)すみません Katsumi> が、どなたか紹介して差し上げて下さいませ。 Katsumi> ;; expire 期間が短かすぎるな。(^^;;) Katsumi> XEmacs 21.2.17 については Katsumi> ftp://ftp.jpl.org/.secret/xemacs-21.2/ に、CVS で取 Katsumi> 得した最新の source への差分と、これをパッチした後 Katsumi> で使うUTF-2000 のパッチを置いてありますので、your Katsumi> own risk でどうぞ。山岡さん、早速ありがとうございます。 ftp://ftp.jpl.org/.secret/ あたりにあるのでは? とあたりをつけて探っていたのですが、その配下のxemacs-21.2のしただったとは。メールを受け取って思い出しました。早速入手して、パッチ・コンパイルしたところ、これらはうまくいきました。早速起動しましたが、以下のような問題が起きます。 XEmacs を立ち上げて、CANNAを起動し、句読点(。や、)を入力して、 CTRL-N で半角句読点に変換しようとすると、Segmentation Fault を起こして、100% XEmacsがお亡くなりになる。ちょっと時間がとれないので、報告だけになってしまい申し訳ありません。(your own risk モードになり切れていない…) ほかで再現しないようであれば、個人の問題として自力で解決を試みてみようと思います。あと、これは問題かどうかがわからないのですが、過去のUTF-8なメールがUTF-2000パッチをあてたXEmacsでは読めなくなってしまいました。 X-Ml-Name: tm(ja) / tm ML (日本語版) X-Ml-Count: 4130 とか。これはこれで正しい動作と考えてよろしいでしょうか? ちなみに、UTF-2000パッチをあてたXEmacsで書いたUTF-8なメールは、同XEmacsで読めます。 Katsumi> なお、xemacs-bata-ja と同時に新設された Katsumi> xemacs-users-ja への参加方法は本文に subscribe と書 Katsumi> いたメールを、それぞれ Katsumi> xemacs-beta-ja-request(a)xemacs.org Katsumi> xemacs-users-ja-request(a)xemacs.org Katsumi> に送る、です。特に xemacs-beta-ja の過去の記事を読 Katsumi> まないと辛いと思いますが、これってwww.xemacs.org あ Katsumi> たりに置いてあるんでしたっけか? 早速参加しました。過去の記事をGETしようと思ったのですが、 majordomo に「ないよ」っていわれてしまいました。;_; もしかして、過去に今回の問題の解決がのっている??? -- Hidekazu NAKAMURA <u90121(a)uis-inf.co.jp> <kazzu(a)eastmail.com> Information Processing Dept., Ube Information Systems, Inc. Phone: +81-836-21-7365 Fax: +81-836-22-6410

2 participants
2 comments

Re: Message with No Mime-Version: header 24 years, 10 months

守岡知彦 / MORIOKA Tomohiko

>>>>> <19990701132220F.nakaji(a)tutrp.tut.ac.jp> にて >>>>> “中治”= 中治弘行 <nakaji(a)tutrp.tut.ac.jp> さま曰く: 中治> >>>>> In [semi-gnus-ja : No.3522] 中治> >>>>> tomo(a)etl.go.jp (守岡知彦 / MORIOKA Tomohiko) wrote: 中治> 残りのご説明はきちんと理解できないのですが、すご〜く大雑把に言うと、 ;; 判りにくくてすみませんでした。(^_^;;; 中治> MUA が解釈して「このように表示して」とEmacsenに依頼、Emacsenは「そ中治> のように」表示するだけ。中治> ということですね。で、「この」や「その」は歴史的経緯からいろいろあっ中治> て、それなりに問題が起こる(ように見える)こともある、と。中治> 今回は、たまたま、1978 な 14dot のフォントがないからスケーリングが中治> 行われた、と。中間にもう一段階あります。ご存知のように現在の MULE では各文字は ISO/IEC 2022 の 94, 96, 94×94, 96×96 図形文字集合 (MULE charset) とその中での code point という形で表現されます。よって、 (make-char 'japanese-jisx0208-1978 33 34) と (make-char 'japanese-jisx0208 33 34) は違う文字オブジェクトになります（Lisp object としてということで、本来は両者は同じ <IDEOGRAPHIC COMMA> という文字として扱われるべきです）。で、code point unify をするというのは (make-char 'japanese-jisx0208-1978 33 34) となるべき文字を (make-char 'japanese-jisx0208 33 34) にしてしまうということです。この例の場合、良いんですが、例えば、 (make-char 'japanese-jisx0208-1978 (+ 18 32) (+ 10 32)) = ?鴎を (make-char 'japanese-jisx0208 (+ 18 32) (+ 10 32)) = ?鴎にするのはまずい訳です。 ;; (make-char 'japanese-jisx0212 #x6c #x3f) = ?鷗 ;; にするのは構わないといえます。で、font の問題は文字オブジェクトの同一性の問題と関連していますが、微妙に違う問題です。例えば、set-charset-registry とかで japanese-jisx0208-1978 用の font として JIS X 0208:1978 用の font を使うことができます。この場合、内部的には code point unify されませんが、見た目は code point unify されます。ついでにいうと、今時の X-tt みたいな環境だと、同じ font を異なる encoding で利用できますので、文字オブジェクトの世界から見た目の世界に至るまで３段階ぐらいの階層が存在することになります。 ;; 現在の規格体系が想定するモデル的には、符号化文字（見た目は一切関係な ;; し）、glyph / 字体（文字の形状に関する抽象的概念）、字形（実際の見た ;; 目）という区別があることになっています。もちろん、実際の実装がこれに ;; 対応しているとは言えないんですが。さて、歴史的経緯とは、十分な種類の font がなかったり、そもそも多くの文字を十分に区別可能な符号空間を持たない貧乏な実装・環境がなかった昔に、 JIS X 0208:1978 / 1983 の差異を誤魔化すために、両者を符号化文字の階層で同一視してしまうということをやってしまったということです。MULE では概ね符号空間の問題はないので、問題は利用者の環境に font があるかどうかに落ちています。にも関わらず、歴史的経緯で、Emacs-MULE は両者を符号化文字の階層で同一視するという病気を持っているということです。そんなことは知ったこっちゃねえ、て言われると悲しいんですが、そういう場合、 (a) 頑張って JIS X 0208:1983 に変換する (b) JIS X 0208:1978 で書かれた文字は読まない (c) JIS X 0208:1983 用の font を使う (d) JIS X 0208:1978 の文字を 1983 の文字に code point unify してしまうというアプローチが考えられます。上ほどお勧めですが、今の所 XEmacs では (a) は難しいです。(d) は知っていますがお教えしません。(^_^;;; 私としては (b) がお勧めですが:-P、(c) としては CCL で code point unify せずに使うという激しい方法も考えられます（お勧めですが akr さん以外には困難でしょう(^_^;）が、前述の set-charset-registry を使って code point unify して使うのが簡単でしょう。 -- ===『幾千億の分子に分かれても ======================================== 決して忘れない。この宇宙が終るまで』守岡知彦 (MORIOKA Tomohiko) ======================================== Email: <tomo(a)etl.go.jp> ===== ;; PGP public key: http://www.etl.go.jp/~tomo/hiko/pgp.key

2 participants
1 comments

MULE or Mule (Re: Message with No Mime-Version: header) 24 years, 10 months

小関吉則 (KOSEKI Yoshinori)

すみません、本題とは無関係なことで‥ >>>>> In <htxoghxypu8.fsf(a)mulelab3.etl.go.jp> >>>>> “守岡” = tomo(a)etl.go.jp (守岡知彦 / MORIOKA Tomohiko)さん守岡> なお、Emacs/MULE では昔は ~~~~ Mule と MULE は使い分けているのでしょうか? o MULE は "MULtilingual Enhancement to GNU Emacs"の意。 o Mule は MULE を実装した emacsen を差す。 Mule の使用例 --- flim/README.ja より > Emacs か Mule を使っているなら、FLIM のディレクトリーを load-path に > 追加してください。初期設定のまま導入したなら、次のように subdirs.el > を書くことができます。例: でもこの引用した3行上では > load-path (Emacs と MULE 用) と書かれているんだな、これが。 http://www.etl.go.jp/~mule/MulePage.html を見ると Mule で統一しているようなんだけど。 ;; すみません。細かくて。でも気になると夜も眠れなくなるので ;; 聞いてしまいます。 ;;; GNU Emacs, XEmacs, Nemacs, and Mule ? or MULE ? -- こせき＠ Emacs のページ作成中 http://www.NetLaputa.ne.jp/~kose/Emacs/ kose(a)yk.NetLaputa.ne.jp

1 participants
0 comments

Re: UTF-2000-MULE (Re: semi? remi? wremi? semi-pgpgpg?) 24 years, 10 months

守岡知彦 / MORIOKA Tomohiko

>>>>> <28pv2c3os3.fsf(a)kchisa.ga.sony.co.jp> にて >>>>> “山岡”= Katsumi Yamaoka <yamaoka(a)ga.sony.co.jp> さま曰く: 北目>> 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 特別版を使っています

1 participants
0 comments

Re: Message with No Mime-Version: header 24 years, 10 months

守岡知彦 / MORIOKA Tomohiko

>>>>> [semi-gnus-ja : No.3518] にて >>>>> “中治”= 中治弘行 <nakaji(a)tutrp.tut.ac.jp> さま曰く: 中治> ときどき、ヘッダに中治> 1. Content-Type はあるが、Mime-Version がない中治> 2. どちらもない中治> メッセージがあります。そういうメッセージの本文を表示するのに、中治> XEmacs さんは jisx0208-1978 なフォントを使うらしく、見苦しいです。 us-ascii にすれば良いですか？:-) というお約束は置いておいて、ある MIME charset をどういう風に解釈するかを決めているのは MUA であって、XEmacs ではありません。よって、1, 2 であるかはこの『問題』に関係ありません。通常、emacsen 上の MUA は MIME charset に対応する coding-system を決め、それで decode してくれるように emacsen に依頼します。で、iso-2022-jp データ列で JIS X 0208:1978 を指示していたら、ISO 2022 decoder は GB 2312 でも ISO 646 IRV でも JIS X 0212 でもなく JIS X 0208:1978 として解釈しなければならないのは当然のことです。ところが、従来、JIS X 0208:1978 と JIS X 0208:1983 を同一視する悪しき慣習がありました。もちろん、文字集合とその上での符号位置で表現される符号化文字をさらに解釈して system 固有の文字に mapping するのは良いことですが、従来、文字を文字として解釈するのではなくて、異なる文字集合の符号位置の意味を勝手に unify するというでたらめなことをしていた訳です。 ISO/IEC 2022 の図形文字集合上の符号位置から文字オブジェクトに mapping する機構と正確な data があれば文字の同一性を考慮して unify するのは真っ当でしょう。しかしながら、現在の XEmacs にはその双方がありません。そうである以上、悪しき慣行に基づく ad-hoc なやり方はやめておいた方が良いと思います。なお、Emacs/MULE では昔は hard coding により unify されていたのですが、現在では文字を文字に変換する translation-table 機構により実現されています。で、default の値が腐っている訳です。多分、これは将来直るのではないかと思っていますが Emacs 20.4 は今のままになるようです。という訳で、以下の質問ですが、中治> 1. そういうメッセージの存在そのものは許されるものでしょうか? 中治> MIMEの世界征服が達成されると、許されない? 許されます。そもそも charset=iso-2022-jp を明示しても同じ問題が起こります。また、 charset の指定がないものを us-ascii として解釈した場合、 charset=iso-2022-jp を明示した message に対してのみこの問題が起こります。 ;; MIME はメタな枠組なので、個々の内容に依存した問題は MIME に関係しない ;; ことが多いです。 ;;; utf-8 の世界征服が達成されると起こらない？（あ、でも、JIS X ;;; 0208:1983 の font とかを使っていると相変わらず起こるとか、UCS ;;; encoding でも穴空き font だともっと激しく起こったりして(^_^;;;） -- ===『幾千億の分子に分かれても ======================================== 決して忘れない。この宇宙が終るまで』守岡知彦 (MORIOKA Tomohiko) ======================================== Email: <tomo(a)etl.go.jp> ===== ;; PGP public key: http://www.etl.go.jp/~tomo/hiko/pgp.key P.S. 新 JIS だと JIS X 0208:1978 と 1990 の両方の文字が入っているのでお得？（果して、今年中に出るのか？）

2 participants
1 comments

Message with No Mime-Version: header 24 years, 10 months

NAKAJI Hiroyuki

中治＠豊橋です。 XEmacs-21.2.17 + Mew/ET-gnus でメール/ニュースの読み書きをしています。ときどき、ヘッダに 1. Content-Type はあるが、Mime-Version がない 2. どちらもないメッセージがあります。そういうメッセージの本文を表示するのに、XEmacs さんは jisx0208-1978 なフォントを使うらしく、見苦しいです。 intlfonts を入れるまで、フォントがない、と表示さえされなかったことを考えると、見えるだけでも良とすべきでしょうが、質問です。 1. そういうメッセージの存在そのものは許されるものでしょうか? MIMEの世界征服が達成されると、許されない? 2. 見苦しいのは、なんともならんのでしょうか? 要するに、あきらめる理由を探しています。 ----====----====----====---- NAKAJI Hiroyuki (中治弘行) 豊橋技術科学大学建設工学系

2 participants
2 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

XEmacs-Beta-ja July 1999