From ueno ＠ unixuser.org Thu Apr 13 10:52:44 2000 From: ueno ＠ unixuser.org (Daiki Ueno) Date: 13 Apr 2000 10:52:44 +0900 Subject: [Mew-dist 12818] Re: =?ISO-2022-JP?B?Z2V0dGV4dBskQjI9GyhCR251?= =?ISO-2022-JP?B?UEc=?= In-Reply-To: <20000412.200731.08383929.kazu@Mew.org> (Kazu Yamamoto =?ISO-2022-JP?B?KBskQjszS1xPQkknGyhCKSdz?= message of "Wed, 12 Apr 2000 20:07:11 +0900") References: <87purv639y.fsf@mail.unixuser.org> <20000412.194229.39219138.kazu@Mew.org> <87n1mz611y.fsf@mail.unixuser.org> <20000412.200731.08383929.kazu@Mew.org> <20000411.133235.730558203.kc@furukawa.ch.kagu.sut.ac.jp> <20000411.135259.74688482.kazu@Mew.org> <20000412183136M.1000@eccosys.com> <20000412.183705.85347616.kazu@Mew.org> <863dork1rm.fsf@aqua.ocn.ne.jp> Message-ID: <87k8i222dv.fsf@mail.unixuser.org> ;; emacs-mime-ja にも振ります。 >>>>> In [Mew-dist : No.12818] >>>>> Kazu Yamamoto (山本和彦) wrote: > いずれにしろ、lang をコマンドオプションで渡せる方がスマートですね。すみません。それはどうしてでしょうか。 ;; mew-pgp.el を大幅に再構成する必要がないから？ LANG で変化するメッセージ群は自然言語であるわけで、これらの意味を、プログラムから適当に解釈して破綻するのはあまりにもいただけないと思うのですが。 status fd の出力形式は、doc/DETAILS に明確に定義されてます。 >>>>> In [Mew-dist : No.12819] >>>>> Shuhei KOBAYASHI wrote: > gpg に --status-fd 1 を渡して出力を解析するという方法を考えたことが > あるのですが, 何か問題があるでしょうか? --status-fd による出力には > [GNUPG:] という prefix が付くので他の出力との区別は可能ではないかと > 思うのですが, 通常の出力で行頭に "[GNUPG:] " が現れる場合があるかは > 確認していません. おお、なるほど。先程 --output と --status-fd 2 を駆使して shell への依存を排除してみました。 ;; http://cvs.m17n.org/cgi-bin/cvsweb/semi/Attic/pgg-gpg.el#rev1.1.2.25 -- Daiki Ueno From kazu ＠ iijlab.net Thu Apr 13 11:10:49 2000 From: kazu ＠ iijlab.net (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Thu, 13 Apr 2000 11:10:49 +0900 (JST) Subject: [Mew-dist 12831] Re: =?iso-2022-jp?B?Z2V0dGV4dBskQjI9GyhCR251UEc=?= In-Reply-To: <87k8i222dv.fsf@mail.unixuser.org> References: <20000412.183705.85347616.kazu@Mew.org> <863dork1rm.fsf@aqua.ocn.ne.jp> <87k8i222dv.fsf@mail.unixuser.org> Message-ID: <20000413.111049.74688102.kazu@Mew.org> From: Daiki Ueno Subject: [Mew-dist 12831] Re: gettext化GnuPG > ;; mew-pgp.el を大幅に再構成する必要がないから？半分はそうです。 > LANG で変化するメッセージ群は自然言語であるわけで、 > これらの意味を、プログラムから適当に解釈して破綻するのは > あまりにもいただけないと思うのですが。そういう意見も正論だと思います。 GnuPG だけを相手にするならそれでいいでしょう。でも、PGP には、そういう定義はないですよね？ --かず From kazu ＠ iijlab.net Thu Apr 13 11:22:11 2000 From: kazu ＠ iijlab.net (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Thu, 13 Apr 2000 11:22:11 +0900 (JST) Subject: [Mew-dist 12832] Re: =?iso-2022-jp?B?Z2V0dGV4dBskQjI9GyhCR251UEc=?= In-Reply-To: <20000413.111049.74688102.kazu@Mew.org> References: <863dork1rm.fsf@aqua.ocn.ne.jp> <87k8i222dv.fsf@mail.unixuser.org> <20000413.111049.74688102.kazu@Mew.org> Message-ID: <20000413.112211.41698484.kazu@Mew.org> From: Kazu Yamamoto (山本和彦) Subject: [Mew-dist 12832] Re: gettext化GnuPG > > LANG で変化するメッセージ群は自然言語であるわけで、 > > これらの意味を、プログラムから適当に解釈して破綻するのは > > あまりにもいただけないと思うのですが。 > > そういう意見も正論だと思います。 --status-fd で、署名の際どのハッシュ関数が使われたのか表示されるなら使う価値はあると思います。micalg を正しく指定できますから。(ちなみに、僕はこのパラメータの存在意義が理解できませんけど。) しかし、どのハッシュ関数が使われたかは、表示されないようですね。 --かず From yoshiki ＠ xemacs.org Mon Apr 17 13:35:51 2000 From: yoshiki ＠ xemacs.org (Yoshiki Hayashi) Date: 17 Apr 2000 13:35:51 +0900 Subject: FLIM 1.13 mime-decode-string Message-ID: <87em85pcns.fsf@buck.sodan.org> (mime-decode-string "abc" 'x-unknown) なら "abc" が帰ってくるのに、 (mime-decode-string "abc" 'base64) だと error になるのはあんまりなので、以下のようにしてみました。一応 chao 1.14 に対する patch ですが、FLIM 1.13 にも当てたいと思います。どうでしょうか。 # 数日中に反対が無い場合は実力行使します。:-) 2000-04-17 Yoshiki Hayashi * mel.el (mime-decode-string): Return original string when it failed to decode. -------------- next part -------------- Index: mel.el =================================================================== RCS file: /cvs/root/flim/mel.el,v retrieving revision 1.23 diff -u -r1.23 mel.el --- mel.el 1999/12/16 09:13:31 1.23 +++ mel.el 2000/04/17 04:29:04 @@ -199,7 +199,12 @@ the STRING by its value." (let ((f (mel-find-function 'mime-decode-string encoding))) (if f - (funcall f string) + (condition-case nil + (funcall f string) + (error + (message "Wrong Content-Transfer-Encoding: %s" + encoding) + string)) string))) -------------- next part -------------- -- Yoshiki Hayashi From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Mon Apr 17 14:49:10 2000 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 17 Apr 2000 14:49:10 +0900 Subject: FLIM 1.13 mime-decode-string In-Reply-To: Yoshiki Hayashi's message of "17 Apr 2000 13:35:51 +0900" References: <87em85pcns.fsf@buck.sodan.org> Message-ID: >>>>> In [emacs-mime-ja : No.00503] >>>>> "Yoshiki" = Yoshiki Hayashi wrote: Yoshiki> (mime-decode-string "abc" 'x-unknown) Yoshiki> なら "abc" が帰ってくるのに、 Yoshiki> (mime-decode-string "abc" 'base64) Yoshiki> だと error になるのはあんまりなので、以下のようにしてみまし Yoshiki> た。 Yoshiki> 一応 chao 1.14 に対する patch ですが、FLIM 1.13 にも当てたい Yoshiki> と思います。どうでしょうか。個人的には、両方 error の方が良いかなと思います。で、error の種類毎に symbol を決めとく方が良い気がします。 ;; error handling は SEMI 層や MUA 層などの利用者界面の責任にする方が ;; すっきりするんじゃないかと思うのですが。 -- ===『幾千億の分子に分かれても ======================================== 決して忘れない。この宇宙が終るまで』守岡知彦 (MORIOKA Tomohiko) ======================================== Email: ====== From okada ＠ opaopa.org Mon Apr 17 15:03:28 2000 From: okada ＠ opaopa.org (=?ISO-2022-JP?B?GyRCMixFRBsoQiAbJEI3cjBsGyhC?= / Kenichi OKADA) Date: Mon, 17 Apr 2000 15:03:28 +0900 Subject: MIME-View decoder Message-ID: おかだです． Wanderlustにおいて、 Subject: =?ISO-2022-JP?B?V2ViVFYbJEIkKyRpQXckaSRsJD8lVSUpITwlYBsoSgo=?= のようなに、改行コードを含むSubjectのメールを表示する際に、メッセージフレームにおいて、Subject以下のヘッダが highlight されなくなります．とりあえず、どこで直すのが適切かわからないので、報告だけです． -- 岡田健一 URLs: mailto:okada ＠ opaopa.org http://www.opaopa.org From yoshiki ＠ xemacs.org Mon Apr 17 15:35:23 2000 From: yoshiki ＠ xemacs.org (Yoshiki Hayashi) Date: 17 Apr 2000 15:35:23 +0900 Subject: FLIM 1.13 mime-decode-string In-Reply-To: (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko's message of "Mon, 17 Apr 2000 14:49:10 +0900") References: <87em85pcns.fsf@buck.sodan.org> Message-ID: <87og79nsk4.fsf@buck.sodan.org> tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡知彦 / MORIOKA Tomohiko) writes: > 個人的には、両方 error の方が良いかなと思います。 > > で、error の種類毎に symbol を決めとく方が良い気がします。 > > ;; error handling は SEMI 層や MUA 層などの利用者界面の責任にする方が > ;; すっきりするんじゃないかと思うのですが。 mmbuffer の mime-entity-content 等が mime-decode-string を呼んでいるのですが、どうするのが良いでしょうか? # 私の知る限りでは SEMI 層は mime-decode-string を直接呼んで # いないです。 -- Yoshiki Hayashi From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Mon Apr 17 15:45:10 2000 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 17 Apr 2000 15:45:10 +0900 Subject: FLIM 1.13 mime-decode-string In-Reply-To: Yoshiki Hayashi's message of "17 Apr 2000 15:35:23 +0900" References: <87em85pcns.fsf@buck.sodan.org> <87og79nsk4.fsf@buck.sodan.org> Message-ID: >>>>> In [emacs-mime-ja : No.00506] >>>>> "Yoshiki" = Yoshiki Hayashi wrote: Yoshiki> > 個人的には、両方 error の方が良いかなと思います。 Yoshiki> > Yoshiki> > で、error の種類毎に symbol を決めとく方が良い気がします。 Yoshiki> > Yoshiki> > ;; error handling は SEMI 層や MUA 層などの利用者界面の責任 Yoshiki> > ;; にする方がすっきりするんじゃないかと思うのですが。 Yoshiki> mmbuffer の mime-entity-content 等が mime-decode-string を呼 Yoshiki> んでいるのですが、どうするのが良いでしょうか? 問題を表現する error を起こすのが良いんじゃないでしょうか？ Yoshiki> # 私の知る限りでは SEMI 層は mime-decode-string を直接呼んで Yoshiki> # いないです。なるほど。ふと思ったんですが、MUA 毎に error handler を設定する機構があると便利かも知れませんね。 ;; MUA 固有の backend でやるのかも知れませんが。 -- ===『幾千億の分子に分かれても ======================================== 決して忘れない。この宇宙が終るまで』守岡知彦 (MORIOKA Tomohiko) ======================================== Email: ====== From yoshiki ＠ xemacs.org Mon Apr 17 16:26:58 2000 From: yoshiki ＠ xemacs.org (Yoshiki Hayashi) Date: 17 Apr 2000 16:26:58 +0900 Subject: FLIM 1.13 mime-decode-string In-Reply-To: (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko's message of "Mon, 17 Apr 2000 15:45:10 +0900") References: <87em85pcns.fsf@buck.sodan.org> <87og79nsk4.fsf@buck.sodan.org> Message-ID: <87ln2dnq65.fsf@buck.sodan.org> tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡知彦 / MORIOKA Tomohiko) writes: > >>>>> In [emacs-mime-ja : No.00506] > >>>>> "Yoshiki" = Yoshiki Hayashi wrote: > > Yoshiki> > 個人的には、両方 error の方が良いかなと思います。 > Yoshiki> > > Yoshiki> > で、error の種類毎に symbol を決めとく方が良い気がします。 > Yoshiki> > > Yoshiki> > ;; error handling は SEMI 層や MUA 層などの利用者界面の責任 > Yoshiki> > ;; にする方がすっきりするんじゃないかと思うのですが。 > > Yoshiki> mmbuffer の mime-entity-content 等が mime-decode-string を呼 > Yoshiki> んでいるのですが、どうするのが良いでしょうか? > > 問題を表現する error を起こすのが良いんじゃないでしょうか？なるほど。 error が起こったときに SEMI 側で 7bit で decode しようとしても raw data を手に入れられないので、それをするための関数を追加したいのですが良いでしょうか。mmbuffer なら (luna-define-method mime-entity-content-data ((entity mime-buffer-entity)) (save-excursion (set-buffer (mime-buffer-entity-buffer-internal entity)) (buffer-substring (mime-buffer-entity-body-start-internal entity) (mime-buffer-entity-body-end-internal entity)))) みたいな感じですが。 # 名前は適当です。良い名前募集。 -- Yoshiki Hayashi From okazaki ＠ be.to Mon Apr 17 16:26:40 2000 From: okazaki ＠ be.to (OKAZAKI Tetsurou) Date: Mon, 17 Apr 2000 16:26:40 +0900 Subject: mime section In-Reply-To: In your message of "Mon, 17 Apr 2000 15:40:51 +0900" References: Message-ID: <86g0sljihb.wl@dolphin.be.to> 岡崎です。emacs-mime-ja に Cc します。 In the ML [Wanderlust 04623] Takeshi Chiba wrote: > ちょっと MIME 関連の処理に関して疑問があるのですが、どのような作りになっ > ているか教えて頂けないでしょうか？ > 以下のような、MIME形式のメールを表示した時に、"foobarに添付されたファ > イル"のセクション表記が 2.1.1 と表示されますが、このセクションは、IMAP > では、2.1.1 ではなく 2.1 です。 > 2.1 ではなく、2.1.1 として扱うのには何か理由があるのでしょうか？ > 何かしょうもない質問ですが、現状の仕様で 2.2 のセクションがあるケース > はありえないような気がします。私が何か考え違いをしているのでしょうか？ > --------- 例：ここから -------- > Content-Type: MultiPart/Mixed;Boundary="---------955594378-9884703" > [1 ] > hogehoge > [2 ] > Content-Type: multipart/mixed; boundary="BoUnDaRy_StRiNg_ThAt_NeVeR_eXiStS" > hogehogeに添付されたメールfoobar > [2.1.1 ] > foobarに添付されたファイル > --------- 例：ここまで -------- 私も詳しい事は判っていませんが、 User-Agent: Wanderlust/1.1.1 REMI/1.14.1 Chao/1.14.1 APEL/10.2 Emacs/20.6 (i386--freebsd) MULE/4.0 (HANANOEN) という環境で再現できました。また、メール冒頭の "hogehoge" がない場合は、 [1 ] のボタンは表示されずに [1.1 ] hogehogeに添付されたメールfoobar [1.2 ] foobarに添付されたファイルの様に表示されました。 -- 岡崎哲朗 From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Mon Apr 17 17:28:19 2000 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 17 Apr 2000 17:28:19 +0900 Subject: FLIM 1.13 mime-decode-string In-Reply-To: Yoshiki Hayashi's message of "17 Apr 2000 16:26:58 +0900" References: <87em85pcns.fsf@buck.sodan.org> <87og79nsk4.fsf@buck.sodan.org> <87ln2dnq65.fsf@buck.sodan.org> Message-ID: >>>>> In [emacs-mime-ja : No.00508] >>>>> "Yoshiki" = Yoshiki Hayashi wrote: Yoshiki> error が起こったときに SEMI 側で 7bit で decode しようとして Yoshiki> も raw data を手に入れられないので、それをするための関数を追 Yoshiki> 加したいのですが良いでしょうか。mmbuffer なら Yoshiki> (luna-define-method mime-entity-content-data ((entity mime-buffer-entity)) Yoshiki> (save-excursion Yoshiki> (set-buffer (mime-buffer-entity-buffer-internal entity)) Yoshiki> (buffer-substring (mime-buffer-entity-body-start-internal entity) Yoshiki> (mime-buffer-entity-body-end-internal entity)))) Yoshiki> みたいな感じですが。 Yoshiki> # 名前は適当です。良い名前募集。 entity-content は Content-Transfer-Encoding を復号した後の byte 列を指す用語のつもりなので、この名前は良くないと思います。例： \begin{function}{mime-entity-content}{\textit{entity}} \textit{entity} の内容（byte 列）を返す。 \end{function} \begin{function}{mime-insert-entity-content}{\textit{entity}} \textit{entity} の内容（byte 列）を現在位置に挿入する。 \end{function} \begin{function}{mime-write-entity-content} {\textit{entity} \textit{file}} \textit{entity} の内容を \textit{file} に書き出す。 \end{function} raw data というのは entity (body) の network 表現のことでしょうか？これらに関しては entity(-body) を用いることになっているようです。例： \begin{function}{mime-insert-entity} {\textit{entity}} \textit{entity} のネットワーク表現を現在位置に挿入する。 \end{function} \begin{function}{mime-write-entity} {\textit{entity} \textit{file}} \textit{entity} のネットワーク表現を \textit{file} に書き出す \end{function} \begin{function}{mime-write-entity-body} {\textit{entity} \textit{file}} \textit{entity} の\body のネットワーク表現を \textit{file} に書き出す \end{function} また、某文書によれば entity body の network 表現を文字列として返す関数のために mime-entity-body を予約しているそうです。（mime-entity-to-string, mime-insert-entity-body も予約してるらしいです）そういう訳で、FLIM 1.14 に mime-entity-body を追加することに賛成します。 -- ===『幾千億の分子に分かれても ======================================== 決して忘れない。この宇宙が終るまで』守岡知彦 (MORIOKA Tomohiko) ====================== Email: ====== From yoshiki ＠ xemacs.org Mon Apr 17 18:01:26 2000 From: yoshiki ＠ xemacs.org (Yoshiki Hayashi) Date: 17 Apr 2000 18:01:26 +0900 Subject: EMY 1.13.5 Message-ID: <8766thnlsp.fsf@buck.sodan.org> 少しずつ変更がされているにも関わらず release していなかったので、release します。懸案の key binding は案がまとまらなかったのでそのままになっています。 # user の意見が無いと何とも言えないので。;-) mime-display-gzipped は、守岡さんの説得に屈して decode-coding-string を使うようになっています。 # 気分的には decode-coding-region は XEmacs では buffer から # stream を開いて、binary で byte sequence にしてから、 # buffer に write stream を開いて与えられた coding system で # 内部表現に変換しているので非常に良いんだけど。:-P 一応変更としては、C-u c で Content-Transfer-Encoding を聞くようになりました。ただし、base64 や quoted-printable を 7bit か 8bit として送ってきたときにしか役に立ちません。 -- Yoshiki Hayashi