~/.w3m/.arrived

[Katsumi Yamaoka <yamaoka@xxxxxxx>]

;; MU-CITE に関係した話もあるので、Elips にも Cc します。
;; フォローして下さるときはご注意を。

~/.w3m/.arrived はユーザが手で編集することはあまり考慮していない
ファイルで、w3m.el のプログラムが作り、または読み込んで利用しま
す (w3m.el のプログラムが読み書きするファイルは他にもあります)。

ぼくは .arrived ファイルを何度も壊してしまった経験があり、壊れて
しまうと emacs-w3m を起動することができないので、その都度壊れた
ファイルを消して対処していました。ファイルが壊れてしまう原因と思
われるものは以下の通りです。

・オプション `w3m-arrived-file-coding-system' の値をデフォルトの
  `euc-japan' のままにしている。
・ときどき読めもしないのに台湾や東欧の web ページを開いてしまう。
・ぼくは主に XEmacs を使っている。

.arrived ファイルにはページのタイトル文字列が記録されますが、そ
れが `euc-japan' でエンコードできない場合に、S 式としての括弧の
整合が破壊されてしまうようです。FSF Emacs の場合は coding-system
を他の何にするかを尋ねてくれると思うのですが、それで正しいファイ
ルが作られたとしても、次回読まれるときには `euc-japan' が適用さ
れてしまうので、XEmacs ほどではないかもしれませんがやはりダメで
しょう。

プログラムが読み書きするファイルの coding-system は
`iso-2022-7bit' などにした方が良いのではないでしょうか?

しかし、単に `w3m-arrived-file-coding-system' のデフォルト値を
いきなり `iso-2022-7bit' に変えてしまうわけにはいきません。おそ
らく既存の `euc-japan' でエンコードされたファイルを壊してしまう
でしょうから。

それで思い出したのが、MU-CITE に含まれている mu-register.el が管
理している ~/.mu-cite.el というファイルのことです。ここにはメー
ルアドレスと返信するときに使う引用符の文字列の alist が記録され
るのですが、プログラムがこのファイルを読み書きするやり方はちょっ
と変わっています。

ファイルを読むときの coding-system はデフォルトでは無指定、すな
わちデコードは Emacs の自動判定に任せています。その自動判定の結
果は読み込んだバッファの `buffer-file-coding-system' に反映され
るので、その値を記憶しておいて内容が更新されたファイル書き込むと
きの coding-system を指定しています。このやり方はかなり良いもの
だとずっと思っていたのですが、実は emacs-w3m と同じ問題を孕んで
いることに気が付いてしまいました。

それは、それまで存在しなかったファイルが新規に作成されるとき、ま
たはそれまでファイルに非 ascii 文字が記録されていなかった場合に、
ファイルを書くときの coding-system を特定していないので非 ascii
文字が `euc-japan' か `shift_jis' のどちらかでエンコードされてし
まうことが多いことが問題の発端になります。

そのように最初に何となく決定されてしまった coding-system がその
後ファイルを書くときに使われるようになってしまうので、もしその
coding-system でエンコードできない文字列が追加されると破綻してし
まいます。少しだけ救いがあると思うのは、FSF Emacs を使っている場
合はそこで適正な coding-system に変更される可能性があることなの
ですが、XEmacs の場合は非常にマズいことになってしまいます。

なお、~/.mu-cite.el の場合は、一度手作業で `iso-2022-7bit' など
に変えてしまえば、その後は事故が起きる可能性がぐっと下がると思い
ます。

さて、emacs-w3m のプログラムが管理しているファイルはどうしましょ
うか? ファイルを読むときは Emacs の自動デコードに任せ、記録する
ときの coding-system を `iso-2022-7bit' などにしてしまう、そのデ
フォルト値を定義する変数は、emacs-w3m のプログラムが扱う複数のファ
イルに対して共通にしてしまう、ということではいかがでしょうか?

それと、真に国際化を目指したときに適当な coding-system として、
`iso-2022-7bit' は適切なデフォルト値なのでしょうか?
Gnus の ChangeLog はそれを指定していますが...。
-- 
Katsumi Yamaoka <yamaoka@jpl.org>