From tsuchiya ＠ pine.kuee.kyoto-u.ac.jp Wed Sep 12 11:05:18 2001 From: tsuchiya ＠ pine.kuee.kyoto-u.ac.jp (TSUCHIYA Masatoshi) Date: 12 Sep 2001 11:05:18 +0900 Subject: [clime] undefined base64-encode-string Message-ID: <20010912110519X.1000@pine.kuee.kyoto-u.ac.jp> 久しぶりに Mule2 からメールを送信しようとして気が付いたのですが。 encoded-text-encode-string() 内で base64-encode-string() が未定義だと いうエラーが発生します。該当部分を眺めると、 (defun encoded-text-encode-string (string encoding &optional mode) (if (string= encoding "B") (base64-encode-string string 'no-line-break) ....)) と、mel-find-function() によらず、直接に base64-encode-string() を呼び 出していますから、必要なモジュールが導入されないままになって、エラーに なっているのではないでしょうか。 とりあえず、手元では、以下のような変更をしてしのいでいるのですが、どう でしょう。 -------------- next part -------------- --- mel.el 28 Dec 2000 01:38:11 -0000 1.23.8.4 +++ mel.el 12 Sep 2001 00:30:42 -0000 @@ -191,7 +191,8 @@ (and (fboundp 'base64-encode-string) (subrp (symbol-function 'base64-encode-string)))) -(when mel-b-builtin +(if (not mel-b-builtin) + (require 'mel-b-el) (mel-define-backend "base64") (mel-define-method-function (mime-encode-string string (nil "base64")) 'base64-encode-string) -------------- next part -------------- -- 土屋 雅稔 ( TSUCHIYA Masatoshi ) From yamaoka ＠ jpl.org Wed Sep 12 11:18:31 2001 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: Wed, 12 Sep 2001 11:18:31 +0900 Subject: [clime] undefined base64-encode-string References: <20010912110519X.1000@pine.kuee.kyoto-u.ac.jp> Message-ID: >>>>> In [emacs-mime-ja : No.00937] >>>>> TSUCHIYA Masatoshi wrote: 土屋さん> 久しぶりに Mule2 からメールを送信しようとして気が付いたので 土屋さん> すが。 土屋さん> encoded-text-encode-string() 内で base64-encode-string() が 土屋さん> 未定義だというエラーが発生します。該当部分を眺めると、 [...] 土屋さん> と、mel-find-function() によらず、直接に 土屋さん> base64-encode-string() を呼び出していますから、必要なモジュー 土屋さん> ルが導入されないままになって、エラーになっているのではないで 土屋さん> しょうか。 ありゃ、ほんとですね。ぼくはたぶん mel より先に Gnus の base64 を load してしまっていたので、気が付かなかったのかもしれません。 土屋さん> とりあえず、手元では、以下のような変更をしてしのいでいるので 土屋さん> すが、どうでしょう。 土屋さん> -(when mel-b-builtin 土屋さん> +(if (not mel-b-builtin) 土屋さん> + (require 'mel-b-el) たぶん、他の base64 codec とカチ合う心配はいらなくて、これで良さ そうな気がします。commit お願いできますか? -- Katsumi Yamaoka From tsuchiya ＠ pine.kuee.kyoto-u.ac.jp Wed Sep 12 12:32:39 2001 From: tsuchiya ＠ pine.kuee.kyoto-u.ac.jp (TSUCHIYA Masatoshi) Date: 12 Sep 2001 12:32:39 +0900 Subject: [clime] undefined base64-encode-string In-Reply-To: (Katsumi Yamaoka's message of "Wed, 12 Sep 2001 11:18:31 +0900") References: <20010912110519X.1000@pine.kuee.kyoto-u.ac.jp> Message-ID: <20010912123239C.1000@pine.kuee.kyoto-u.ac.jp> >> On Wed, 12 Sep 2001 11:18:31 +0900 >> 「山」== yamaoka ＠ jpl.org (Katsumi Yamaoka) said as follows: 山> たぶん、他の base64 codec とカチ合う心配はいらなくて、これで良さ 山> そうな気がします。commit お願いできますか? しました。 ;; 例によって、FSF Emacs と XEmacs の文字コード非互換問題が発生しまし ;; た…。いつも利用している pcl-cvs を使うと余分な変更が入ってしまうの ;; で、XEmacs を使ったり、vi を使ったり等、かなり苦労してしまいました。 -- 土屋 雅稔 ( TSUCHIYA Masatoshi ) From yamaoka ＠ jpl.org Wed Sep 12 13:29:46 2001 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: Wed, 12 Sep 2001 13:29:46 +0900 Subject: [clime] undefined base64-encode-string References: <20010912110519X.1000@pine.kuee.kyoto-u.ac.jp> <20010912123239C.1000@pine.kuee.kyoto-u.ac.jp> Message-ID: >>>>> In [emacs-mime-ja : No.00939] >>>>> TSUCHIYA Masatoshi wrote: 山> commit お願いできますか? 土屋さん> しました。 どうもありがとうございます。 ;; って、ぼくは CLIME のメインテイナーぢゃありませんけどね。^^;; 土屋さん> ;; 例によって、FSF Emacs と XEmacs の文字コード非互換問題が 土屋さん> ;; 発生しました…。いつも利用している pcl-cvs を使うと余分な 土屋さん> ;; 変更が入ってしまうので、XEmacs を使ったり、vi を使ったり 土屋さん> ;; 等、かなり苦労してしまいました。 ああ、ChangeLog にある codename ですね。何ですかねえ。ぼくの手元 にある Emacsen ではどれも守岡さんが書かれたものと同じにならなかっ たので、いつも binary で find-file して、非ascii 文字を書くとき は手でエンコードしてからさらに ESC などの位置を調整していました。 ですから、codename については FLIM 1.14 の ChangeLog との差異は 無いと思います。 何度も懲りた経験から、*.el ファイルなども含めて通常は binary で find-file/save-buffer しています。ま、変に差分が増えるのを気にし なければ、何でも良いのかもしれませんが。 -- Katsumi Yamaoka From keiichi ＠ nanap.org Thu Sep 13 09:41:19 2001 From: keiichi ＠ nanap.org (Keiichi Suzuki) Date: 13 Sep 2001 09:41:19 +0900 Subject: [clime] undefined base64-encode-string In-Reply-To: References: <20010912110519X.1000@pine.kuee.kyoto-u.ac.jp> <20010912123239C.1000@pine.kuee.kyoto-u.ac.jp> Message-ID: >>>>> emacs-mime-ja の No. 00940 >>>>> Message-Id: で、 >>>>> "山岡" == Katsumi Yamaoka さま曰く... 山岡> ああ、ChangeLog にある codename ですね。何ですかねえ。ぼくの手元 山岡> にある Emacsen ではどれも守岡さんが書かれたものと同じにならなかっ 山岡> たので、いつも binary で find-file して、非ascii 文字を書くとき 山岡> は手でエンコードしてからさらに ESC などの位置を調整していました。 山岡> ですから、codename については FLIM 1.14 の ChangeLog との差異は 山岡> 無いと思います。 FSF Emacs で x-ctext ではだめですか? 今， FLIM 1.14 の ChangeLog をいじって， C-x v = してみたのです が，おかしなことにはならないようです。 -- 鈴木圭一 / keiichi ＠ nanap.org PGP finger print (DH/DSS) 0B32 B37E 6DE9 3BC1 68A4 4089 7AAF 2B03 ECBD 614B From yamaoka ＠ jpl.org Thu Sep 13 10:30:23 2001 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: Thu, 13 Sep 2001 10:30:23 +0900 Subject: [clime] undefined base64-encode-string References: <20010912110519X.1000@pine.kuee.kyoto-u.ac.jp> <20010912123239C.1000@pine.kuee.kyoto-u.ac.jp> Message-ID: >>>>> In [emacs-mime-ja : No.00941] >>>>> Keiichi Suzuki wrote: 圭一さん> FSF Emacs で x-ctext ではだめですか? 圭一さん> 今， FLIM 1.14 の ChangeLog をいじって， C-x v = してみたの 圭一さん> ですが，おかしなことにはならないようです。 iso-2022-7bit の方が良いみたい。 現在の FLIM 1.14 の ChangeLog では元々 x-ctext が使われているん じゃないでしょうか? これを FSFmacs で単純に find-file すると buffer-file-coding-system が iso-2022-8bit-ss2-unix になり、 codename は正しくデコードされません。また、XEmacs で同じことをす ると raw-text、すなわちデコードすることを放棄してしまうようです。 x-ctext を指定して find-file すると、当然ながらちゃんとデコード され、一部を書き換えて save しても FSFmacs と XEmacs ともに同じ ファイルを作ってくれます。 しかし、いったん iso-2022-7bit にしてしまえば、 FSFmacs と XEmacs の両方とも coding-system を意識せずに編集できるようになり ます。 もっともぼくは Emacs の自動デコードをハナから信用していないので、 意識しなくて良い、と言われても常に気にしてしまいますけれど。:-p -- Katsumi Yamaoka From tomo ＠ m17n.org Wed Sep 19 14:49:54 2001 From: tomo ＠ m17n.org (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko) Date: 19 Sep 2001 14:49:54 +0900 Subject: LEMI (Re: bug fixes for ...) In-Reply-To: Larry Hunter's message of "Tue, 18 Sep 2001 14:37:16 -0600" References: <200108162347.f7GNlqA03312@huge.uchsc.edu> <200109182037.f8IKbGf05609@huge.uchsc.edu> Message-ID: >>>>> In <200109182037.f8IKbGf05609 ＠ huge.uchsc.edu> >>>>> "Larry" = Larry Hunter wrote: Larry> I am in the process of making the upgrade to emacs 21. In your Larry> email from last month, you said that you have a supplemental Larry> package for emacs 21. Would it be possible for me to obtain Larry> that package without causing you too much trouble? How should Larry> I do it? Now I prepared public CVS repository for the package. If you can use cvs via the Internet, please try following: ====================================================================== ** cvs login (first time only) % cvs -d :pserver:anonymous ＠ cvs.m17n.org:/cvs/root login CVS password: [CR] # NULL string ** checkout % cvs -d :pserver:anonymous ＠ cvs.m17n.org:/cvs/root co lemi ====================================================================== Unfortunately it does not contain Makefile to compile *.el files yet, so please compile each file by hand. Best regards, -- tomo. From ueno ＠ unixuser.org Tue Sep 25 01:19:48 2001 From: ueno ＠ unixuser.org (Daiki Ueno) Date: Tue, 25 Sep 2001 01:19:48 +0900 Subject: EMIKO 1.14.0 (Zoomastigophora) Message-ID: 懸案事項はだいたいクリアできたような気がするので、EMIKO 1.14.0 を リリースします。 http://deisui.bug.org/~ueno/emacs-lisp/emiko-1.14.0.tar.gz * 状態 alpha * 必須環境 GNU Emacs 20.7 or greater XEmacs 21.4 or greater FLIM 1.14 or greater * 変更点 Oort Gnus に倣い、添付ファイルのパートに font-lock を施す。 初期状態で閉じている entity を C-c C-t C-c で正しく開閉できる(はず)。 C-u C-c C-v C-c などにより、CTE: および MIME-charset: を指定できる。 ;; EMY の実装を参考にしましたが、XEmacs without MULE でも動作すると思います。 vcard.el (http://www.splode.com/~friedman/software/emacs-lisp/) がインストールされていれば、text/x-vcard のパートを整形する。 (load "mime-setup") 以降に (setq mime-setup-enable-inline-html nil) な どを設定しても期待通りに動作する。 mime-play-entity コマンドの呼ばれかたにより method の選択方法を変えるよ うにした。(マウスの第 2 ボタンで選択された場合にはポップアップメニューを、 そうでなければミニバッファから読み込む) entity button を widget で再実装した。 PGG のマニュアルを附属 (pgg.texi) -- Daiki Ueno From ueno ＠ unixuser.org Fri Sep 28 11:54:30 2001 From: ueno ＠ unixuser.org (Daiki Ueno) Date: Fri, 28 Sep 2001 11:54:30 +0900 Subject: [T] support EMIKO 1.14 In-Reply-To: (Katsumi Yamaoka's message of "Thu, 27 Sep 2001 21:09:39 +0900") References: Message-ID: ;; Cc: emacs-mime-ja >>>>> In [semi-gnus-ja : No.6320] >>>>> Katsumi Yamaoka wrote: > EMIKO 1.14 の MIME-Edit で T-gnus が正しくメールやニュースを送信 > できるようにしました。t-gnus-6_15 枝と t-gnus-6_15-quimby 枝の両 > 方です。 > EMIKO 1.14 を使っている場合に、記事に絵などを挿入した後で text > タグを付けずに平文を書いてしまうと、今まではその文章が絵などのデー > タの一部としてエンコードされてしまっていました。 > 今まで放っておいてすみません。今日 xemacs-beta で送信に失敗して > 初めて問題に気が付きました。 > ;; 過去にあんな方法で対処したのが間違いの元なんですが。^^;; mime-edit-invisible を付加することにした時の記憶が既におぼろげなので、 もう一度 T-gnus の message.el を眺めてみたのですが、 (1) EMIKO 以外の SEMI は `invisible-region' を使って付加した invisible プロパティをパートの境界を判断するのに利用している。 (2) message.el 内で `invisible-region' を `message-invisible-region' に 置き換えて、特定の領域からは invisible プロパティを剥ぎ取らないように、 message-invisible プロパティで印をつけている。 (3) EMIKO は `message-invisible-region' 相当のものを自前で用意しているた め、(1) (2) が効かなかった。 という理解でよろしいでしょうか。 素人考えで申し訳ありませんが、他に方法はないかと考えてみました。 * `message-send' で、テキストプロパティを一切剥ぎ取らない。 → X-Face utility などとの兼ね合いから、これでは悲しいことになる? * `gnus-copy-article-buffer' を変更して、*Article* バッファからコピーする 時点で、(2) のアプローチとは逆に invisible プロパティを剥ぎ取っても良い 領域に message-invisible プロパティを付加する。 * `x-face-mule-hidden-properties' 相当の変数を EMIKO に用意する。 ;; `mime-edit-invisible' という名前は、あまりにもあんまりなので…。 たぶん山岡さんは、このような代替案はあらかた考慮されていると思いますが、 もしよろしければ、これら各方法に関して御意見を頂けますでしょうか? 勿論、 新たな代案も歓迎します。 P.S. EMIKO の `mime-edit-content-end' の修正ありがとうございます。 -- Daiki Ueno From yamaoka ＠ jpl.org Fri Sep 28 14:32:49 2001 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: Fri, 28 Sep 2001 14:32:49 +0900 Subject: [T] support EMIKO 1.14 References: Message-ID: >>>>> In [emacs-mime-ja : No.00945] >>>>> Daiki Ueno wrote: 上野さん> たぶん山岡さんは、このような代替案はあらかた考慮されていると 上野さん> 思いますが、 考えてませんて。この問題の対策を行なうのはたぶんこれで三回目です が、その都度何が起こっているかを調べ直しているザマですから。:-p 上野さん> mime-edit-invisible を付加することにした時の記憶が既におぼろ 上野さん> げなので、もう一度 T-gnus の message.el を眺めてみたのですが、 ぼくも自分の鶏頭にしっかり刷り込むために、考えながらコメントして みます。実はあんな変なことはやらなくても良いのではないかと思い始 めています。 上野さん> (1) EMIKO 以外の SEMI は `invisible-region' を使って付加した 上野さん> invisible プロパティをパートの境界を判断するのに利用している。 そうですね。そして、エンコードするときに invisible な領域の直後 に MIME tag 以外のものがあったら text の tag を挿入するのは少な くとも後期の tm では行なわれていますから、これは伝統と言っても良 さそうです。 一方 tm をかなりお手本にしたと思われる v5.8 以降の Gnus では tag の文字列が情報のすべてであって、SEMI のように binary データの実 体を人間が編集するバッファに挿入しない代わりに、binary データの tag を挿入した場所の先に何も無くても text の tag を必ず付けます。 揮発性の高い text property に依存しないこの方法も、ぼくは確実で 良いと思っています。 上野さん> (2) message.el 内で `invisible-region' を 上野さん> `message-invisible-region' に置き換えて、特定の領域からは 上野さん> invisible プロパティを剥ぎ取らないように、message-invisible 上野さん> プロパティで印をつけている。 はい。この関数の置き換えは、後々何をやっているのか忘れてしまいそ うで心配だったのですが、案の定でありました。^^;; Semi-gnus の良いところは、人間が編集するバッファとエンコードする バッファが別になっていることで、万が一送信に失敗しても最初から書 き直したりエンコードによる変更を undo する必要がありません。 でも Gnus は message の処理のいろんな区切り目に (undo-boundary) を入れてあるので、T-gnus でも同様のことができるような気がします。 あるいはエンコードするときは元のバッファの内容を別の場所にコピー して保存するようにしても良いわけですし。 そして次が問題なのですが、編集用のバッファからエンコード用のバッ ファに内容物をコピーするときに、T-gnus では Gnus の message-send-mail に倣ってすべての text-property をはぎ取ってい ます。ただし invisible または mime-edit-invisible は残します。 上野さん> (3) EMIKO は `message-invisible-region' 相当のものを自前で用 上野さん> 意しているため、(1) (2) が効かなかった。 はいそうです。昨日までの T-gnus では mime-edit-invisible を消し てしまっていました。 どうもぼくは何も考えずに Gnus をデッドコピーしたのではないかと思 うのですが、T-gnus ではすべての text-property をはぎ取る必要は無 かったのではないか。もしそうならば、これをやめることによって問題 の 70% は消えてしまいます。Chaos を覗いてみると実際にそんなこと はしていませんし。 上野さん> * `message-send' で、テキストプロパティを一切剥ぎ取らない。 上野さん> → X-Face utility などとの兼ね合いから、これでは悲しいことに 上野さん> なる? X-Face util? はて、自分では何も思い出せないので、ともかく実験が 必要ですね。^^;; 上野さん> * `gnus-copy-article-buffer' を変更して、*Article* バッファ 上野さん> からコピーする時点で、(2) のアプローチとは逆に invisible プ 上野さん> ロパティを剥ぎ取っても良い領域に message-invisible プロパティ 上野さん> を付加する。 うーむ、これもわからんぞ。article から持ってきたものを MIME-Edit でエンコードするのって、どういうときでしたっけ? ^^;; message バッファからエンコード用のバッファに移すときにそうするの は良いでしょうね。 前に 70% と書きました。残りの 30% は何かというと、T-gnus には (Gnus にも) 人間が編集するバッファに不可視なものがあったら、 「こんなものがあるけど、このまま送信しちゃっていいの?」とユーザ に見せてお伺いをたてる機能があります。ここで MIME-Edit が挿入し たデータも対象になってしまうのは煩わしいので、現在はチェックする ときだけ invisible を解除していて、その判別に mime-edit-invisible ないしは mime-edit-invisible の印が必要です。 たいした違いではないですが、そういう印が付いていたらチェック対象 にならないようにすることも可能でしょう。 上野さん> * `x-face-mule-hidden-properties' 相当の変数を EMIKO に用意 上野さん> する。 上野さん> ;; `mime-edit-invisible' という名前は、あまりにもあん 上野さん> ;; まりなので…。 ではどんな名前が良いでしょう? :-) すでに普及している EMIKO との互換性を保つためには、このままにし ておくのが良いような気もしますが。と言うのは、 ここまで書いて思い付いた今後の方針: ・副作用が無いならば、編集用のバッファからエンコード用のバッファ にコピーするときに一切の text property をはぎ取らない。 ・mime-edit-invisible が付いている部分は不可視領域のチェック対象 から外す。 ・invisible-region を置き換える関数 message-invisible-region が 付加する property は、現在の message-invisible に代わって mime-edit-invisible とする。 といったところでいかがでしょうか? -- Katsumi Yamaoka ;; すみません、長くて。^^;; From ueno ＠ unixuser.org Fri Sep 28 15:48:50 2001 From: ueno ＠ unixuser.org (Daiki Ueno) Date: Fri, 28 Sep 2001 15:48:50 +0900 Subject: [T] support EMIKO 1.14 In-Reply-To: (Katsumi Yamaoka's message of "Fri, 28 Sep 2001 14:32:49 +0900") References: Message-ID: >>>>> In [semi-gnus-ja : No.6331] >>>>> Katsumi Yamaoka wrote: 上野> * `message-send' で、テキストプロパティを一切剥ぎ取らない。 上野> → X-Face utility などとの兼ね合いから、これでは悲しいことに 上野> なる? 山岡さん> X-Face util? はて、自分では何も思い出せないので、ともかく実験が 山岡さん> 必要ですね。^^;; [T] Invisible text found and made visible...? http://lists.airs.net/semi-gnus/archive/200006/msg00002.html あたりの話だと思います。 上野> * `gnus-copy-article-buffer' を変更して、*Article* バッファ 上野> からコピーする時点で、(2) のアプローチとは逆に invisible プ 上野> ロパティを剥ぎ取っても良い領域に message-invisible プロパティ 上野> を付加する。 山岡さん> うーむ、これもわからんぞ。article から持ってきたものを MIME-Edit 山岡さん> でエンコードするのって、どういうときでしたっけ? ^^;; 山岡さん> message バッファからエンコード用のバッファに移すときにそうするの 山岡さん> は良いでしょうね。 編集用の message バッファに、MIME-Edit の関数以外の手で invisible プロパ ティが付加されるタイミングを考えていました。主なものとしては以下のふたつ ではないかと思いますが、よく調べていないので、後者は僕の完全な思い違いか もしれません。 ・X-Face utility のようなツールを使って message バッファに何らかの不可視 属性をつける必要がある場面 ・*Article* バッファにて既に invisible プロパティがついているテキストを、 message バッファにそのままコピーしてきた時 上野> * `x-face-mule-hidden-properties' 相当の変数を EMIKO に用意 上野> する。 上野> ;; `mime-edit-invisible' という名前は、あまりにもあん 上野> ;; まりなので…。 山岡さん> ではどんな名前が良いでしょう? :-) mmediting を利用した MIME-Edit next generation が登場した暁には、 mime-view-entity-body に対応する mime-edit-entity-body のようなプロパティ が用意されるのではないかと勝手に予想していました。^^;; それはそれとして、純粋にパートの境界を判断するためのプロパティであるのに mime-edit-*invisible* という名前では、あまり実状を表していないと思うのです。 山岡さん> すでに普及している EMIKO との互換性を保つためには、このままにし 山岡さん> ておくのが良いような気もしますが。 現在の EMY にも、同時に同様のコードが盛り込まれた記憶があるので、やはり、 このままにしておくのが良いのかもしれません。 山岡さん> ここまで書いて思い付いた今後の方針: 山岡さん> ・副作用が無いならば、編集用のバッファからエンコード用のバッファ 山岡さん> にコピーするときに一切の text property をはぎ取らない。 山岡さん> ・mime-edit-invisible が付いている部分は不可視領域のチェック対象 山岡さん> から外す。 山岡さん> ・invisible-region を置き換える関数 message-invisible-region が 山岡さん> 付加する property は、現在の message-invisible に代わって 山岡さん> mime-edit-invisible とする。 なるほど。名前をそちらに揃えてしまう手もありますね。 -- Daiki Ueno From yamaoka ＠ jpl.org Fri Sep 28 16:31:09 2001 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: Fri, 28 Sep 2001 16:31:09 +0900 Subject: [T] support EMIKO 1.14 References: Message-ID: >>>>> In [semi-gnus-ja : No.6336] >>>>> Daiki Ueno wrote: 山岡> X-Face util? はて、自分では何も思い出せないので、ともかく実験が 山岡> 必要ですね。^^;; 上野さん> [T] Invisible text found and made visible...? 上野さん> http://lists.airs.net/semi-gnus/archive/200006/msg00002.html 上野さん> あたりの話だと思います。 自分でやってみてすぐにわかりました。その記事に書いた (add-hook 'mime-edit-translate-hook 'x-face-xmas-remove-x-face-glyph) は効かず、T-gnus では (add-hook 'message-send-hook 'x-face-xmas-remove-x-face-glyph) でないとだめでした。^^;; 上野さん>> * `gnus-copy-article-buffer' を変更して、*Article* バッファ 上野さん>> からコピーする時点で、(2) のアプローチとは逆に invisible プ 上野さん>> ロパティを剥ぎ取っても良い領域に message-invisible プロパティ 上野さん>> を付加する。 山岡> うーむ、これもわからんぞ。article から持ってきたものを MIME-Edit 山岡> でエンコードするのって、どういうときでしたっけ? ^^;; 山岡> message バッファからエンコード用のバッファに移すときにそうするの 山岡> は良いでしょうね。 上野さん> 編集用の message バッファに、MIME-Edit の関数以外の手で 上野さん> invisible プロパティが付加されるタイミングを考えていました。 上野さん> 主なものとしては以下のふたつではないかと思いますが、よく調べ 上野さん> ていないので、後者は僕の完全な思い違いかもしれません。 上野さん> ・X-Face utility のようなツールを使って message バッファに何 上野さん> らかの不可視属性をつける必要がある場面 上野さん> ・*Article* バッファにて既に invisible プロパティがついてい 上野さん> るテキストを、message バッファにそのままコピーしてきた時 理解しました。 X-Face util などは利用者が自分で対策するとして、後者は警告の対象 にすべきですが、現在の message-send ではすでに実現されていますね。 上野さん>> ;; `mime-edit-invisible' という名前は、あまりにもあんまりな 上野さん>> ;; ので…。 山岡> ではどんな名前が良いでしょう? :-) 上野さん> mmediting を利用した MIME-Edit next generation が登場した暁 上野さん> には、mime-view-entity-body に対応する mime-edit-entity-body 上野さん> のようなプロパティが用意されるのではないかと勝手に予想してい 上野さん> ました。^^;; 上野さん> それはそれとして、純粋にパートの境界を判断するためのプロパティ 上野さん> であるのに mime-edit-*invisible* という名前では、あまり実状 上野さん> を表していないと思うのです。 まあ確かにそうですね。 山岡> すでに普及している EMIKO との互換性を保つためには、このままにし 山岡> ておくのが良いような気もしますが。 上野さん> 現在の EMY にも、同時に同様のコードが盛り込まれた記憶がある 上野さん> ので、やはり、このままにしておくのが良いのかもしれません。 う、EMY があったか。後で EMY に変えてみよう。 山岡> ここまで書いて思い付いた今後の方針: [...] 山岡> ・invisible-region を置き換える関数 message-invisible-region が 山岡> 付加する property は、現在の message-invisible に代わって 山岡> mime-edit-invisible とする。 上野さん> なるほど。名前をそちらに揃えてしまう手もありますね。 では、もしとても良い名前が見つかったら、... ううむ ...、やはり 少なくとも T-gnus, EMIKO および EMY の三者は、当分の間は新旧両方 の名前に対応しなければならいってことになるでしょうか。^^;; ;; T-gnus の改造は、もしやるとしたら来週以降にします。 -- Katsumi Yamaoka From ueno ＠ unixuser.org Sat Sep 29 06:17:55 2001 From: ueno ＠ unixuser.org (Daiki Ueno) Date: Sat, 29 Sep 2001 06:17:55 +0900 Subject: [T] support EMIKO 1.14 In-Reply-To: (Katsumi Yamaoka's message of "Fri, 28 Sep 2001 16:31:09 +0900") References: Message-ID: >>>>> In [emacs-mime-ja : No.00948] >>>>> Katsumi Yamaoka wrote: 上野> 編集用の message バッファに、MIME-Edit の関数以外の手で 上野> invisible プロパティが付加されるタイミングを考えていました。 上野> 主なものとしては以下のふたつではないかと思いますが、よく調べ 上野> ていないので、後者は僕の完全な思い違いかもしれません。 上野> ・X-Face utility のようなツールを使って message バッファに何 上野> らかの不可視属性をつける必要がある場面 上野> ・*Article* バッファにて既に invisible プロパティがついてい 上野> るテキストを、message バッファにそのままコピーしてきた時 山岡さん> 理解しました。 山岡さん> X-Face util などは利用者が自分で対策するとして、後者は警告の対象 山岡さん> にすべきですが、現在の message-send ではすでに実現されていますね。 そうですね。message バッファが用意されてからも、利用者が他のバッファから message バッファに手でカットアンドペーストする場面も考えられますから、や はり、現状のまま MIME-Edit での invisible プロパティの扱いを一時的に変更 するのが最良の方針だと思います。 上野> 現在の EMY にも、同時に同様のコードが盛り込まれた記憶がある 上野> ので、やはり、このままにしておくのが良いのかもしれません。 山岡さん> う、EMY があったか。後で EMY に変えてみよう。 すみません、これは真赤な嘘でした。 ;; 何を勘違いしていたのだろう? ^^;; 山岡さん> ・invisible-region を置き換える関数 message-invisible-region が 山岡さん> 付加する property は、現在の message-invisible に代わって 山岡さん> mime-edit-invisible とする。 上野> なるほど。名前をそちらに揃えてしまう手もありますね。 山岡さん> では、もしとても良い名前が見つかったら、... ううむ ...、やはり 山岡さん> 少なくとも T-gnus, EMIKO および EMY の三者は、当分の間は新旧両方 山岡さん> の名前に対応しなければならいってことになるでしょうか。^^;; invisible プロパティに依存しない MIME-Edit が現れて、それを仮定した T-gnus が登場するまでの繋ぎと考えると、別に名前には拘る必要がないように 思えてきました。というわけで、前言は撤回します。 -- Daiki Ueno