[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: w3m-euc-japan
>> On 23 May 2001 19:05:12 +0900
>> 「山」== yamaoka@jpl.org (Katsumi Yamaoka) said as follows:
山> ;; GIF anime にうつつを抜かしている間に、日本語のページがまった
山> ;; く読めなくなっていることに気がつきました。
土> あれま。おっかしいなあ、[emacs-w3m:00786] を出したときには
土> XEmacs でも試したのですが、問題なく読めていたんですけど…。
この問題なんですけど、実は CCL の問題ではなく、
山> ;; 問題はこれを XEmacs でどう料理するかだなあ。FSFmacs みたいに
山> ;; unibyte という状態が存在しないわけで...。
これが本質的な原因なのではないか、ということに気が付きました。
今回の改変では、「ある関数を実行中は必ず、バッファは unibyte (or
multibyte) 表現である」という切り分けを諦めて、「バッファは unibyte で
も multibyte でも有り得る。各関数はそれに対応して動作を変えるべし」と
いう実装で整理しました。
具体的には、w3m-decode-buffer / w3m-rendering-region がそうなっていま
す。
しかし、XEmacs は unibyte という状態が存在しないので、例えば、
(let ((url "http://namazu.org/~tsuchiya/emacs-w3m/"))
(w3m-with-work-buffer
(w3m-retrieve url)
(w3m-decode-buffer url)))
としても *w3m-work* の内容は人間には読めない形式のまま、になってしまい
ます。
また、
(with-current-buffer (get-buffer-create "*TEST*")
(let ((coding-system-for-write)
(coding-system-for-read 'w3m-euc-japan))
(call-process "w3m" nil t nil "-halfdump"
"http://namazu.org/~tsuchiya/emacs-w3m/")))
が正常に表示されることから考えても、CCL の実装に問題はないと判断できる
と思います。
そういうわけで、以前の通り「ある関数を実行中は必ず、バッファは unibyte
(or multibyte) 表現である」という切り分けをするように変更しようと思い
ますが、ちょっと考えさせてください。
土> # euc-japan が実は iso-2022 に準拠した文字コードだということ
土> # を、今回初めて知りました。
山> (decode-coding-string (encode-coding-string "あ" 'iso-2022-7bit) 'euc-japan)
山> => "あ"
山> ;; XEmacs の実装です。:-p
すごいなあ。
山> うーむうーむ、苦し紛れにちょっと大きなものを付けます。すみません。
山> [2 xemacs-w3m.png <image/png (base64)>]
初めて Semi-gnus でインライン表示される画像を見ました。なかなか良いも
のですね。
--
土屋 雅稔 ( TSUCHIYA Masatoshi )
http://www-nagao.kuee.kyoto-u.ac.jp/member/tsuchiya/