山岡> > Update of ${CVSROOT}/apel 山岡> > Modified Files: 山岡> > mcs-xm.el 山岡> > Log Message: 山岡> > (mime-charset-decoder-alist): Don't use 山岡> > `decode-mime-charset-region-with-iso646-unification' if running 山岡> > XEmacs-UTF-2000. 山岡> > (mime-iso646-character-unification-alist): Don't define if running 山岡> > XEmacs-UTF-2000. 山岡> > (mime-unified-character-face): Likewise. 山岡> > (mime-character-unification-limit-size): Likewise. 山岡> > (decode-mime-charset-region-with-iso646-unification): Likewise. 山岡> ええと、US-ASCII のように見えて実は違う文字が isearch などで捕ま 山岡> らなくなってしまうのですが、このへんはどうお考えでしょうか? 山岡> 確かに US-ASCII では無いのですが、そういう文字をメールで送って来 山岡> る人の多くはおそらく US-ASCII のつもりで書いているし、受け取った 山岡> 側も同じ字体で表示していたら区別がつきません。 最新の UTF-2000 では Latin 文字に関して重複符号化しなくしたので、 (split-char (make-char 'latin-jisx0201 65)) -> (ascii 65) となります。そういう訳で、上記の code は意味をなさないばかりか障害の原 因になります。 ;; それで慌てて修正したんです（焦ったぜー；encoder しかいじってないは ;; ずなのに何で decode がおかしくなったんだろうと頭を抱えてしまった）。 ;; 直接の原因は decode-mime-charset-region-with-iso646-unification で ;; case-fold-search を nil に束縛してないことなんですけど。（治した方 ;; が良いかも） まあ、UTF-2000 では将来追加される UTF-2000 の文字定義機能によって文字 の包接を制御することにして、めでたく APEL の中途半端で遅い文字統合機能 は引退というのが良いんじゃないかと思います。 ;; ISO/IEC 2022 の登記簿にある文字集合用の領域は私的領域に予約してある ;; ので、必要ならその場所（あるいはそれ以外の場所）に JIS-Latin の文字 ;; を分離することも可能にする予定です（逆に、ASCII をそこに写すことも ;; できるでしょう）。ただ、こうすると、UTF-8 のお約束により、１文字が ;; 5 byte になります。:-P -- === ……つまり ======================================================= ====== 隠されているかもしれない可能性にかけてみようということです ==== 守岡 知彦 (MORIOKA Tomohiko) Email: <tomo(a)etl.go.jp&gt;