From yoichi ＠ eken.phys.nagoya-u.ac.jp Sun Nov 3 15:56:22 2002 From: yoichi ＠ eken.phys.nagoya-u.ac.jp (Yoichi NAKAYAMA) Date: Sun, 03 Nov 2002 15:56:22 +0900 Subject: reedit message by WL/SEMI Message-ID: <87of97uoo9.wl@eken.phys.nagoya-u.ac.jp> なかやまです Wanderlust で、wl-summary-reedit した時に、mime-edit のバッファでは decode されるべきでないパート(message/rfc822 とか *.diff や *.el を application/octet-stream で添付したものとか)まで decode されてしまい、そうなった場合、再編集後に送信されるメッセージではそれらのパートの encoding がおかしくなってしまいます。少し調べて見た所、mime-edit.el で以下のようにすれば Wanderlust ではうまく機能するみたいなのですが、こういう変更は SEMI 的にはどないなもんでしょうか？ ;; not-decode-text の意図がわからなかったのですが、これがもし、text part ;; についての「decode する/しない」を規定するだけのものだとしたらこの変更 ;; でよさそうに思います。 T-gnus の gnus-article-mime-edit-article-setup を見るとそこでは message/rfc822 を特別扱いして SEMI を騙しているようです。Wanderlust での問題はまさにその部分の話だと思うので、T-gnus のほうではどういう事情でこのようになってるんでしょうか。 ;; ちなみに T-gnus では message/rfc822 以外は大丈夫なんでしょうか？ Regards, -- Yoichi Nakayama -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: mime-edit.diff 型: application/octet-stream サイズ: 1168 バイト説明: 無し URL: From Katsumi ＠ yamaoka.cc Sun Nov 3 23:20:16 2002 From: Katsumi ＠ yamaoka.cc (Katsumi ＠ yamaoka.cc) Date: Sun, 03 Nov 2002 23:20:16 +0900 Subject: reedit message by WL/SEMI References: <87of97uoo9.wl@eken.phys.nagoya-u.ac.jp> Message-ID: >>>>> In [emacs-mime-ja : No.01105] >>>>> Yoichi NAKAYAMA wrote: 中山さん> 少し調べて見た所、mime-edit.el で以下のようにすれば中山さん> Wanderlust ではうまく機能するみたいなのですが、こういう変更中山さん> は SEMI 的にはどないなもんでしょうか？中山さん> ;; not-decode-text の意図がわからなかったのですが、これがも中山さん> ;; し、text partについての「decode する/しない」を規定するだ中山さん> ;; けのものだとしたらこの変更でよさそうに思います。 ;; そうすると、たぶん application/emacs-lisp なんていうパートに ;; 含まれる日本語はデコードされなくなるのですね(?)。まあ、それも ;; 良いのではないでしょうか。中山さん> T-gnus の gnus-article-mime-edit-article-setup を見るとそこ中山さん> ではmessage/rfc822 を特別扱いして SEMI を騙しているようです。中山さん> Wanderlust での問題はまさにその部分の話だと思うので、T-gnus 中山さん> のほうではどういう事情でこのようになってるんでしょうか。 2001-02-28 Katsumi Yamaoka * lisp/gnus-art.el (gnus-article-mime-edit-article-setup): Leave the forwarded parts undecoded. これはまったくのやっつけ仕事です。うーむ、その先のはてしない問題が見えてしまったからだったのか、あるいはたまたま mime-edit-again が返す結果が目を被うようなサンプルを見てしまったからなのか。ともかく、いい加減に切り上げて蓋をしてしまったような記憶がありますね。 ;; なお mime-edit-again が非常に複雑な MIME 構造に対応していない ;; ことは既知で、それは Gnus の mml-to-mime も同様です。中山さん> ;; ちなみに T-gnus では message/rfc822 以外は大丈夫なんでしょ中山さん> ;; うか？ご想像の通り。:-p > +2002-11-03 Yoichi NAKAYAMA > + > + * mime-edit.el (mime-edit-decode-single-part-in-buffer): Decode text > + part only. 何となく、漠然と、いろいろ考えると、SEMI 的には中山さんの変更が正しい気がします。 -- Katsumi ＠ Yamaoka.cc 埼玉県さいたま市 From yoichi ＠ eken.phys.nagoya-u.ac.jp Mon Nov 4 22:16:01 2002 From: yoichi ＠ eken.phys.nagoya-u.ac.jp (Yoichi NAKAYAMA) Date: Mon, 04 Nov 2002 22:16:01 +0900 Subject: reedit message by WL/SEMI In-Reply-To: References: <87of97uoo9.wl@eken.phys.nagoya-u.ac.jp> Message-ID: <87k7jth3vy.wl@eken.phys.nagoya-u.ac.jp> なかやまですコメントの部分のみに反応して申し訳ないのですが… At Sun, 03 Nov 2002 23:20:16 +0900, Katsumi ＠ Yamaoka.cc wrote: 山岡さん> ;; そうすると、たぶん application/emacs-lisp なんていうパートに山岡さん> ;; 含まれる日本語はデコードされなくなるのですね(?)。まあ、それも山岡さん> ;; 良いのではないでしょうか。新たな問題を引き起こしちゃいますでしょうか？少なくとも、Content-Transfer-Encoding が書いてある場合に、reedit 時にそれと矛盾するようにデコードされてしまうことは無くなると思います。山岡さん> ;; なお mime-edit-again が非常に複雑な MIME 構造に対応していない山岡さん> ;; ことは既知で、それは Gnus の mml-to-mime も同様です。あまり複雑な MIME message は作ったことが(想像したことも)なかったので知りませんでした。参考までに簡単な例(とか、どっかで話が出ていたとかの情報)があれば教えていただけるとありがたいです。 best regards, -- Yoichi Nakayama ;; リリースがせまっている wl-2_10 では T-gnus と同様の変更を入れておくべき ;; でしょうかね。 From yamaoka ＠ jpl.org Tue Nov 5 10:12:50 2002 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: Tue, 05 Nov 2002 10:12:50 +0900 Subject: reedit message by WL/SEMI References: <87of97uoo9.wl@eken.phys.nagoya-u.ac.jp> <87k7jth3vy.wl@eken.phys.nagoya-u.ac.jp> Message-ID: >>>>> In [semi-gnus-ja : No.7146] >>>>> Yoichi NAKAYAMA wrote: 山岡> ;; そうすると、たぶん application/emacs-lisp なんていうパートに山岡> ;; 含まれる日本語はデコードされなくなるのですね(?)。まあ、それも山岡> ;; 良いのではないでしょうか。中山さん> 新たな問題を引き起こしちゃいますでしょうか？すみません、誤解していました。しばらく Gnus ばかり使っているうちに疎くなってしまいましたが mime-edit-again に限定して考えて良いのですね。中山さん> 少なくとも、Content-Transfer-Encoding が書いてある場合に、中山さん> reedit 時にそれと矛盾するようにデコードされてしまうことは無中山さん> くなると思います。はい、結構だと思います。 -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: 無し型: application/octet-stream サイズ: 174 バイト説明: 無し URL: -------------- next part -------------- ;; ↑このパートは SEMI MUA では普通に見えますよね(?)。山岡> ;; なお mime-edit-again が非常に複雑な MIME 構造に対応していない山岡> ;; ことは既知で、それは Gnus の mml-to-mime も同様です。中山さん> あまり複雑な MIME message は作ったことが(想像したことも)なかっ中山さん> たので知りませんでした。参考までに簡単な例(とか、どっかで話中山さん> が出ていたとかの情報)があれば教えていただけるとありがたいで中山さん> す。うーむ、偶然見つかることはよくあるのですが、例を作ろうとすると意外に難しい。フォワードのフォワードみたいなものでおかしくなったような気がするのですが、今回はご勘弁を。^^;; 中山さん> ;; リリースがせまっている wl-2_10 では T-gnus と同様の変更を中山さん> ;; 入れておくべきでしょうかね。 ;; 極めて美しくないものですが、まあ無いよりはマシですかねえ。:-p -- Katsumi Yamaoka From yoichi ＠ eken.phys.nagoya-u.ac.jp Tue Nov 5 13:40:39 2002 From: yoichi ＠ eken.phys.nagoya-u.ac.jp (Yoichi NAKAYAMA) Date: Tue, 05 Nov 2002 13:40:39 +0900 Subject: reedit message by WL/SEMI In-Reply-To: References: <87of97uoo9.wl@eken.phys.nagoya-u.ac.jp> <87k7jth3vy.wl@eken.phys.nagoya-u.ac.jp> Message-ID: <877kfs1veg.wl@eken.phys.nagoya-u.ac.jp> なかやまです山岡さん> すみません、誤解していました。しばらく Gnus ばかり使っているうち山岡さん> に疎くなってしまいましたが mime-edit-again に限定して考えて良い山岡さん> のですね。 mime-edit-decode-single-part-in-buffer が mime-edit-again でしか使われていないので私はそういう認識をしているのですが、 mime-edit-decode-single-part-in-buffer は not documented なのでよくわかりません。上の理解が正しいのであれば別の用途で用いられないように、 For mime-edit-again 的な description を書いておいた方がよいかもしれません。山岡さん> 強いて言うならば、MIME-View はこんなパートもデコードして表示して山岡さん> しまうので、reedit の対象に含めたくなりますが、それはたぶん違う山岡さん> 問題でしょう。これは、forward するメッセージが mime-edit で読めない(preview では見えるのに)所を、見えるようにしたいだの改竄したいだのという要求と同じ問題ですよね。中山> ;; リリースがせまっている wl-2_10 では T-gnus と同様の変更を中山> ;; 入れておくべきでしょうかね。山岡さん> ;; 極めて美しくないものですが、まあ無いよりはマシですかねえ。:-p semi に変更を入れるにしても、古い semi を使っている場合に問題になっちゃうので入れておきます。 ;; semi の変更で使えなくなってしまったりなことがあるかもしれませんが ;; T-gnus と一蓮托生と思っておきます… :P -- Yoichi Nakayama From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Tue Nov 5 19:46:25 2002 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQg==?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 05 Nov 2002 19:46:25 +0900 Subject: What does get-mother arg. of mime-preview-find-boundary-info mean? In-Reply-To: Yoichi NAKAYAMA's message of "Thu, 17 Oct 2002 03:21:58 +0900" References: <87elarc0lv.wl@eken.phys.nagoya-u.ac.jp> <874rbmkzw9.wl@eken.phys.nagoya-u.ac.jp> Message-ID: もはや、FLIM/SEMI の code を半分（以上）忘れてる守岡です。このところ反応が悪くてごめんなさい。でも、XEmacs UTF-2000 をいじってるうちに MIME-charset の撰択がおかしくなってきて、そろそろ encode まわりをまたいじらなあかんなぁと思う今日この頃です。 >>>>> [emacs-mime-ja : No.01101] にて >>>>> “Yoichi”= Yoichi NAKAYAMA さま曰く: Yoichi> > mime-preview-find-boundary-info の get-mother の意図する効用 Yoichi> > というのはどういうものでしょうか？ひとつ上の親の境界を調べるという意味のようです。 Yoichi> 別件で FLIM とか SEMI とか読んだら副作用で読めるようになってし Yoichi> まったので結局自分で読みました :) ぱちぱち。(^_^) Yoichi> (header) Yoichi> 1 Yoichi> (header) <== ここで get-mother=t なら 1 全体を取る; nil なら 1 の header のみ (*) Yoichi> 1.1.1 Yoichi> ～ <== ここでは get-mother=t でも 1.1.1 のみ Yoichi> 1.1.2 Yoichi> ～ <== (**) Yoichi> 2 Yoichi> ～おぼろげな記憶によれば、1.1.1 の場合、get-mother=t なら 1.1 全体になります。ただ、1.1 が message/rfc822 だったりすると陽に見えないので判りにくいですが（上記はそういう場合の図でしょうか？）。 (*) は曖昧で、実は 1 の場合と 1.1 の場合がありそうです。実は 1 だった場合、get-mother=t なら message 全体となりますし、実は 1.1 なら 1 全体となるのが正しいといえます。 (**) の場合、get-mother=t なら 1.1 全体となるのが正しいといえます。 Yoichi> ということを意図してるのだと思いますが、次の次のパートが存在し Yoichi> ないとき、例えば上の図のように 2 までしかないときについては論 Yoichi> 理がおかしいために(*) とか (**) のところで間違えて (point-max) Yoichi> を p-end に入れてしまいます。とすると、(*) の場合は (point-max) ではまずい場合と、(point-max) で良い場合があります。 (**) の場合、(point-max) ではまずいといえます。 Yoichi> 添付のようにして直っているような気がしているのですがいかがでしょ Yoichi> うか。 Yoichi> ;; かなり眠い状態で考えてたので、実はおかしいのは自分の頭の中 Yoichi> ;; というオチだったりして… ;; 私が tm-view/mime-view 書いてた頃も眠いか頭おかしいか精神がおかしい ;; 時が多かった気がします。(^_^;; Yoichi> [2 mime-view.diff ] Yoichi> Index: mime-view.el Yoichi> =================================================================== Yoichi> RCS file: /cvs/root/semi/mime-view.el,v Yoichi> retrieving revision 1.151.2.11 Yoichi> diff -u -r1.151.2.11 mime-view.el Yoichi> --- mime-view.el 14 Jun 2001 14:34:19 -0000 1.151.2.11 Yoichi> +++ mime-view.el 16 Oct 2002 18:18:29 -0000 Yoichi> @@ -1503,7 +1503,6 @@ Yoichi> ) Yoichi> (get-mother Yoichi> (save-excursion Yoichi> - (goto-char p-end) Yoichi> (catch 'tag Yoichi> (let (e i) Yoichi> (while (setq e Yoichi> @@ -1511,12 +1510,14 @@ Yoichi> (point) 'mime-view-entity)) Yoichi> (goto-char e) Yoichi> (let ((rc (mime-entity-node-id Yoichi> - (get-text-property (1- (point)) Yoichi> + (get-text-property (point) Yoichi> 'mime-view-entity)))) Yoichi> (or (and (>= (setq i (- (length rc) len)) 0) Yoichi> (equal entity-node-id (nthcdr i rc))) Yoichi> (throw 'tag nil))) Yoichi> - (setq p-end e))) Yoichi> + (setq p-end (or (next-single-property-change Yoichi> + (point) 'mime-view-entity) Yoichi> + (point-max))))) Yoichi> (setq p-end (point-max)))) Yoichi> )) Yoichi> (vector p-beg p-end entity))) 正直いって今の私ではこの修整が正しいかどうかは判断できないのですが、元の code に関していえば、text-property の境界の挙動に関する知識が混乱してた（あるいは実装も混乱してた?）時期の香りがするので、おそらく中山さんの修整が正しいような気がします。いずれにしても修整ありがとうございました。 ;; test suit が欲しい所ですね。 -- ┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━ ││ ─ │ ─ ／ ─ ┼─ ┬ ─ ─┼ ┬┴─ ┼┼─┼|〓━─┼ 守岡知彦 (MORIOKA Tomohiko) ─ ─┬ ┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ From yoichi ＠ eken.phys.nagoya-u.ac.jp Tue Nov 5 20:28:47 2002 From: yoichi ＠ eken.phys.nagoya-u.ac.jp (Yoichi NAKAYAMA) Date: Tue, 05 Nov 2002 20:28:47 +0900 Subject: What does get-mother arg. of mime-preview-find-boundary-info mean? In-Reply-To: References: <87elarc0lv.wl@eken.phys.nagoya-u.ac.jp> <874rbmkzw9.wl@eken.phys.nagoya-u.ac.jp> Message-ID: <87of94s1ao.wl@eken.phys.nagoya-u.ac.jp> なかやまです Yoichi> > mime-preview-find-boundary-info の get-mother の意図する効用 Yoichi> > というのはどういうものでしょうか？ tomo> ひとつ上の親の境界を調べるという意味のようです。あ、嘘の description を入れてしまったかも Yoichi> (header) Yoichi> 1 Yoichi> (header) <== ここで get-mother=t なら 1 全体を取る; nil なら 1 の header のみ (*) Yoichi> 1.1.1 Yoichi> ～ <== ここでは get-mother=t でも 1.1.1 のみ Yoichi> 1.1.2 Yoichi> ～ <== (**) Yoichi> 2 Yoichi> ～ tomo> おぼろげな記憶によれば、1.1.1 の場合、get-mother=t なら 1.1 全体になり tomo> ます。ただ、1.1 が message/rfc822 だったりすると陽に見えないので判りに tomo> くいですが（上記はそういう場合の図でしょうか？）。 tomo> (*) は曖昧で、実は 1 の場合と 1.1 の場合がありそうです。実は 1 だった tomo> 場合、get-mother=t なら message 全体となりますし、実は 1.1 なら 1 全体 tomo> となるのが正しいといえます。はい、図は message/rfc822 を 1 として添付した例です。 (mime-entity-node-id (get-text-property (point) 'mime-view-entity)) で調べてみたところ、message/rfc822 の場合、 tag 直上で 1 、ヘッダ領域で 1.1 がそれぞれ生で見えますね。 > (**) の場合、get-mother=t なら 1.1 全体となるのが正しいといえます。うーむ。となると僕の修正以前からその意図とは違う動作になっているような…。 Yoichi> ということを意図してるのだと思いますが、次の次のパートが存在し Yoichi> ないとき、例えば上の図のように 2 までしかないときについては論 Yoichi> 理がおかしいために(*) とか (**) のところで間違えて (point-max) Yoichi> を p-end に入れてしまいます。僕が修正した問題は、元のコードだと「次の次」の entity の先頭に飛んで、一歩後ろを見て「次」の entity の情報を調べていた (真なら「次の次」の先頭か point-max を返す) ので、「次の次」の entity が存在しない時は調べる前にやめちゃうという問題で、 → 「次」に飛んで、そこで足元を見て「次」の entity の情報を調べる (真なら「次の次」の先頭か point-max を返す) ようにしました。というわけで論理の bug を取っただけで大筋の動作は変えていません。僕の読みでは、find-boundary-info の動作としては、mime-preview-follow-current-entity で使われていることをふまえて、実際の動作を検証した結果、 get-mother=t なら、「自分と自分から生えた枝」を取るという動作と取りました。で、そういう description 付けちゃったんですが、間違ってますかねぇ。 ;; で、どうして get-mother って名前なのかという疑問は残ったわけです。 -- Yoichi Nakayama From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Tue Nov 5 20:31:34 2002 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQg==?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 05 Nov 2002 20:31:34 +0900 Subject: reedit message by WL/SEMI In-Reply-To: Yoichi NAKAYAMA's message of "Sun, 03 Nov 2002 15:56:22 +0900" References: <87of97uoo9.wl@eken.phys.nagoya-u.ac.jp> Message-ID: >>>>> [emacs-mime-ja : No.01105] にて >>>>> “Yoichi”= Yoichi NAKAYAMA さま曰く: Yoichi> Wanderlust で、wl-summary-reedit した時に、mime-edit のバッファ Yoichi> ではdecode されるべきでないパート(message/rfc822 とか *.diff Yoichi> や *.el をapplication/octet-stream で添付したものとか)まで Yoichi> decode されてしまい、そうなった場合、再編集後に送信されるメッ Yoichi> セージではそれらのパートのencoding がおかしくなってしまいます。 Yoichi> 少し調べて見た所、mime-edit.el で以下のようにすれば Wanderlust Yoichi> ではうまく機能するみたいなのですが、こういう変更は SEMI 的には Yoichi> どないなもんでしょうか？ Yoichi> ;; not-decode-text の意図がわからなかったのですが、これがもし、 Yoichi> ;; text partについての「decode する/しない」を規定するだけのも Yoichi> ;; のだとしたらこの変更でよさそうに思います。 not-decode-text に関する記憶はおぼろげなんですが(^_^;、確か message 全体が既に code 変換されているようなものを扱うためのものだったと思います。とすると、encoding が 7bit, 8bit, binary 以外であることを check しないとまずいはずですね。あと、(eq type 'text) でなくても charset が nil でなければ code 変換処理を呼んだ方が良いような気がします。それにしてもそもそもこんな風に decode して再 encode するのは良くないですよね。やっぱ mime-edit 作り直さないと（といってもう２年が経ってしまった気がしますが(^_^;;;）。 ;; とりあえず作りかけの code を格納した枝を作った方が良いかもという気 ;; も。 -- ┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━ ││ ─ │ ─ ／ ─ ┼─ ┬ ─ ─┼ ┬┴─ ┼┼─┼|〓━─┼ 守岡知彦 (MORIOKA Tomohiko) ─ ─┬ ┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Tue Nov 5 20:39:40 2002 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQg==?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 05 Nov 2002 20:39:40 +0900 Subject: reedit message by WL/SEMI In-Reply-To: Katsumi@yamaoka.cc's message of "Sun, 03 Nov 2002 23:20:16 +0900" References: <87of97uoo9.wl@eken.phys.nagoya-u.ac.jp> Message-ID: >>>>> In [emacs-mime-ja : No.01106] >>>>> "山岡さん" = Katsumi ＠ yamaoka.cc wrote: 山岡さん> ;; なお mime-edit-again が非常に複雑な MIME 構造に対応してい山岡さん> ;; ないことは既知で、それは Gnus の mml-to-mime も同様です。 ;; mime-edit の場合、再帰的に書いてあるはずなので、entity 階層の複雑さ ;; にはあまり関係ない気がします。ただまあ、確かに、複雑な message の場 ;; 合、おかしい場合の崩れ方も複雑になると思いますが、崩れ方は規則的だ ;; と思います。:-) -- 守岡知彦 (MORIOKA Tomohiko) From yamaoka ＠ jpl.org Tue Nov 5 21:10:41 2002 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: Tue, 05 Nov 2002 21:10:41 +0900 Subject: reedit message by WL/SEMI References: <87of97uoo9.wl@eken.phys.nagoya-u.ac.jp>

Message-ID: >>>>> In >>>>> 守岡知彦さん wrote: 山岡> ;; なお mime-edit-again が非常に複雑な MIME 構造に対応してい山岡> ;; ないことは既知で、それは Gnus の mml-to-mime も同様です。守岡さん> ;; mime-edit の場合、再帰的に書いてあるはずなので、entity 階守岡さん> ;; 層の複雑さにはあまり関係ない気がします。ただまあ、確かに、守岡さん> ;; 複雑な message の場合、おかしい場合の崩れ方も複雑になると守岡さん> ;; 思いますが、崩れ方は規則的だと思います。:-) ;; すみません、どうやら濡れ衣だったようです。これでもかあれでも ;; かと試してみましたが、不具合は発見できなかったし、そもそも ;; tm-edit.el の時代から安定していたように見えるので、完璧にぼく ;; の勘違いなのだと思います。失礼いたしました。^^;; -- Katsumi Yamaoka From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Tue Nov 5 21:27:25 2002 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQg==?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 05 Nov 2002 21:27:25 +0900 Subject: What does get-mother arg. of mime-preview-find-boundary-info mean? In-Reply-To: Yoichi NAKAYAMA's message of "Tue, 05 Nov 2002 20:28:47 +0900" References: <87elarc0lv.wl@eken.phys.nagoya-u.ac.jp> <874rbmkzw9.wl@eken.phys.nagoya-u.ac.jp> <87of94s1ao.wl@eken.phys.nagoya-u.ac.jp> Message-ID: >>>>> <87of94s1ao.wl ＠ eken.phys.nagoya-u.ac.jp> にて >>>>> “Yoichi”= Yoichi NAKAYAMA さま曰く: Yoichi> > mime-preview-find-boundary-info の get-mother の意図する効用 Yoichi> > というのはどういうものでしょうか？ tomo> ひとつ上の親の境界を調べるという意味のようです。 Yoichi> あ、嘘の description を入れてしまったかも Yoichi> (header) Yoichi> 1 Yoichi> (header) <== ここで get-mother=t なら 1 全体を取る; nil なら 1 の header のみ (*) Yoichi> 1.1.1 Yoichi> ～ <== ここでは get-mother=t でも 1.1.1 のみ Yoichi> 1.1.2 Yoichi> ～ <== (**) Yoichi> 2 Yoichi> ～ tomo> おぼろげな記憶によれば、1.1.1 の場合、get-mother=t なら 1.1 全体 tomo> になります。ただ、1.1 が message/rfc822 だったりすると陽に見えな tomo> いので判りにくいですが（上記はそういう場合の図でしょうか？）。 tomo> (*) は曖昧で、実は 1 の場合と 1.1 の場合がありそうです。実は 1 tomo> だった場合、get-mother=t なら message 全体となりますし、実は 1.1 tomo> なら 1 全体となるのが正しいといえます。 Yoichi> はい、図は message/rfc822 を 1 として添付した例です。 Yoichi> (mime-entity-node-id (get-text-property (point) 'mime-view-entity)) Yoichi> で調べてみたところ、message/rfc822 の場合、 tag 直上で 1 、ヘッ Yoichi> ダ領域で1.1 がそれぞれ生で見えますね。 Yoichi> > (**) の場合、get-mother=t なら 1.1 全体となるのが正しいとい Yoichi> > えます。 Yoichi> うーむ。となると僕の修正以前からその意図とは違う動作になってい Yoichi> るような…。そのようですね。get-mother というより with-children に近いですね。API 体系ととして考えると、別に mime-preview-move-to-upper のような親の情報を得るための関数があれば、それと mime-preview-find-boundary-info を組み合わせれば親の情報が得られる訳で、get-mother みたいな不自然な option は要らない気がします。一方、子孫込みの自分の全領域を得る情報はあった方が良いと思います。という訳で、with-children という定義にすることを提案したいと思います。また、SEMI 1.15 API を作る時に、mime-preview-move-to-upper の (mime-preview-quit) なし版というか副作用なし版の関数を追加してはどうかと思います。ところで、mime-preview-find-boundary-info の SEMI での用例は mime-preview-follow-current-entity とmime-preview-toggle-display だけで、ChangeLog を見た感じでもなんとなくcheck が甘そうな香りがします。 (^_^;; いずれにせよ、申し訳ないです。 Yoichi> ということを意図してるのだと思いますが、次の次のパートが存在し Yoichi> ないとき、例えば上の図のように 2 までしかないときについては論 Yoichi> 理がおかしいために(*) とか (**) のところで間違えて (point-max) Yoichi> を p-end に入れてしまいます。 Yoichi> 僕が修正した問題は、元のコードだと Yoichi> 「次の次」の entity の先頭に飛んで、一歩後ろを見て「次」の Yoichi> entity の情報を調べていた (真なら「次の次」の先頭か point-max Yoichi> を返す) Yoichi> ので、「次の次」の entity が存在しない時は調べる前にやめちゃう Yoichi> という問題で、 Yoichi> → 「次」に飛んで、そこで足元を見て「次」の entity の情報を調べる Yoichi> (真なら「次の次」の先頭か point-max を返す) Yoichi> ようにしました。というわけで論理の bug を取っただけで大筋の動 Yoichi> 作は変えていません。僕の読みでは、find-boundary-info の動作と Yoichi> しては、mime-preview-follow-current-entityで使われていることを Yoichi> ふまえて、実際の動作を検証した結果、 Yoichi> get-mother=t なら、「自分と自分から生えた枝」を取る Yoichi> という動作と取りました。で、そういう description 付けちゃった Yoichi> んですが、間違ってますかねぇ。 Yoichi> ;; で、どうして get-mother って名前なのかという疑問は残ったわ Yoichi> ;; けです。という訳で、これを追認するということでいかがでしょうか？その場合、get-mother を with-children とかに変えてはいかがでしょうか？では。 -- ┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━ ││ ─ │ ─ ／ ─ ┼─ ┬ ─ ─┼ ┬┴─ ┼┼─┼|〓━─┼ 守岡知彦 (MORIOKA Tomohiko) ─ ─┬ ┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Wed Nov 6 19:50:13 2002 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQg==?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 06 Nov 2002 19:50:13 +0900 Subject: reedit message by WL/SEMI In-Reply-To: Yoichi NAKAYAMA's message of "Tue, 05 Nov 2002 13:40:39 +0900" References: <87of97uoo9.wl@eken.phys.nagoya-u.ac.jp> <87k7jth3vy.wl@eken.phys.nagoya-u.ac.jp> <877kfs1veg.wl@eken.phys.nagoya-u.ac.jp> Message-ID: >>>>> [emacs-mime-ja : No.01109] にて >>>>> “Yoichi”= Yoichi NAKAYAMA さま曰く: 山岡さん> すみません、誤解していました。しばらく Gnus ばかり使っている山岡さん> うちに疎くなってしまいましたが mime-edit-again に限定して考山岡さん> えて良いのですね。 Yoichi> mime-edit-decode-single-part-in-buffer が mime-edit-again でし Yoichi> か使われていないので私はそういう認識をしているのですが、 Yoichi> mime-edit-decode-single-part-in-buffer は not documented なの Yoichi> でよくわかりません。上の理解が正しいのであれば別の用途で用いら Yoichi> れないように、 For mime-edit-again 的な description を書いてお Yoichi> いた方がよいかもしれません。 MIME-Edit に関していえば、一応、公開用関数には全て DOC-string を書いてあるつもりなんですが、もし抜けてたら付けましょう。あと、公開しない関数には DOC-string を付けない方が良いと思います。 comment なら賛成です。とはいえ、関数 mime-edit-decode-single-part-in-buffer は ;;; @ edit again ;;; と書いてある章?の中にある DOC-string のない関数なので、普通に読めば mime-edit-again のための内部処理用関数だと判ると思う気がするんですが、不十分でしょうか？山岡さん> 強いて言うならば、MIME-View はこんなパートもデコードして表示山岡さん> してしまうので、reedit の対象に含めたくなりますが、それはた山岡さん> ぶん違う問題でしょう。 Yoichi> これは、forward するメッセージが mime-edit で読めない(preview Yoichi> では見えるのに)所を、見えるようにしたいだの改竄したいだのとい Yoichi> う要求と同じ問題ですよね。こういうのは、編集しない entity に対して編集不可な表示を出しつつ entity の network 表現を保存しとくというような方法を採れば可能だと思います。中山> ;; リリースがせまっている wl-2_10 では T-gnus と同様の変更を中山> ;; 入れておくべきでしょうかね。必要ならそろそろ SEMI 1.14.5 を release しようと思いますがいかがでしょうか？ -- ┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━ ││ ─ │ ─ ／ ─ ┼─ ┬ ─ ─┼ ┬┴─ ┼┼─┼|〓━─┼ 守岡知彦 (MORIOKA Tomohiko) ─ ─┬ ┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ From yoichi ＠ eken.phys.nagoya-u.ac.jp Wed Nov 6 20:07:08 2002 From: yoichi ＠ eken.phys.nagoya-u.ac.jp (Yoichi NAKAYAMA) Date: Wed, 06 Nov 2002 20:07:08 +0900 Subject: reedit message by WL/SEMI In-Reply-To: References: <87of97uoo9.wl@eken.phys.nagoya-u.ac.jp> <87k7jth3vy.wl@eken.phys.nagoya-u.ac.jp> <877kfs1veg.wl@eken.phys.nagoya-u.ac.jp> Message-ID: <87y987ufc3.wl@eken.phys.nagoya-u.ac.jp> 守岡さん wrote: > mime-edit-decode-single-part-in-buffer は > > ;;; @ edit again > ;;; > > と書いてある章?の中にある DOC-string のない関数なので、普通に読めば > mime-edit-again のための内部処理用関数だと判ると思う気がするんですが、なるほど、このコメントはそう読むものでしたか。これまでそういう読み方をしたことがなかったのでわかってませんでしたが理解できました。 > 必要ならそろそろ SEMI 1.14.5 を release しようと思いますがいかがでしょ > うか？そうしていただけると嬉しいです。Thanks in advance! Best Regards, -- Yoichi Nakayama From okada ＠ opaopa.org Wed Nov 13 11:56:02 2002 From: okada ＠ opaopa.org (okada ＠ opaopa.org) Date: Wed, 13 Nov 2002 11:56:02 +0900 Subject: smtp.el of slim Message-ID: 最近、elispをいじっていないおかだです．現在、slim と幹の差分は、smtp.el の smtp-submit-package の starttls の部分と、 smtp-send-by-myself の部分となっています．これを幹にマージしてしまってよろしいでしょうか？ -- 岡田健一 mailto:okada ＠ opaopa.org From okada ＠ opaopa.org Wed Nov 13 12:05:54 2002 From: okada ＠ opaopa.org (okada ＠ opaopa.org) Date: Wed, 13 Nov 2002 12:05:54 +0900 Subject: smtp.el of slim Message-ID: 最近、elispをいじっていないおかだです．現在、slim と幹の差分は、smtp.el の smtp-submit-package の starttls の部分と、 smtp-send-by-myself の部分となっています．これを幹にマージしてしまってよろしいでしょうか？ -- 岡田健一 mailto:okada ＠ opaopa.org From yamaoka ＠ jpl.org Wed Nov 13 12:08:10 2002 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: Wed, 13 Nov 2002 12:08:10 +0900 Subject: smtp.el of slim References: Message-ID: >>>>> In [emacs-mime-ja : No.01118] 岡田健一さん wrote: 岡田さん> 現在、slim と幹の差分は、smtp.el の岡田さん> smtp-submit-package の starttls の部分と、岡田さん> smtp-send-by-myself の部分となっています．岡田さん> これを幹にマージしてしまってよろしいでしょうか？賛成。 ;; たぶん反対と言う人もいない代わりに積極的に賛成発言する人も少 ;; ないと思うので一応。:-p -- Katsumi Yamaoka From okada ＠ opaopa.org Wed Nov 13 13:53:16 2002 From: okada ＠ opaopa.org (okada ＠ opaopa.org) Date: Wed, 13 Nov 2002 13:53:16 +0900 Subject: smtp.el of slim In-Reply-To: References: Message-ID: おかだです。 In the message Katsumi Yamaoka wrote: 岡田> 現在、slim と幹の差分は、smtp.el の岡田> smtp-submit-package の starttls の部分と、岡田> smtp-send-by-myself の部分となっています．岡田> これを幹にマージしてしまってよろしいでしょうか？山岡さん> 賛成。山岡さん> ;; たぶん反対と言う人もいない代わりに積極的に賛成発言する人も少山岡さん> ;; ないと思うので一応。:-p とりあえず、commit してみました． -- 岡田健一 mailto:okada ＠ opaopa.org From yamaoka ＠ jpl.org Wed Nov 13 14:28:06 2002 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: Wed, 13 Nov 2002 14:28:06 +0900 Subject: smtp.el of slim References: Message-ID: >>>>> In [emacs-mime-ja : No.01121] 岡田健一さん wrote: 岡田さん> とりあえず、commit してみました．どうもです。CLIME へのマージと、それから今朝がたつい手がすべって少しいじってしまった LIMIT の完全 sync をやらせていただきます。あとで。 -- Katsumi Yamaoka From yoichi ＠ eken.phys.nagoya-u.ac.jp Wed Nov 13 16:07:00 2002 From: yoichi ＠ eken.phys.nagoya-u.ac.jp (Yoichi NAKAYAMA) Date: Wed, 13 Nov 2002 16:07:00 +0900 Subject: mailcap.el Message-ID: なかやまですふと気になったのですが、flim-1_14 では mailcap.el をインストールしますが、lemi を見ると入ってないようです。これって flim ではインストールしといた方がいいのでしょうか？ ;; Oort gnus 使う時に名前がかぶっているのに気がついて ;; ~/.gnus で ;; ;; (load "gnus/mailcap") ;; ;; しています。(load-path をいじればいいのですが) -- Yoichi Nakayama From yamaoka ＠ jpl.org Wed Nov 13 21:37:08 2002 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: Wed, 13 Nov 2002 21:37:08 +0900 Subject: sync CLIME and LIMIT with FLIM (Re: smtp.el of slim) References: Message-ID: clime-1_14 枝と limit-1_14 枝の flim を flim-1_14 枝に同期させました。LIMIT の mime-parse.el にある心臓部は恐ろしくていじれませんでしたが。 -- Katsumi Yamaoka ;; LIMIT が FLIM になってしまっていないことを祈ります。:-p From tomo ＠ mousai.as.wakwak.ne.jp Thu Nov 14 01:45:27 2002 From: tomo ＠ mousai.as.wakwak.ne.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQg==?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 14 Nov 2002 01:45:27 +0900 Subject: mailcap.el In-Reply-To: Yoichi NAKAYAMA's message of "Wed, 13 Nov 2002 16:07:00 +0900" References: Message-ID: >>>>> [emacs-mime-ja : No.01123] にて >>>>> “Yoichi”= Yoichi NAKAYAMA さま曰く: Yoichi> ふと気になったのですが、flim-1_14 では mailcap.el Yoichi> をインストールしますが、lemi を見ると入ってない Yoichi> ようです。これって flim ではインストールしといた方 Yoichi> がいいのでしょうか？古い SEMI のための対処ですが、もう install しない方が良い気がします。 -- ┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━ ││ ─ │ ─ ／ ─ ┼─ ┬ ─ ─┼ ┬┴─ ┼┼─┼|〓━─┼ 守岡知彦 (MORIOKA Tomohiko) ─ ─┬ ┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ From yamaoka ＠ jpl.org Fri Nov 15 09:33:27 2002 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: Fri, 15 Nov 2002 09:33:27 +0900 Subject: Problems with (require 'mailcap) References: <200211141335.gAEDZaMH013537@musashi.et.bocholt.fh-gelsenkirchen.de> Message-ID: Hi, I'll CC this message to the emacs-mime-ja list (for discussing FLIM, SEMI, etc.). Please note that the list is closed for non- subscribes senders. I'll forward your message if you'd like to say something to that community. >>>>> In <200211141335.gAEDZaMH013537 ＠ musashi.et.bocholt.fh-gelsenkirchen.de> >>>>> Dirk GOUDERS wrote: > Gnus v5.9.0 > GNU Emacs 21.2.1 (i386--freebsd, X toolkit, Xaw3d scroll bars) > Hello, > I had some problems with Gnus and want to report about it: > everytime I tried to read an article with MIME headers, I got an error > message: > Symbol's function definition is void: mailcap-parse-mailcap > recognized a (require 'mailcap) and that requirement was fullfilled by > the wrong file /usr/local/share/emacs/21.2/site-lisp/flim/mailcap.el > which also provides `mailcap'. > I solved the problem by renaming Gnus' mailcap to gnus-mailcap. > I'm not sure if it is a problem of Gnus, but I think that no to > lisp-files should provide the same resource, do they? Neither Gnus nor FLIM is bad. The problem occurred since those names had collided by chance. Now, all functions in the FLIM's mailcap.el have been transferred to mime-conf.el in order to avoid the problem. So, you may simply delete it like: rm /usr/local/share/emacs/21.2/site-lisp/flim/mailcap.el* Probably, mailcap.el won't be included in the next FLIM release. Regards, -- Katsumi Yamaoka From yamaoka ＠ jpl.org Fri Nov 15 09:50:51 2002 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: Fri, 15 Nov 2002 09:50:51 +0900 Subject: mailcap.el References: Message-ID: >>>>> In [emacs-mime-ja : No.01125] 守岡知彦さん wrote: Yoichi> ふと気になったのですが、flim-1_14 では mailcap.el Yoichi> をインストールしますが、lemi を見ると入ってない Yoichi> ようです。これって flim ではインストールしといた方 Yoichi> がいいのでしょうか？ > 古い SEMI のための対処ですが、もう install しない方が良い気がします。では中山さんに対処をお願いしてよろしいですか? :) -- Katsumi Yamaoka ;; なぜかネット社会ではまったくつながりがなさそうな場所で、同時 ;; 期に似た話が出てきますね。→ さっきの bugs ＠ gnus.org のメール From yamaoka ＠ jpl.org Fri Nov 15 14:44:48 2002 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: Fri, 15 Nov 2002 14:44:48 +0900 Subject: Fwd: Re: Problems with (require 'mailcap) Message-ID: gnus.gnus-bug に寄せられたメッセージをフォワードします。ぼくは実は Gnus でも FLIM の smtp.el と smtpmail.el を使っていますが、彼が指摘した問題は知りませんでした。 emacs-mime-(en|ja) も第3者ポスト可にした方が良いかもしれませんね。 -------------- next part -------------- 添付メールを保管しました... 送信者: Jesper Harder 件名: Re: Problems with (require 'mailcap) 日付: Fri, 15 Nov 2002 03:35:32 +0100 サイズ: 2322 バイト URL: From yamaoka ＠ jpl.org Fri Nov 15 16:06:37 2002 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: Fri, 15 Nov 2002 16:06:37 +0900 Subject: Problems with (require 'mailcap) References: <200211141335.gAEDZaMH013537@musashi.et.bocholt.fh-gelsenkirchen.de> Message-ID: >>>>> In >>>>> Katsumi Yamaoka wrote: > Though I'm always using FLIM's smtpmail, I didn't know such a > problem until now. >> Debugger entered--Lisp error: (wrong-type-argument stringp nil) >[...] >> * call-interactively(smtpmail-send-queued-mail) > I will use that command in a minute. :) (I think you may know what happened since you are skilled programmer. :-p) The FLIM version of smtpmail.el uses smtp.el and there's the option `smtp-server' which is apt to be nil by default. You seem to be successful in sending queued mails if you specify the proper SMTP server name for this option. How is it? -- Katsumi Yamaoka From yoichi ＠ eken.phys.nagoya-u.ac.jp Fri Nov 15 16:27:02 2002 From: yoichi ＠ eken.phys.nagoya-u.ac.jp (Yoichi NAKAYAMA) Date: Fri, 15 Nov 2002 16:27:02 +0900 Subject: Fwd: Re: Problems with (require 'mailcap) In-Reply-To: References: Message-ID: <87d6p7i989.wl@eken.phys.nagoya-u.ac.jp> At Fri, 15 Nov 2002 14:44:48 +0900,Katsumi Yamaoka wrote: > gnus.gnus-bug に寄せられたメッセージをフォワードします。 > ぼくは実は Gnus でも FLIM の smtp.el と smtpmail.el を使っていま > すが、彼が指摘した問題は知りませんでした。僕も同じことで困って以下のようなのを ~/.gnus にしこんでました。 (load "gnus/mailcap") (load "mail/smtpmail") ;; mailcap の方は対処しておきます。 -- Yoichi Nakayama From yamaoka ＠ jpl.org Fri Nov 15 16:55:38 2002 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: Fri, 15 Nov 2002 16:55:38 +0900 Subject: Fwd: Re: Problems with (require 'mailcap) References: <87d6p7i989.wl@eken.phys.nagoya-u.ac.jp> Message-ID: >>>>> In [emacs-mime-ja : No.01130] >>>>> Yoichi NAKAYAMA wrote: >> ぼくは実は Gnus でも FLIM の smtp.el と smtpmail.el を使っていま >> すが、彼が指摘した問題は知りませんでした。中山さん> 僕も同じことで困って以下のようなのを ~/.gnus にしこんでました。中山さん> (load "gnus/mailcap") 中山さん> (load "mail/smtpmail") Emacs の smtpmail.el を見るとこんなものがありました。 (defun smtpmail-via-smtp (recipient smtpmail-text-buffer) (let ((process nil) (host (or smtpmail-smtp-server (error "`smtpmail-smtp-server' not defined"))) [...] smtp.el にも同様のものがあれば良かったのかもしれませんね。中山さん> ;; mailcap の方は対処しておきます。よろしくおねが...どうもありがとうございました。:) -- Katsumi Yamaoka From yamaoka ＠ jpl.org Fri Nov 15 17:02:04 2002 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: Fri, 15 Nov 2002 17:02:04 +0900 Subject: Problems with (require 'mailcap) References: <200211141335.gAEDZaMH013537@musashi.et.bocholt.fh-gelsenkirchen.de> Message-ID: 転送します (thread をちゃんと繋げるのが少々やっかい ^^;;)。 -------------- next part -------------- 添付メールを保管しました... 送信者: Dirk GOUDERS 件名: Re: Problems with (require 'mailcap) 日付: Fri, 15 Nov 2002 08:53:58 +0100 サイズ: 1136 バイト URL: From kose ＠ wizard.tamra.co.jp Fri Nov 15 17:05:16 2002 From: kose ＠ wizard.tamra.co.jp (=?ISO-2022-JP?B?GyRCPi40WBsoQiAbJEI1SEInGyhC?= (KOSEKI Yoshinori)) Date: Fri, 15 Nov 2002 17:05:16 +0900 Subject: Fwd: Re: Problems with (require 'mailcap) In-Reply-To: <87d6p7i989.wl@eken.phys.nagoya-u.ac.jp> (Yoichi NAKAYAMA's message of "Fri, 15 Nov 2002 16:27:02 +0900") References: <87d6p7i989.wl@eken.phys.nagoya-u.ac.jp> Message-ID: <20021115xjc65uzgsw3.%kose@wizard.tamra.co.jp> >>>>> In [emacs-mime-ja : No.01130] >>>>> Yoichi NAKAYAMA wrote: > At Fri, 15 Nov 2002 14:44:48 +0900,Katsumi Yamaoka wrote: > > gnus.gnus-bug に寄せられたメッセージをフォワードします。 > > ぼくは実は Gnus でも FLIM の smtp.el と smtpmail.el を使っていま > > すが、彼が指摘した問題は知りませんでした。 Oort Gnus と FLIM の smtp.el と smtpmail.el を使っていますがこういうことは経験がないです。 > 僕も同じことで困って以下のようなのを ~/.gnus にしこんでました。 > (load "gnus/mailcap") > (load "mail/smtpmail") もしかして、smtpmailel の「queue にためる機能」を使っているのですか? ボクは Oort Gnus では gnus-agnet の「queue にためる機能」を使っているから遭遇しないということなのでしょうか? -- こせき // Meadow Netinstall http://www.netlaputa.ne.jp/~kose/Emacs/Meadow/#netinstall From yamaoka ＠ jpl.org Fri Nov 15 17:20:13 2002 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: Fri, 15 Nov 2002 17:20:13 +0900 Subject: Fwd: Re: Problems with (require 'mailcap) References: <87d6p7i989.wl@eken.phys.nagoya-u.ac.jp> <20021115xjc65uzgsw3.%kose@wizard.tamra.co.jp> Message-ID: >>>>> In [emacs-mime-ja : No.01133] 小関吉則さん wrote: 小関さん> Oort Gnus と FLIM の smtp.el と smtpmail.el を使っています小関さん> がこういうことは経験がないです。 [...] 小関さん> もしかして、smtpmailel の「queue にためる機能」を使っている小関さん> のですか? はいそうです。→ X-Mail-Count: 01128 Thread をつなぎそこなってしまいましたが → X-Mail-Count: 01129 単に smtp-server が nil だっただけではないかと。ぼくは smtpmail-send-queued-mail がちゃんと使えましたから。 -- Katsumi Yamaoka From yoichi ＠ eken.phys.nagoya-u.ac.jp Fri Nov 15 17:25:55 2002 From: yoichi ＠ eken.phys.nagoya-u.ac.jp (Yoichi NAKAYAMA) Date: Fri, 15 Nov 2002 17:25:55 +0900 Subject: Fwd: Re: Problems with (require 'mailcap) In-Reply-To: <20021115xjc65uzgsw3.%kose@wizard.tamra.co.jp> References: <87d6p7i989.wl@eken.phys.nagoya-u.ac.jp> <20021115xjc65uzgsw3.%kose@wizard.tamra.co.jp> Message-ID: <87adkbi6i4.wl@eken.phys.nagoya-u.ac.jp> At Fri, 15 Nov 2002 17:05:16 +0900,小関吉則 (KOSEKI Yoshinori) wrote: > もしかして、smtpmailel の「queue にためる機能」を使っている > のですか? 僕の場合は単に emacs 附属の方の smtpmail.el のコメントにある SMTP server の設定法を見ていて、あれ、うまくいかないなー、って思ったときに flim の方のを load してるのに気付いて、参照していた方の mail/smtpmail を load したらうまくいってそのままというだけのことです。 ;; mail/smtpmail だと smtpmail-default-smtp-server の所を flim/smtpmail ;; だと smtp-default-server に変えればいいというのは後で気付きました。 -- Yoichi Nakayama From kose ＠ wizard.tamra.co.jp Fri Nov 15 17:26:05 2002 From: kose ＠ wizard.tamra.co.jp (=?ISO-2022-JP?B?GyRCPi40WBsoQiAbJEI1SEInGyhC?= (KOSEKI Yoshinori)) Date: Fri, 15 Nov 2002 17:26:05 +0900 Subject: Fwd: Re: Problems with (require 'mailcap) In-Reply-To: <20021115xjc65uzgsw3.%kose@wizard.tamra.co.jp> (=?ISO-2022-JP?B?GyRCPi40WBsoQiAbJEI1SEInGyhC?= (KOSEKI Yoshinori)'s message of "Fri, 15 Nov 2002 17:05:16 +0900") References: <87d6p7i989.wl@eken.phys.nagoya-u.ac.jp> <20021115xjc65uzgsw3.%kose@wizard.tamra.co.jp> Message-ID: <20021115xjc3cq3grxe.%kose@wizard.tamra.co.jp> >>>>> In [emacs-mime-ja : No.01133] >>>>> “kose” = 小関吉則 (KOSEKI Yoshinori) wrote: kose> もしかして、smtpmailel の「queue にためる機能」を使っている kose> のですか? kose> ボクは Oort Gnus では gnus-agnet の「queue にためる機能」を kose> 使っているから遭遇しないということなのでしょうか? 全く的外れなことを言ってますね、これ。 >>>>> In [emacs-mime-ja : No.00927] >>>>> “kose” = 小関吉則 (KOSEKI Yoshinori) wrote: kose> ボクの場合だとどちらを使っても有効なように、 kose> (setenv "SMTPSERVER" "SMTP-SERVER-NAME") kose> とやっていたりしますが。だと遭遇しなかったということなのですね。 -- こせき // Meadow Netinstall http://www.netlaputa.ne.jp/~kose/Emacs/Meadow/#netinstall From tomo ＠ m17n.org Fri Nov 15 17:45:31 2002 From: tomo ＠ m17n.org (=?ISO-2022-JP?B?GyRCPGkyLBsoQg==?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 15 Nov 2002 17:45:31 +0900 Subject: SEMI: Version 1.14.5 =?ISO-2022-JP?B?KBskQjAyODYyOUB0GyhCKQ==?= Message-ID: [状態] beta [推奨する環境] APEL: 10.3 FLIM: 1.14.4 [変更点] 2002-11-15 MORIOKA Tomohiko * SEMI: Version 1.14.5 (Awara-Onsen) released. 2002-11-05 Yoichi NAKAYAMA * mime-view.el (mime-preview-find-boundary-info): Change the name of the argument from get-mother to with-children along its effect. 2002-11-03 Yoichi NAKAYAMA * mime-edit.el (mime-edit-decode-single-part-in-buffer): Decode text part only. 2002-04-16 Daiki Ueno * mime-edit.el (mime-file-types): Add setting of *.jpeg for image/jpeg. 2002-10-26 Yoichi NAKAYAMA * mime-view.el (mime-preview-find-boundary-info): Fix logic. Do not refer next to next part before examining the next part. 2002-08-28 Katsumi Yamaoka * mime-edit.el (mime-edit-user-agent-value): Add `xemacs-extra-name'. -------------- next part -------------- It is available from http://www.kanji.zinbun.kyoto-u.ac.jp/~tomo/comp/emacsen/lisp/semi/semi-1.14-for-flim-1.14/ -------------- next part -------------- -- tomo. From yoichi ＠ eken.phys.nagoya-u.ac.jp Sat Nov 16 00:29:16 2002 From: yoichi ＠ eken.phys.nagoya-u.ac.jp (Yoichi NAKAYAMA) Date: Sat, 16 Nov 2002 00:29:16 +0900 Subject: PGP =?ISO-2022-JP?B?GyRCPXBMPiROOCE+WhsoQg==?= Message-ID: <871y5mj1gz.wl@eken.phys.nagoya-u.ac.jp> なかやまです pgg-verify-region が echo buffer に出すメッセージについての話です。 wl-message-pgp-verify-region をしたときに、手元の環境では default-buffer-file-coding-system が euc-japan-unix だと生のもの、 iso-2022-7bit だと encode された物が入るみたいです。 MIME-PGP の場合に mime-verify-application/pgp-signature で再生したときの echo buffer についても同様みたいなのですが、とりあえず wl-message-pgp-verify-region については対処しときました(のつもり)。 http://cvs.m17n.org/cgi-bin/viewcvs/wanderlust/wl/wl-mime.el.diff?r1=1.46&r2=1.47 ;; encoding に関する知識を持ってないので、動作を見ながら想像しつつ ;; 変更したので変なことしてたらごめんなさい。これは pgg の方で対処してもらった方がいいのでしょうか？ -- Yoichi Nakayama From yoichi ＠ eken.phys.nagoya-u.ac.jp Wed Nov 20 08:11:48 2002 From: yoichi ＠ eken.phys.nagoya-u.ac.jp (Yoichi NAKAYAMA) Date: Wed, 20 Nov 2002 08:11:48 +0900 Subject: PGP =?ISO-2022-JP?B?GyRCPXBMPiROOCE+WhsoQg==?= In-Reply-To: <871y5mj1gz.wl@eken.phys.nagoya-u.ac.jp> References: <871y5mj1gz.wl@eken.phys.nagoya-u.ac.jp> Message-ID: <87bs4lrw7f.wl@eken.phys.nagoya-u.ac.jp> At Sat, 16 Nov 2002 00:29:16 +0900, yoichi wrote: > pgg-verify-region が echo buffer に出すメッセージについての話です。 > > wl-message-pgp-verify-region をしたときに、手元の環境では > default-buffer-file-coding-system が euc-japan-unix だと生のもの、 > iso-2022-7bit だと encode された物が入るみたいです。 > MIME-PGP の場合に mime-verify-application/pgp-signature で再生した > ときの echo buffer についても同様みたいなのですが、とりあえず > wl-message-pgp-verify-region については対処しときました(のつもり)。 [...] > これは pgg の方で対処してもらった方がいいのでしょうか？ちなみに手元では同じような変更を pgg.el, mime-pgp.el に加えて使っています。 -- Yoichi Nakayama -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: pgp-verify.diff 型: application/octet-stream サイズ: 1521 バイト説明: 無し URL: