[Mew-dist 12998] Re: raw iso-2022-jp in subject field
Shun-ichi GOTO
gotoh at example.com
2000年 5月 18日 (木) 15:19:03 JST
>>>>> at Thu, 18 May 2000 11:41:06 +0900
>>>>> kazu == Kazu Yamamoto (山本和彦) <kazu at example.com> said,
kazu> From: Shun-ichi GOTO <gotoh at example.com>
kazu> Subject: [Mew-dist 12989] Re: raw iso-2022-jp in subject field
> それにしてもMew本体に、JISのSubject:を解釈しする機能を導入しない
> 理由はないと思っています。「受信は寛容に」の観点から。
kazu> 「C-uC-cC-l で、できなかったかしら」と思ってコードを見たら、C-u が付い
kazu> たときは coding-system の指定でしたね。
kazu> というわけで、ヘッダ用のコード変換コマンドを作成し、C-cC-d に割り当て
kazu> ました。(最初 C-cC-h にしたら、DEL と間違われて動かなかった。)
そういう方向にきましたか。(^^;
例えば structured field での "=?ISO-2022-JP?B?.....?=" をデコードする
スイッチ mew-decode-quoted を加えたのと同様に、mew-decode-non-mime-chars
とか何とかのスイッチを設けるという方向でも良いかと。
逆をいえば、C-cC-d のアクションに mew-decode-quoted な機能も内包した方が
機能が分散しないで良いのではないでしょうか。
kazu> 「ユーザのためには、頑張って何事もなかったかのように振る舞うべきだ」と
kazu> 思わないところがハッカーらしい。:-)
# 異常を通知するというのは大事なことですね。:-)
# でも『ユーザフレンドリ』なんて言葉を考え始めるとその妥協点に悩むこと
# しばしば。。。
kazu> --かず@化けないと規約違反って分からないんだもん
この気持ちには完全に同意なのですが、ユーザとしてはは既約違反を見つけるこ
とより、ストレスなくメールを読むことが出来ることを望んでいることも確かだ
と思います。Mew は決して文法チェッカーではないわけですし(^^;。
もちろん全自動で寛容である必要はなく、今回のC-cC-d のようなアクションに
よって実現されるので良いと思います。
欲をいえば、それさえも面倒だと思う人のために、オプションで自動でデコード
を行なえると嬉しいかと思います。とは言え、そうしてオプションが増えていく
のもヤなので、厳密さのレベル指定でも設けて行なった方がいいのかも知れませ
んが...
## レベルわけのイメージとしてはこんなんを選択する、と。
## 'strict ... 厳密 : 違反したものに対しては明示的なアクションが必要
## 'moderate ... 適度 : 一般的なMUA対策程度の許容
## 'tolerant ... 寛容 : ナンデモアリ
## ちょっとやりすぎかもな。。。
--- Regards,
Shun-ichi Goto <gotoh at example.com>
R&D Group, TAIYO Corp., Tokyo, JAPAN
Mew-dist メーリングリストの案内