[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 メーリングリストの案内