From tomo @ etl.go.jp Wed Oct 27 13:35:08 1999 From: tomo @ etl.go.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko) Date: 27 Oct 1999 13:35:08 +0900 Subject: test Message-ID: -- ===『幾千億の分子に分かれても ======================================== 決して忘れない。 この宇宙が終るまで』 守岡 知彦 (MORIOKA Tomohiko) ======================================== Email: ===== From tomo @ etl.go.jp Thu Oct 28 18:17:48 1999 From: tomo @ etl.go.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko) Date: 28 Oct 1999 18:17:48 +0900 Subject: new mailing lists (Re: about chamonix) In-Reply-To: tomo@etl.go.jp's message of "27 Oct 1999 15:15:30 +0900" References: <14341.47116.409765.10385Q@kurusugawa.jaist.ac.jp> <14356.23173.40706.68864H@kurusugawa.jaist.ac.jp> Message-ID: tm-ja からの forward はまだなんですが、とりあえず新 mailing list がで きたので、こちらに移ってください。 よろしくお願いします。 -- ┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━ ││ ─ │ ─ / ─ ┼─ ┬ ─ ─┼ ┬┴─ ┼┼─┼|〓━─┼ 守岡 知彦 (MORIOKA Tomohiko) ─ ─┬ ┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ From tomo @ etl.go.jp Thu Oct 28 19:20:54 1999 From: tomo @ etl.go.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko) Date: 28 Oct 1999 19:20:54 +0900 Subject: attached file in mail In-Reply-To: Keiichi Suzuki's message of "27 Oct 1999 14:24:20 +0900" References: <87aepdgl5m.fsf@dp50.ecc.u-tokyo.ac.jp> <8766zwp10e.fsf@santoka.bio.agr.yamaguchi-u.ac.jp> Message-ID: >>>>> In [tm(ja) / tm ML (日本語版) : No.5455] >>>>> "圭一" = Keiichi Suzuki wrote: 圭一> ;; 完成時期に関してはあまり早い時期を期待しないでくださいね。 圭一> ;; 本業 & 風邪 ;_; お大事に。 圭一> うむむ、私も同様の理由で text-property はあまり使いたくありませ 圭一> んが、言語情報という意味ではこれも良いかもしれませんね。 圭一> ;; ここから、ここまでは日本語で... なんてこともできるし。 そうですね。ただ、parameter に限っていえば、parameter 毎に言語が決まる ので。 圭一> Decode 済のものには text-property をつけるようにしましょうか? そうですね。何が良いでしょうかね? mime-language? それとも『男らしく』 language とか。 ;; 他の関係各位(言語タグな人とか)と相談した方が良いような気もします ;; が。 圭一> いろいろ考えてみたのですが、結果としては parameter の表現を現在の 圭一> (attribute-name . value) 圭一> という形式から、 圭一> (attribute-name . [language charset raw-value-alist encoded-value-cache]) 圭一> member of raw-value-alist: 圭一> (section-number . (encoded . raw-value)) 圭一> という形式に変更して、結合と encode は lazy に処理するというのが 圭一> 良いのではないかと思いますがいかがでしょうか? よろしいんじゃないでしょうか? あるいは、連想リストじゃなくて mime-parameter というような抽象型の 集合(多分実装上は vector の list か hash (or obarray))に変更しちゃう のが良いかも知れません。 ;; どうせ連想 list のままでも連想 list を直接いじる program は動かなく ;; なるだろうし、mime-*-parameters で結合後の連想 list を返せば行儀の ;; 良い program は救済できるだろうし。 -- ===『幾千億の分子に分かれても ======================================== 決して忘れない。 この宇宙が終るまで』 守岡 知彦 (MORIOKA Tomohiko) ======================================== Email: ===== From yamaoka @ ga.sony.co.jp Thu Oct 28 20:38:27 1999 From: yamaoka @ ga.sony.co.jp (Katsumi Yamaoka) Date: 28 Oct 1999 20:38:27 +0900 Subject: mime-preview-follow-current-entity References: <14358.39458.424256.82471L@daidai.kuis.kyoto-u.ac.jp> <14359.44891.990143.63369G@wanderlust.dq.isl.ntt.co.jp> <87ln8nzx9r.fsf@dp50.ecc.u-tokyo.ac.jp> Message-ID: <28g0yv1zrg.fsf@kchisa.ga.sony.co.jp> >>>>> In [tm(ja) / tm ML (日本語版) : No.5470] >>>>> Katsumi Yamaoka wrote: 山岡> とりあえず津邑さんのパッチは後で commit します。 もう一点、フォワードされたメッセージを MIME-View で表示しているとき "[2 ]" といった entity button の場所とその一行下のヘッダでは entity の値が異 なるため、この button の場所で M-x mime-preview-follow-current-entity または a キーをタイプすると、followup の対象となるメッセージとしては "[2 ]" この button のテキストだけが抽出されてしまいます。 多分に付け焼き刃ではありますが以下の変更をお許し願えますでしょうか? -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: mime-view.el.diff 型: application/octet-stream サイズ: 591 バイト 説明: 無し URL: -------------- next part -------------- 山岡> ;; gnus-following-method は gnus-art.el から gnus-msg.el に移し 山岡> ;; て検討して gnus-setup-message を被せた関数に変更する検討をし 山岡> ;; ています。 ;; 検討して検討↑した結果 (^^;;)、gnus-following-method は次のようにし ;; ようと思っています。 (defun gnus-following-method (buf) (gnus-setup-message 'reply-yank (set-buffer buf) (if (message-news-p) (message-followup) (message-reply nil 'wide)) (let ((message-reply-buffer buf)) (message-yank-original)) (message-goto-body)) (kill-buffer buf)) -- Katsumi Yamaoka From tomo @ etl.go.jp Fri Oct 29 16:17:34 1999 From: tomo @ etl.go.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko) Date: 29 Oct 1999 16:17:34 +0900 Subject: mime-preview-follow-current-entity In-Reply-To: Katsumi Yamaoka's message of "28 Oct 1999 01:51:00 -0400 (EDT)" References: <14358.39458.424256.82471L@daidai.kuis.kyoto-u.ac.jp> <14359.44891.990143.63369G@wanderlust.dq.isl.ntt.co.jp> Message-ID: >>>>> In [tm(ja) / tm ML (日本語版) : No.5466] >>>>> "山岡" = Katsumi Yamaoka wrote: 山岡> もう一つ gnus には問題があって、M-x 山岡> mime-preview-follow-current-entityで使われる関数 山岡> message-followup はニュース記事を意識した内容になっているため、 山岡> To フィールドなどが自動生成されません。 山岡> これは改善の余地ありです。 元々の気持では followup と reply の両方を作るつもりだったんですが、 lazy な実装の結果未だ reply が存在しないという現状になっています。 (^_^;;; ;; followup は、某 mailing list のまとめ送り記事に返事を書いたり、実家 ;; に forward した記事に返事を書くのが面倒なのに堪え切れず、やむにやま ;; れず実装したような記憶が。(^_^; で、当時使っていたのは tm-mh-e だっ ;; たので、ながらく tm-mh-e 用の method しかなかったような気が。 そういう訳で、個人的には『entity に follow する』機能に加え『entity に reply する』機能を追加するのが良いと思います。 ===『幾千億の分子に分かれても ======================================== 決して忘れない。 この宇宙が終るまで』 守岡 知彦 (MORIOKA Tomohiko) ======================================== Email: ===== From tomo @ etl.go.jp Fri Oct 29 16:22:38 1999 From: tomo @ etl.go.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko) Date: 29 Oct 1999 16:22:38 +0900 Subject: mime-preview-follow-current-entity In-Reply-To: Yoshiki Hayashi's message of "28 Oct 1999 17:48:16 +0900" References: <14358.39458.424256.82471L@daidai.kuis.kyoto-u.ac.jp> <14359.44891.990143.63369G@wanderlust.dq.isl.ntt.co.jp> <87ln8nzx9r.fsf@dp50.ecc.u-tokyo.ac.jp> Message-ID: >>>>> [tm(ja) / tm ML (日本語版) : No.5469] にて >>>>> “Yoshiki”= Yoshiki Hayashi さま曰く: Yoshiki> # ^L にはいろいろと悩まされるので、いっそのこと SEMI に ^L Yoshiki> # handling 用の変数を作って、SEMI 自身の機能にしてしまう方が Yoshiki> # 扱いが楽なのに、と思うことがときどきあります。 同感です。 ところで、仕様的に SEMI API に含めた方が良いでしょうか?あるいは、実装 の問題とすべきでしょうか? -- ┏━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━┓ ┃『開ける価値の無い ┃守岡 知彦 (MORIOKA Tomohiko) ┃ ┃ 衣裳ダンスの扉は無い』┃ E-mail: ┃ ┗━━━━━━━━━━━━┻━━━━━━━━━━━━━━━━━━━━┛ From yamaoka @ jpl.org Fri Oct 29 16:29:56 1999 From: yamaoka @ jpl.org (Katsumi Yamaoka) Date: 29 Oct 1999 03:29:56 -0400 (EDT) Subject: mime-preview-follow-current-entity References: <14358.39458.424256.82471L@daidai.kuis.kyoto-u.ac.jp> <14359.44891.990143.63369G@wanderlust.dq.isl.ntt.co.jp> Message-ID: >>>>> In [emacs-mime-ja : No.00005] >>>>> tomo @ etl.go.jp (守岡 知彦 / MORIOKA Tomohiko) wrote: 山岡> もう一つ gnus には問題があって、M-x 山岡> mime-preview-follow-current-entityで使われる関数 山岡> message-followup はニュース記事を意識した内容になっているため、 山岡> To フィールドなどが自動生成されません。 山岡> これは改善の余地ありです。 tomo> 元々の気持では followup と reply の両方を作るつもりだったんです tomo> が、lazy な実装の結果未だ reply が存在しないという現状になってい tomo> ます。(^_^;;; [...] tomo> そういう訳で、個人的には『entity に follow する』機能に加え tomo> 『entity にreply する』機能を追加するのが良いと思います。 実はそれも考えたのですが、どうもそういうのって gnus 独自の文化ではない かと思いまして実施は思いとどまりました。 めったに使わない機能なので、あまり力を入れる気が起きなかった、という本 音もあるのですが、一方で返信をニュースでするかメールでするかを自動決定 させ、しかも Mail-(Copies|Followup)-To を真面目に扱うようにするために は、現行の Semi-gnus 系の message.el にかなり手を入れる必要があります。 もっとも実際に使ってみると、ある特定のパートだけに返信する場合に非常に 便利なことにも気がつきました。 そういうわけで、手修正を許して曲がりなりにも使えるものにするための最低 限の対応が、 津邑さんのパッチ: tm-ja 5458 山岡のパッチ: emacs-mime-ja 00004 であるわけです。 SEMI 1.14 が出るまでのつなぎ、にするにしても、やはり (特に 00004 は) メインテナの守岡さんとして許せないですよねえ。(?|^^;;) -- Katsumi Yamaoka From t90553 @ mail.ecc.u-tokyo.ac.jp Fri Oct 29 16:42:07 1999 From: t90553 @ mail.ecc.u-tokyo.ac.jp (Yoshiki Hayashi) Date: 29 Oct 1999 16:42:07 +0900 Subject: mime-preview-follow-current-entity In-Reply-To: (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko's message of "Fri, 29 Oct 1999 16:22:38 +0900") References: <14358.39458.424256.82471L@daidai.kuis.kyoto-u.ac.jp> <14359.44891.990143.63369G@wanderlust.dq.isl.ntt.co.jp> <87ln8nzx9r.fsf@dp50.ecc.u-tokyo.ac.jp> Message-ID: <87wvs6aa0g.fsf@dp50.ecc.u-tokyo.ac.jp> tomo @ etl.go.jp (守岡 知彦 / MORIOKA Tomohiko) writes: > Yoshiki> # ^L にはいろいろと悩まされるので、いっそのこと SEMI に ^L > Yoshiki> # handling 用の変数を作って、SEMI 自身の機能にしてしまう方が > Yoshiki> # 扱いが楽なのに、と思うことがときどきあります。 > > 同感です。 > > ところで、仕様的に SEMI API に含めた方が良いでしょうか?あるいは、実装 > の問題とすべきでしょうか? ^L handling を SEMI に実装してしまって、SEMI API に含まれた 方が嬉しいです。narrowing でよければ SEMI 1.14 用に実装しま すが。 -- Yoshiki Hayashi From tomo @ etl.go.jp Fri Oct 29 16:51:40 1999 From: tomo @ etl.go.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko) Date: 29 Oct 1999 16:51:40 +0900 Subject: MIME-Edit, MIME-View file attachment In-Reply-To: Yoshiki Hayashi's message of "27 Oct 1999 18:53:33 +0900" References: <87bt9ur9gh.fsf@dp50.ecc.u-tokyo.ac.jp> <877lkhgkdy.fsf@dp50.ecc.u-tokyo.ac.jp> <87zoxbsuik.fsf@dp50.ecc.u-tokyo.ac.jp> <87r9in936g.fsf@dp50.ecc.u-tokyo.ac.jp> <87ogdr920m.fsf@dp50.ecc.u-tokyo.ac.jp> <87iu3z8xz2.fsf@dp50.ecc.u-tokyo.ac.jp> <87g0z38vq5.fsf@dp50.ecc.u-tokyo.ac.jp> <87zox56sf6.fsf@dp50.ecc.u-tokyo.ac.jp> Message-ID: >>>>> [tm(ja) / tm ML ($BF|K\8lHG(B) : No.5460] $B$K$F(B >>>>> $B!H(BYoshiki$B!I(B= Yoshiki Hayashi $B$5$^[)$/(B: Yoshiki> > $B$=$&$$$&5sF0$r$9$kL?Na4X?t$r:n$C$F!"=>Mh$N4X?t$rCV$-49$($l(B Yoshiki> > $B$PNI$$$H;W$&$N$G$9$,!#(B Yoshiki> $B$=$&$$$&4X?t @ lMQ$KB>$N4X?t$G$O;H$o$l$J$$JQ?t$r:n$k$N$O5v$5$l(B Yoshiki> $B$k$N$G$7$g$&$+(B? $B$=$l$H$b!"(B.emacs $B$K=q$/$N$J$i4XCN$7$J$$$N$G(B Yoshiki> $B>!! $B @ _Dj%b!<%I$KF~$k$+!"$=$N$^$^A`:n$r3P$($k$N$+$O!">lLL$K$h$C$F(B Yoshiki> $BJQ$o$k$N$G!";d$ON>J}$G$-$k$N$,M}A[$G$9!#(B $B;d$O(B mode $B$O$"$s$^$j9%$-$8$c$J$$$H$$$&8EE5E*$J?M$G!"M;9g$7$F$?$jO"B3E*(B $B$@$C$?$j$9$k$N$,9%$-$G$9!#$=$&$$$&0UL#$G!"N>J}$G$-$k$N$O;d$NM}A[$G$b$"(B $B$j$^$9!#(B ;; $B4D6-u67$KKd$a9~$^$l$?(B user interface $B$,9%$-$G$9!#(B ;;; $B$=$&$$$($P!"(BVAIO $B$N%5%$%P!<%3!<%I$b$3$N7OE}$N8&5f$+$i @ 8$^$l$?$s$G(B ;;; $B$9$M!#(B Yoshiki> $B?7(B MUA $B$H$^$G$O$$$+$J$$$G$7$g$&$,!"(BT-gnus $B$H(B SEMI $B$,$"$^$j>e(B Yoshiki> $B $B$?$$$G$9!#$"$H(B nnimap $B4XO"$H$+!#(B $B$3$l$O;d$b5$$K$J$C$F$$$k$H$3$m$J$s$G$9!#(B ;; $B$G$b!"(BWanderlust $B$,(B FLIM $B$N5$;}$r35$M > $B$H$3$m$G!"(BSEMI $B$G$N(B file $BCj=P$G$9$,!"(Bfile $BL>$N>pJs$,$"$k>l(B Yoshiki> > $B9g$K!"$=$l$rLdEzL5MQ$KMQ$$$:$K!"(Bdefault $B$H$7$FDs<($9$k$h$&(B Yoshiki> > $B$K$9$k$3$H$K;?@.$7$^$9!#@'Hs!"(Bmime-save-content $B$r=q$-49$((B Yoshiki> > $B$F$/$@$5$$!#(B Yoshiki> $B$[$H$s$I(B interface $B$O(B Gnus $B$=$N$^$^$G$9$,!"0J2<$N(B patch $B$N$h(B Yoshiki> $B$&$K$7$F$_$^$7$?!#(Bparameter $B$,L5$$>l9g$O!"(BContent-type $B$N $B$NJ}(B (text $B$H$+(B application $B$H$+(B) $B$r;H$&$h$&$K$7$F$$$^$9!#(B Yoshiki> $B$D$$$G$KJ]B8MQ$N(B directory $B$r;XDj$9$kJQ?t$b:n$C$F$_$^$7$?!#(B $B$"$k(B method $B @ lMQ$N(B parameter $B$,(B mime-view.el $B$K$"$k$N$O8D?ME*$K$O5$;}(B $B0-$$$G$9!#$^$?!"8D?ME*$K$O(B directory $B$@$1$rMF0W$K;XDj$G$-$?$j!"$"$k$$(B $B$O!"(Bcurrent directory $B$r8+$F$/$l$kJ}$,$&$l$7$$$G$9!#(B ;; $B1?MQ$K0MB8$7$=$&$G$9$,!#(B $B$^$?!":3:Y$J$3$H$G$9$,!"(B + (concat (file-name-as-directory mime-save-directory) + (file-name-nondirectory name)))) $B$O(B expand-file-name $B$r;H$C$?J}$,NI$$$G$7$g$&!#(B ;; elisp $B$G$O0UL#$J$$$G$9$,!"(BCommon Lisp $BE*$K$O(B file-name $B$OJ8;zNs$8$c(B ;; $B$J$$$G$9!#(B Yoshiki> # $B$H$3$m$G!":G6a;W$&$s$G$9$1$I!"$I$&$7$F(B MIME-Edit $B$G$O(B file Yoshiki> # $B$rA^F~$9$k$HA4It(B attachment $B$K$J$C$F$7$^$&$N$G$7$g$&!#(B ;; $B=i4|@_Dj$N$;$$$G$9!#(BSEMI API $B$N4XCN$9$k=j$G$O$"$j$^$;$s!#(B $B$H$3$m$G!":#8e!";d$O(B SEMI API $B$N:vDj$N$_$K4X&$7!"p$+$i;d$,$^$H$a$k$H$$$&$@$1$G!"$b(B ;; $B$A$m$s!"3'MM$N8f0U8+$r:N$jF~$l$5$;$FD:$-$?$$$H;W$$$^$9!#(B ;;; API $B4XO"J8=q$OEvLL(B plain text $B$G=q$-$^$9$,!"Ev=i$NM=DjDL$j(B:-) $BNS$5(B ;;; $B$s$,(B XML $B$N(B DTD $B$r:vDjZ$rL\E*$H$7$? ===== From tomo @ etl.go.jp Fri Oct 29 17:03:22 1999 From: tomo @ etl.go.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko) Date: 29 Oct 1999 17:03:22 +0900 Subject: mime-preview-follow-current-entity In-Reply-To: Yoshiki Hayashi's message of "29 Oct 1999 16:42:07 +0900" References: <14358.39458.424256.82471L@daidai.kuis.kyoto-u.ac.jp> <14359.44891.990143.63369G@wanderlust.dq.isl.ntt.co.jp> <87ln8nzx9r.fsf@dp50.ecc.u-tokyo.ac.jp> <87wvs6aa0g.fsf@dp50.ecc.u-tokyo.ac.jp> Message-ID: >>>>> In [emacs-mime-ja : No.00008] >>>>> "Yoshiki" = Yoshiki Hayashi wrote: Yoshiki> > ところで、仕様的に SEMI API に含めた方が良いでしょうか?あ Yoshiki> > るいは、実装の問題とすべきでしょうか? Yoshiki> ^L handling を SEMI に実装してしまって、SEMI API に含まれた Yoshiki> 方が嬉しいです。narrowing でよければ SEMI 1.14 用に実装しま Yoshiki> すが。 では利用者界面に関する規約に含めます。 -- ===『幾千億の分子に分かれても ======================================== 決して忘れない。 この宇宙が終るまで』 守岡 知彦 (MORIOKA Tomohiko) ======================================== Email: ===== From t90553 @ mail.ecc.u-tokyo.ac.jp Fri Oct 29 17:30:25 1999 From: t90553 @ mail.ecc.u-tokyo.ac.jp (Yoshiki Hayashi) Date: 29 Oct 1999 17:30:25 +0900 Subject: MIME-Edit, MIME-View file attachment In-Reply-To: (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko's message of "Fri, 29 Oct 1999 16:51:40 +0900") References: <87bt9ur9gh.fsf@dp50.ecc.u-tokyo.ac.jp> <877lkhgkdy.fsf@dp50.ecc.u-tokyo.ac.jp> <87zoxbsuik.fsf@dp50.ecc.u-tokyo.ac.jp> <87r9in936g.fsf@dp50.ecc.u-tokyo.ac.jp> <87ogdr920m.fsf@dp50.ecc.u-tokyo.ac.jp> <87iu3z8xz2.fsf@dp50.ecc.u-tokyo.ac.jp> <87g0z38vq5.fsf@dp50.ecc.u-tokyo.ac.jp> <87zox56sf6.fsf@dp50.ecc.u-tokyo.ac.jp> Message-ID: <87ogdia7ry.fsf@dp50.ecc.u-tokyo.ac.jp> tomo @ etl.go.jp (守岡 知彦 / MORIOKA Tomohiko) writes: > >>>>> [tm(ja) / tm ML (日本語版) : No.5460] にて > >>>>> “Yoshiki”= Yoshiki Hayashi さま曰く: > > Yoshiki> > そういう挙動をする命令関数を作って、従来の関数を置き換えれ > Yoshiki> > ば良いと思うのですが。 > > Yoshiki> そういう関数専用に他の関数では使われない変数を作るのは許され > Yoshiki> るのでしょうか? それとも、.emacs に書くのなら関知しないので > Yoshiki> 勝手にしてね、ということでしょうか? > > 内部的に変数を作るのは勝手なんじゃないでしょうか? > > 但し、それは SEMI kernel の変数ではないでしょうし、SEMI API で規定すべ > きものでもないでしょう。 下ともつながるのですが、どこまでが kernel で API なんでしょ う? Doc string が付いているのは API の一部であるというのを少 なくとも FLIM に関しては聞いたような気がするのですが。 でまぁ、やっぱり邪悪系はやる気がしないので、適当に web でも 作ってその道の人用に布教することにします。:-) # SEMI 1.14 が出た後などに、また local からの pressure が強 # 烈になれば考えます。:-P > Yoshiki> > ところで、SEMI での file 抽出ですが、file 名の情報がある場 > Yoshiki> > 合に、それを問答無用に用いずに、default として提示するよう > Yoshiki> > にすることに賛成します。是非、mime-save-content を書き換え > Yoshiki> > てください。 > > Yoshiki> ほとんど interface は Gnus そのままですが、以下の patch のよ > Yoshiki> うにしてみました。parameter が無い場合は、Content-type の主 > Yoshiki> の方 (text とか application とか) を使うようにしています。 > Yoshiki> ついでに保存用の directory を指定する変数も作ってみました。 > > ある method 専用の parameter が mime-view.el にあるのは個人的には気持 > 悪いです。また、個人的には directory だけを容易に指定できたり、あるい > は、current directory を見てくれる方がうれしいです。 そうすると、変数は mime-play.el に書けばよいのでしょうか? mime-play.el に書かなかったのは、一つも defcustom されていな いので書かない方針なのかな、と推測しただけです。守岡さん的に は、その変数が t だと current directory だと解釈すると良いの でしょうか? ところで、directory だけを容易に指定できるよう にしてあるはずなのですが、どこがだめなのでしょうか? > また、些細なことですが、 > > + (concat (file-name-as-directory mime-save-directory) > + (file-name-nondirectory name)))) > > は expand-file-name を使った方が良いでしょう。 これは gnus に倣ったのですが、たぶん directory の指定がこけ ていてもちゃんとした値がでるように、という親切設計なのでしょ う。別に expand-file-name でも私は構わないですが。選択は maintainer にお任せします。 > Yoshiki> # ところで、最近思うんですけど、どうして MIME-Edit では file > Yoshiki> # を挿入すると全部 attachment になってしまうのでしょう。 > > ;; 初期設定のせいです。SEMI API の関知する所ではありません。 対話的に inline か attachment かを選ぶ方法は無いですよね? > ;; API に関してもとりあえず歴史的事情から私がまとめるというだけで、も > ;; ちろん、皆様の御意見を採り入れさせて頂きたいと思います。 > > ;;; API 関連文書は当面 plain text で書きますが、当初の予定通り:-) 林さ > ;;; んが XML の DTD を策定次第、その形式に移行する予定です。 ;;; うーむ。pressure が... とりあえず draft はできているんで ;;; すが、簡易 formatter を書くのが面倒で止まっています。 ;;; 最近は、日常生活に支障のでる方を優先して、XEmacs が壊れ ;;; ているのを直したりしていたのでなかなか時間が取れません。 ;;; (^^;; -- Yoshiki Hayashi From tomo @ etl.go.jp Fri Oct 29 18:44:03 1999 From: tomo @ etl.go.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko) Date: 29 Oct 1999 18:44:03 +0900 Subject: MIME-Edit, MIME-View file attachment In-Reply-To: Yoshiki Hayashi's message of "29 Oct 1999 17:30:25 +0900" References: <87bt9ur9gh.fsf@dp50.ecc.u-tokyo.ac.jp> <877lkhgkdy.fsf@dp50.ecc.u-tokyo.ac.jp> <87zoxbsuik.fsf@dp50.ecc.u-tokyo.ac.jp> <87r9in936g.fsf@dp50.ecc.u-tokyo.ac.jp> <87ogdr920m.fsf@dp50.ecc.u-tokyo.ac.jp> <87iu3z8xz2.fsf@dp50.ecc.u-tokyo.ac.jp> <87g0z38vq5.fsf@dp50.ecc.u-tokyo.ac.jp> <87zox56sf6.fsf@dp50.ecc.u-tokyo.ac.jp> <87ogdia7ry.fsf@dp50.ecc.u-tokyo.ac.jp> Message-ID: >>>>> In [emacs-mime-ja : No.00011] >>>>> "Yoshiki" = Yoshiki Hayashi wrote: Yoshiki> 下ともつながるのですが、どこまでが kernel で API なんでしょう? Yoshiki> Doc string が付いているのは API の一部であるというのを少なく Yoshiki> とも FLIM に関しては聞いたような気がするのですが。 method は kernel ではありません。つまり、mime-view-mode で v とか e を 押した時の実際の挙動を実現する部分は kernel ではありません。 ;; tm に比べて SEMI は kernel と method があんまり分離されていないので、 でまあ、仕様が曖昧であることを避けるために ・SEMI API を文書化する(某処に FLIM 1.12 API と SEMI 1.12 API が載っ ている本があるという噂も) ・SEMI 実装の maintainer をやめる ことにした訳です。 SEMI API 定義文書はとりあえず現在の構想では 第1部 MUA 界面 第2部 method 界面および内部表現 第3部 利用者界面 第4部 標準 method からなるものとし、具体的な挙動や見かけに関する規定は極力行わないように しようと思っています。 ;; 個人的には SEMI および semi-* は私の安定版の私的枝に使いたいんです ;; が、公的枝化し、APEL に準じた運用を行った方が良いかなとも思っていま ;; す。API 開発・検証用実装には REMI を用いる予定です。 MUA は要求する SEMI API の部と実装水準を持つあらゆる SEMI API の実装と 組合せ可能であることを目指します。このため、SEMI API の実装はどの部を どの水準まで実装したかを主張することにします。 このことにより、例えば林さんが SEMI API 第 1,3,4 部実装水準1を満たす 実行状況モデルを採用しない MIME UI 実装を作ることができます。で、EMH と cmail は実装水準1で動くとするとそれらを組み合わせることができると いう訳です。 Yoshiki> そうすると、変数は mime-play.el に書けばよいのでしょうか? Yoshiki> mime-play.el に書かなかったのは、一つも defcustom されていな Yoshiki> いので書かない方針なのかな、と推測しただけです。守岡さん的に Yoshiki> は、その変数が t だと current directory だと解釈すると良いの Yoshiki> でしょうか? ところで、directory だけを容易に指定できるよう Yoshiki> にしてあるはずなのですが、どこがだめなのでしょうか? なるほど(message が良くない気が)。 Yoshiki> これは gnus に倣ったのですが、たぶん directory の指定がこけ Yoshiki> ていてもちゃんとした値がでるように、という親切設計なのでしょ Yoshiki> う。別に expand-file-name でも私は構わないですが。選択は Yoshiki> maintainer にお任せします。 今は maintainer 不在なので、林さんにお任せします。 Yoshiki>>> # ところで、最近思うんですけど、どうして MIME-Edit では file Yoshiki>>> # を挿入すると全部 attachment になってしまうのでしょう。 Yoshiki> > Yoshiki> > ;; 初期設定のせいです。SEMI API の関知する所ではありません。 Yoshiki> 対話的に inline か attachment かを選ぶ方法は無いですよね? 私も良く判らないです。 ;; なんとなく、 また、SEMI API 1.14 でも各命令の挙動の詳細に関しては規定しない予定です。 ;; ただ、私は対話的に選べる実装を使いたいです。(^_^; Yoshiki> ;;; うーむ。pressure が... とりあえず draft はできているんで Yoshiki> ;;; すが、簡易 formatter を書くのが面倒で止まっています。 個人的には、とりあえず簡易 formatter がなくても DTD があれば良いです。 Yoshiki> ;;; 最近は、日常生活に支障のでる方を優先して、XEmacs が壊れ Yoshiki> ;;; ているのを直したりしていたのでなかなか時間が取れません。 Yoshiki> ;;; (^^;; ;; 私も XEmacs を使うだけのはずが、いつの間にか tm を動かせる程度に ;; XEmacs を直すようになっていて、気がつくと日常生活に支障が出る部分だ ;; け XEmacs を直すようになっていって、どんどん泥沼化した気がします。 ;; まあ、私は林さんと異なり、必殺見なかったふり攻撃や使うとこしか直さ ;; ない攻撃により、自分の評判の悪化とひきかえに泥沼から脱出したのです ;; が。(^_^;;; もっとも、2, 3 年前にもう少し体系的に直しとけば API と ;; かの問題が起こらなかったのにとか後悔もしてますが。 ;;; lazy にやると結果的にころころ API を変えることになる。 ;; そういう訳で、林さん、頑張ってください。 ;;; でも、文書関係をもっと頑張って欲しい気も。(^_^; -- ┏━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━┓ ┃『開ける価値の無い ┃守岡 知彦 (MORIOKA Tomohiko) ┃ ┃ 衣裳ダンスの扉は無い』┃ E-mail: ┃ ┗━━━━━━━━━━━━┻━━━━━━━━━━━━━━━━━━━━┛ From t90553 @ mail.ecc.u-tokyo.ac.jp Fri Oct 29 19:50:54 1999 From: t90553 @ mail.ecc.u-tokyo.ac.jp (Yoshiki Hayashi) Date: 29 Oct 1999 19:50:54 +0900 Subject: MIME-Edit, MIME-View file attachment In-Reply-To: (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko's message of "Fri, 29 Oct 1999 18:44:03 +0900") References: <87bt9ur9gh.fsf@dp50.ecc.u-tokyo.ac.jp> <877lkhgkdy.fsf@dp50.ecc.u-tokyo.ac.jp> <87zoxbsuik.fsf@dp50.ecc.u-tokyo.ac.jp> <87r9in936g.fsf@dp50.ecc.u-tokyo.ac.jp> <87ogdr920m.fsf@dp50.ecc.u-tokyo.ac.jp> <87iu3z8xz2.fsf@dp50.ecc.u-tokyo.ac.jp> <87g0z38vq5.fsf@dp50.ecc.u-tokyo.ac.jp> <87zox56sf6.fsf@dp50.ecc.u-tokyo.ac.jp> <87ogdia7ry.fsf@dp50.ecc.u-tokyo.ac.jp> Message-ID: <87r9ie8mpd.fsf@dp50.ecc.u-tokyo.ac.jp> tomo @ etl.go.jp (守岡 知彦 / MORIOKA Tomohiko) writes: > SEMI API 定義文書はとりあえず現在の構想では > > 第1部 MUA 界面 > 第2部 method 界面および内部表現 > 第3部 利用者界面 > 第4部 標準 method > > からなるものとし、具体的な挙動や見かけに関する規定は極力行わないように > しようと思っています。 API の定義をお待ちしております。:-) > ;; 個人的には SEMI および semi-* は私の安定版の私的枝に使いたいんです > ;; が、公的枝化し、APEL に準じた運用を行った方が良いかなとも思っていま > ;; す。API 開発・検証用実装には REMI を用いる予定です。 > MUA は要求する SEMI API の部と実装水準を持つあらゆる SEMI API の実装と > 組合せ可能であることを目指します。このため、SEMI API の実装はどの部を > どの水準まで実装したかを主張することにします。 > > このことにより、例えば林さんが SEMI API 第 1,3,4 部実装水準1を満たす > 実行状況モデルを採用しない MIME UI 実装を作ることができます。で、EMH > と cmail は実装水準1で動くとするとそれらを組み合わせることができると > いう訳です。 ということは、API 互換な alternative を今より簡単に作れるよ うになるということですね。 > Yoshiki> そうすると、変数は mime-play.el に書けばよいのでしょうか? > Yoshiki> mime-play.el に書かなかったのは、一つも defcustom されていな > Yoshiki> いので書かない方針なのかな、と推測しただけです。守岡さん的に > Yoshiki> は、その変数が t だと current directory だと解釈すると良いの > Yoshiki> でしょうか? ところで、directory だけを容易に指定できるよう > Yoshiki> にしてあるはずなのですが、どこがだめなのでしょうか? > > なるほど(message が良くない気が)。 これも gnus の message がそうなっているので、私には違和感は 無いのですが、短くて分かりやすい prompt があれば、お願いしま す。 # 良い提案があればそれにしますが、私の貧弱な想像力では良いも # のを思い付かないので、提案がなければあの message になって # しまうと思います。 > Yoshiki> これは gnus に倣ったのですが、たぶん directory の指定がこけ > Yoshiki> ていてもちゃんとした値がでるように、という親切設計なのでしょ > Yoshiki> う。別に expand-file-name でも私は構わないですが。選択は > Yoshiki> maintainer にお任せします。 > > 今は maintainer 不在なので、林さんにお任せします。 守岡さんが maintainer でない SEMI というのはあんまり嬉しくな いので、とりあえずこれを commit して後で怪しいことをしたくなっ たときは、私的枝を作ることにします。 > Yoshiki> ;;; うーむ。pressure が... とりあえず draft はできているんで > Yoshiki> ;;; すが、簡易 formatter を書くのが面倒で止まっています。 > > 個人的には、とりあえず簡易 formatter がなくても DTD があれば良いです。 週末に report が早く終わって、時間が取れたらがんばってみます。 (^^;; > ;; そういう訳で、林さん、頑張ってください。 私も最近は自己の利害が絡まないと壊れているのを修正しないので。 # 片足を突っこんでる project 全部同時にやるとそれを本業にし # ても時間が足りないような気が... (^^;; > ;;; でも、文書関係をもっと頑張って欲しい気も。(^_^; (^^;;; -- Yoshiki Hayashi