From yoshiki @ xemacs.org Wed Mar 1 15:00:40 2000 From: yoshiki @ xemacs.org (Yoshiki Hayashi) Date: Wed, 01 Mar 2000 15:00:40 +0900 Subject: EMIKO mimd-display-image In-Reply-To: (Daiki Ueno's message of "Tue, 29 Feb 2000 17:36:31 +0900") References: <87ln44ijnb.fsf@dp50.ecc.u-tokyo.ac.jp> Message-ID: <87zosj44c7.fsf@dp50.ecc.u-tokyo.ac.jp> Daiki Ueno writes: > > mime-image.el の mime-display-image にある、 > > > > (save-window-excursion > > (set-window-buffer (selected-window)(current-buffer)) > > (sit-for 0)) > > > > の部分は何のためにあるのでしょうか? これがあると buffer が > > narrowing されて画像を表示した状態で一瞬止まるので、とても変 > > な感じです。すくなくとも、XEmacs では上の code を取り外して > > も動いているようです。 > > 一時ファイルを作っていたときの名残りなので、取り除いて良いと思います。 > > ;; Emacs21 の image は、実際に可視になった時点で初めて具体化されるので、 > ;; 一時ファイルを消す前に強制的に redisplay させていた、と。 なるほど。取り除いたものを EMIKO と EMY に commit しました。 -- Yoshiki Hayashi From tomo @ m17n.org Wed Mar 1 18:43:42 2000 From: tomo @ m17n.org (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko) Date: 01 Mar 2000 18:43:42 +0900 Subject: REMI 1.14.1 =?ISO-2022-JP?B?KBskQkNuQG5CZz95GyhCKQ==?= Message-ID: [状態] alpha [必要な環境] APEL: 9.20 以降 FLIM: 1.13.1 以降 -------------- next part -------------- [変更点] 2000-03-01 MORIOKA Tomohiko * REMI: Version 1.14.1 (Mushigawa?sugi) released. 2000-03-01 MORIOKA Tomohiko * mime-view.el (mime-view-define-keymap): Add new binding `mime-preview-show-header' for C-c C-v C-f and C-c C-v h; add new binding `mime-preview-show-content' for C-c C-v C-c; add new binding `mime-preview-hide-header' for C-c C-d C-f and C-c C-d h; add new binding `mime-preview-hide-content' for C-c C-d C-c. (mime-preview-toggle-display): New function. (mime-preview-toggle-header): Add new optional argument `force-visible'; use `mime-preview-toggle-display'. (mime-preview-toggle-content): Likewise. (mime-preview-show-header): New function. (mime-preview-show-content): New function. (mime-preview-hide-header): New function. (mime-preview-hide-content): New function. 2000-02-25 MORIOKA Tomohiko * mime-view.el (mime-situation-examples-file-coding-system): New variable. (mime-save-situation-examples): Use `with-temp-buffer'; try to save as `mime-situation-examples-file-coding-system'. - Use with-temp-buffer to load `mime-situation-examples-file'; setup `mime-situation-examples-file-coding-system' when mime-situation-examples-file is loaded; 2000-02-25 MORIOKA Tomohiko * mime-view.el (mime-view-define-keymap): Change keybind for `mime-preview-toggle-header' to C-c C-t h and C-c C-t C-f. 2000-02-24 Mito * mime-edit.el (mime-edit-normalize-body): Fix number of arguments against enriched-encode. 2000-02-23 Daiki Ueno * mime-image.el (mime-image-normalize-xbm-buffer): New inline function. (mime-image-create) [XEmacs || Emacs21]: Use it for XBM data. (mime-display-image): Don't create temporary file. 2000-02-22 MORIOKA Tomohiko * mime-view.el (mime-delq-null-situation): Accept multiple ignored values. (mime-unify-situations): t is also regarded as an ignored-value. (mime-preview-follow-current-entity): Eliminate unused local variable `str'. 2000-02-22 MORIOKA Tomohiko * mime-play.el (mime-play-find-every-situations): Renamed from `mime-view-find-every-situations'. * mime-view.el (mime-view-find-every-situations): Moved to mime-play.el. 2000-02-22 MORIOKA Tomohiko * mime-play.el (mime-play-entity): Specify `mime-view-find-every-situations' as an optional argument `every-situations'. * mime-view.el (mime-unify-situations): Add new optional argument `every-situations'; use it instead of `mime-view-find-every-situations'. (mime-display-multipart/alternative): Modify `body' property instead of `body-presentation-method' property of preview-situation. * semi-setup.el: Use `eval-after-load' for text/html related setting. 2000-02-21 Daiki Ueno * semi-def.el (mime-user-interface-product): Bump up to EMIKO 1.13.12. * pgg.el (pgg-temp-buffer-show-function): Use `shrink-window-if-larger-than-buffer'. * pgg-gpg.el (pgg-gpg-process-region): Fix cleanup form. * pgg-pgp.el (pgg-pgp-process-region): Ditto. * pgg-pgp5.el (pgg-pgp5-process-region): Ditto. * semi-setup.el (mime-setup-enable-inline-image): Remove checking of bitmap-mule; use `eval-after-load' instead of `call-after-loaded' to require `mime-image'. * mime-image.el (mime-display-image): Set default umask to 077. (mime-image-create): Use `nothing-image-instance-p'. * mime-pgp.el: When it is compiled, define `smime-output-buffer' and `smime-errors-buffer' to avoid compiler warning. * mime-edit.el: Ditto. * mime-pgp.el (mime-view-application/pkcs7-mime): Regard smime-type as "enveloped-data" unless it is specified. * smime.el (smime-directory-files): Abolish. (smime-verify-region): Abolish local variable `args'. 2000-02-20 Daiki Ueno * mime-image.el: Remove X-Face setting; require cl when compiling. (mime-image-format-alist): Remove image/x-mag and image/x-pic. (mime-image-type-available-p): New function. (mime-image-create): New function. (mime-image-insert): New function. (mime-display-image): Rewrite. * mime-edit.el (mime-edit-define-charset): Handle 'mime-charset-comment. 2000-02-18 MORIOKA Tomohiko * mime-view.el (mime-view-define-keymap): Change binding of `mime-preview-toggle-content' from C-c C-t C-b to C-c C-t C-c. (mime-preview-toggle-content): Renamed from `mime-preview-toggle-body'. -------------- next part -------------- It is available from ftp://ftp.m17n.org/pub/mule/semi/semi-1.14-for-flim-1.13 or ftp://ftp.etl.go.jp/pub/mule/semi/semi-1.14-for-flim-1.13 -------------- next part -------------- -- 感じてたことさ ; 守岡 知彦 (MORIOKA Tomohiko) ずっとずっと前から ; Email: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; From tomo @ m17n.org Wed Mar 1 19:12:33 2000 From: tomo @ m17n.org (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko) Date: 01 Mar 2000 19:12:33 +0900 Subject: Chao 1.14.0 =?ISO-2022-JP?B?KBskQkVtOzMbKEIp?= Message-ID: [状態] alpha [必要な環境] APEL: 9.22 以降 [FLIM 1.13.2 からの変更点] 2000-03-01 MORIOKA Tomohiko * Chao: Version 1.14.0 (Momoyama) released. 2000-01-05 Katsumi Yamaoka * Makefile, mime-en.sgml, mime-ja.sgml: Update for the new CVS server. 1999-12-20 Katsumi Yamaoka * mel-b-el.el (base64-encode-region): Allow the optional second arg `no-line-break'. (base64-external-encode-region): Likewise. (base64-internal-encode-region): Likewise. (base64-encode-string): Likewise. 1999-12-16 MORIOKA Tomohiko * FLIM-ELS (flim-modules): Add `mmexternal'. * mime-parse.el (mime-parse-external): New function. * mime-def.el (mime-entity-children [mime-entity]): Use `mime-parse-external' for message/external-body. * mmexternal.el: New module. 1999-12-13 Katsumi Yamaoka * README.en, README.ja, mime-en.sgml, mime-ja.sgml: Update for the recent ML address and ftp site. 1999-10-17 Yoshiki Hayashi * FLIM-MK (install-flim-package): Delete auto-autoloads.el and custom-load.el 1999-09-20 Katsumi Yamaoka * mailcap.el (mailcap-look-at-schar): Protect against unexpected eof. [cf. ] 1999-09-13 Katsumi Yamaoka * smtpmail.el (smtpmail-send-it): Remove needless `concat'. 1999-09-08 Yoshiki Hayashi * mime-ja.sgml, mime-en.sgml (Entity creation): Fix typo. 1999-09-01 Katsumi Yamaoka * smtpmail.el (smtpmail-send-it): Make directory `smtpmail-queue-dir' if it does not exist; convert filename of queued mail using `convert-standard-filename'. (smtpmail-queue-index): Treat `smtpmail-queue-dir' as a directory name using `file-name-as-directory'. (smtpmail-queue-dir, smtpmail-queue-mail): Remove "*" from doc strings. 1999-08-26 Katsumi Yamaoka * smtpmail.el (smtpmail-send-it): Use `time-stamp-yyyy-mm-dd' and `time-stamp-hh:mm:ss' instead of `current-time'. 1999-08-25 Katsumi Yamaoka * FLIM-ELS: Use `if' instead of `unless'. -------------- next part -------------- It is available from ftp://ftp.m17n.org/pub/mule/flim/flim-1.14 or ftp://ftp.etl.go.jp/pub/mule/flim/flim-1.14 -------------- next part -------------- -- 感じてたことさ ; 守岡 知彦 (MORIOKA Tomohiko) ずっとずっと前から ; Email: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; From tomo @ etl.go.jp Thu Mar 2 16:09:43 2000 From: tomo @ etl.go.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko) Date: 02 Mar 2000 16:09:43 +0900 Subject: mime-entity- and mime-message- In-Reply-To: tomo@etl.go.jp's message of "23 Feb 2000 17:34:44 +0900" References: Message-ID: >>>>> In [emacs-mime-ja : No.00439] >>>>> "守岡" = tomo @ etl.go.jp (守岡 知彦 / MORIOKA Tomohiko) wrote: 圭一> ;; mime-w3.el で mime-entity-buffer を使っているので FLIM 側に 圭一> ;; mime-entity-root を作って、これを使うようにしたいのです。 守岡> 個人的には、名前的は mime-find-root-entity の方が好みです。圭一 守岡> さん、いかがでしょうか? 圭一> 単に mime-entity-parent を元につけただけですので、名前に関しては、 圭一> 私も何でもいいです。 守岡> じゃあ、mime-find-root-entity で行きましょう。 などと書きましたが、やっぱり私も mime-entity- からはじまるようにしたく なってきました。(^_^;;; で、mime-entity-find-root ではいかがでしょうか? あと、FLIM 1.14 では 1.13 で obsolete にした変数 mime-message-structure および関数 mime-fetch-field, mime-read-field を 廃止しようと思います。また、これに伴い、optional 引数の既定値が mime-message-structure の値であるような関数において、その引数を必須と するようにしたいと思います。具体的には mime-find-entity-* が該当します。 で、これら message (= root-entity) に対する機能には mime-message- から はじまる名前を付けた方が良いかなとふと思ったのですがいかがでしょうか? 例えば、mime-find-entity-from-content-id (cid message) は mime-message-find-entity-by-content-id (message cid) みたいにしようと いう訳です。皆様、どう思われますか? もし、この変更を行ったとしても、FLIM 1.14 では旧名を obsolete な関数と して残します。廃止は 1.15 で行います。 ところで、chao-1_14 において buffer 系 API の obsolete 宣言を行いまし た。これらの実際の廃止は FLIM 1.15 で行いたいと思います。 ;; つまり、FLIM 1.13 にある機能は全て 1.14 に残し、そのうち obsolete ;; なものは 1.15 で廃止しようと言う訳です。 -- ===『幾千億の分子に分かれても ======================================== 決して忘れない。 この宇宙が終るまで』 守岡 知彦 (MORIOKA Tomohiko) ======================================== Email: ===== From keiichi @ nanap.org Fri Mar 3 17:46:37 2000 From: keiichi @ nanap.org (Keiichi Suzuki) Date: 03 Mar 2000 17:46:37 +0900 Subject: mime-entity-node-id in Chao-1.14.1 + Message-ID: chao-1_14 最新の mime.el で、 (defalias 'mime-entity-node-id 'mime-entity-node-id-internal) となっていますが、まずいのではないでしょうか。 (defun mime-entity-node-id (entity) (mime-entity-node-id-internal entity)) or (defalias 'mime-entity-node-id (eval-when-compile (symbol-function 'mime-entity-node-id-internal))) にすると問題がなくなるようです。 -- 鈴木圭一 / keiichi @ nanap.org PGP finger print (DH/DSS) 0B32 B37E 6DE9 3BC1 68A4 4089 7AAF 2B03 ECBD 614B From tomo @ etl.go.jp Fri Mar 3 18:00:04 2000 From: tomo @ etl.go.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko) Date: 03 Mar 2000 18:00:04 +0900 Subject: mime-entity-node-id in Chao-1.14.1 + In-Reply-To: Keiichi Suzuki's message of "03 Mar 2000 17:46:37 +0900" References: Message-ID: >>>>> In [emacs-mime-ja : No.00465] >>>>> "圭一" = Keiichi Suzuki wrote: 圭一> chao-1_14 最新の mime.el で、 圭一> (defalias 'mime-entity-node-id 'mime-entity-node-id-internal) 圭一> となっていますが、まずいのではないでしょうか。 まずいと思います。(^_^;;; 圭一> (defun mime-entity-node-id (entity) 圭一> (mime-entity-node-id-internal entity)) 圭一> or 圭一> (defalias 'mime-entity-node-id 圭一> (eval-when-compile 圭一> (symbol-function 'mime-entity-node-id-internal))) 圭一> にすると問題がなくなるようです。 前者が良いと思います。 -- ┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━ ││ ─ │ ─ / ─ ┼─ ┬ ─ ─┼ ┬┴─ ┼┼─┼|〓━─┼ 守岡 知彦 (MORIOKA Tomohiko) ─ ─┬ ┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ From yoshiki @ xemacs.org Fri Mar 3 18:57:35 2000 From: yoshiki @ xemacs.org (Yoshiki Hayashi) Date: Fri, 03 Mar 2000 18:57:35 +0900 Subject: mime-entity- and mime-message- In-Reply-To: (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko's message of "Thu, 02 Mar 2000 16:09:43 +0900") References: Message-ID: <87n1ogz88g.fsf@dp50.ecc.u-tokyo.ac.jp> tomo @ etl.go.jp (守岡 知彦 / MORIOKA Tomohiko) writes: > 圭一> 単に mime-entity-parent を元につけただけですので、名前に関しては、 > 圭一> 私も何でもいいです。 > > 守岡> じゃあ、mime-find-root-entity で行きましょう。 > > などと書きましたが、やっぱり私も mime-entity- からはじまるようにしたく > なってきました。(^_^;;; で、mime-entity-find-root ではいかがでしょうか? 別に良いと思います。反対意見も無いようなので決定してしまって 良いんじゃないでしょうか。 > で、これら message (= root-entity) に対する機能には mime-message- から > はじまる名前を付けた方が良いかなとふと思ったのですがいかがでしょうか? > 例えば、mime-find-entity-from-content-id (cid message) は > mime-message-find-entity-by-content-id (message cid) みたいにしようと > いう訳です。皆様、どう思われますか? 別に悪くは無いとは思いますが、どうしても新しいものである必要 が無い場合は変えない方が良いと思います。移行時の混乱と比較し てそんなに利点があるとは思えないのですが。 -- Yoshiki Hayashi From tomo @ etl.go.jp Wed Mar 8 19:10:54 2000 From: tomo @ etl.go.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko) Date: 08 Mar 2000 19:10:54 +0900 Subject: mime-entity- and mime-message- In-Reply-To: Yoshiki Hayashi's message of "Fri, 03 Mar 2000 18:57:35 +0900" References: <87n1ogz88g.fsf@dp50.ecc.u-tokyo.ac.jp> Message-ID: >>>>> In [emacs-mime-ja : No.00467] >>>>> "Yoshiki" = Yoshiki Hayashi wrote: 圭一>>> 単に mime-entity-parent を元につけただけですので、名前に関しては、 圭一>>> 私も何でもいいです。 守岡>>> じゃあ、mime-find-root-entity で行きましょう。 Yoshiki> > などと書きましたが、やっぱり私も mime-entity- からはじまる Yoshiki> > ようにしたくなってきました。(^_^;;; で、 Yoshiki> > mime-entity-find-root ではいかがでしょうか? Yoshiki> 別に良いと思います。反対意見も無いようなので決定してしまって Yoshiki> 良いんじゃないでしょうか。 mime-entity- は mime-message- と対になるものとして整理しようという提案 なので、下記を行わないのであればあんまり利点がなかったりします。 とはいえ、mime-entity-find-root にします。 Yoshiki> > で、これら message (= root-entity) に対する機能には Yoshiki> > mime-message- からはじまる名前を付けた方が良いかなとふと思っ Yoshiki> > たのですがいかがでしょうか?例えば、 Yoshiki> > mime-find-entity-from-content-id (cid message) は Yoshiki> > mime-message-find-entity-by-content-id (message cid) みたい Yoshiki> > にしようという訳です。皆様、どう思われますか? Yoshiki> 別に悪くは無いとは思いますが、どうしても新しいものである必要 Yoshiki> が無い場合は変えない方が良いと思います。移行時の混乱と比較し Yoshiki> てそんなに利点があるとは思えないのですが。 raw-buffer の存在を仮定しないためには、既定値が mime-message-structure である optional 引数を廃止しなければなりません。で、こうした引数を optional じゃなくする方向にした時、そのことに compiler warning をかけ ることが出来ません。また、Emacs は引数の数を調べるのは不得意なので、難 ありである訳です。 これに対し、関数を新設し、旧関数を obsolete 宣言すれば、check がしやす いかなと思った訳です。(あと、旧関数の名称が英語としておかしいような気 がするんですが(^_^;;;) あと、object は総称関数の第1引数でなければならないという luna の制限 があった気がするんですが、もしこれが真なら、第1引数にすれば総称関数と してかけてうれしいような気がします。(従来の実装は mime-entity class の method とし、mm-backend でこれを override 出来るようになる)(もっ ともそれがうれしいかは疑問かな?(^_^;;;) まあ、でも、そんなに強い希望ではないので、単に optional 引数じゃなくす るだけで良いならそれでも良いと思います。 -- ===『幾千億の分子に分かれても ======================================== 決して忘れない。 この宇宙が終るまで』 守岡 知彦 (MORIOKA Tomohiko) ======================================== Email: ===== From tomo @ etl.go.jp Wed Mar 8 19:16:53 2000 From: tomo @ etl.go.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko) Date: 08 Mar 2000 19:16:53 +0900 Subject: mime-{fetch|read}-field Message-ID: Chao 1.14 では check も兼ねていきなり廃止してみましたが、FLIM 1.14 で は、第2引数が省略された時 std11-field-body に準じた挙動をするようにし ても良いかなと思うのですがいかがでしょうか? つまり、変数 mime-message-structure を参照するのではなく、current buffer の message header を parse する訳です。 もし、この案に賛同者が出るなら、FLIM 1.14 ではこの方向で行こうと思いま す。 あと、FLIM 1.14 では header の sort/filtering についても考えたいんです が、結局、前回の議論はどうなったんでしたっけ?仕様の案についてまた議論 をして頂けると幸いです。 -- ===『幾千億の分子に分かれても ======================================== 決して忘れない。 この宇宙が終るまで』 守岡 知彦 (MORIOKA Tomohiko) ======================================== Email: ===== From nakaji @ tutrp.tut.ac.jp Thu Mar 9 12:48:23 2000 From: nakaji @ tutrp.tut.ac.jp (NAKAJI Hiroyuki) Date: 09 Mar 2000 12:48:23 +0900 Subject: What is a recommended combination of APEL, FLIM and SEMI? Message-ID: <87ya7s7qig.fsf@nakaji.tutrp.tut.ac.jp> 中治@豊橋です。 今は、User-Agent のような組合わせで使っていますが、APEL, FLIM, SEMI, Semi-gnus の組合わせは、千差万別とまでは行かないにしても、たくさんあっ て悩ましいように思います。さて、 どういう組合わせがオススメなのでしょうか? とりあえず、T-gnus または Nana-gnus ?何それ?という人、存在を知ってい てそのリリース版が使えればいいやという人から、CVS でいろんなバージョン を取り出して、遊んでしまう人までユーザー層は幅広いですよね。 ぶっちゃけた話、「遊んでしまう人」に近い私は、remi-1_14 でいいのかなぁ と悩んでしまっているのですが。(^_^;; -- NAKAJI Hiroyuki (中治 弘行) From yamaoka @ jpl.org Thu Mar 9 13:02:11 2000 From: yamaoka @ jpl.org (Katsumi Yamaoka) Date: 08 Mar 2000 23:02:11 -0500 (EST) Subject: What is a recommended combination of APEL, FLIM and SEMI? References: <87ya7s7qig.fsf@nakaji.tutrp.tut.ac.jp> Message-ID: >>>>> In [semi-gnus-ja : No.5002] >>>>> NAKAJI Hiroyuki wrote: 中治さん> 今は、User-Agent のような組合わせで使っていますが、APEL, 中治さん> FLIM, SEMI, Semi-gnus の組合わせは、千差万別とまでは行かない 中治さん> にしても、たくさんあって悩ましいように思います。さて、 中治さん> どういう組合わせがオススメなのでしょうか? あまり elips で遊ぶ気が無い方に Nana-gnus 7 や T-gnus の先端を勧めると したら、APEL, FLIM, SEMI は release 版の最新になるのでしょう。それぞれ どれかのファイルに書いてありますよね。一応 T-gnus 6.14 については APEL 9.20 以上 FLIM 1.13.1 以上 SEMI/WEMI 1.13.5 以上 ってことになっています。 ;; が、最近はぜんぜん試していないので自信がありません。(^^;;) ;; 問題が起きたときの対処の楽さから言うと、jpl.org などにある最先端品 ;; を揃えるのがお勧め...とも言えないか...。(^^;;) -- Katsumi Yamaoka From nakaji @ tutrp.tut.ac.jp Thu Mar 9 13:50:14 2000 From: nakaji @ tutrp.tut.ac.jp (NAKAJI Hiroyuki) Date: 09 Mar 2000 13:50:14 +0900 Subject: What is a recommended combination of APEL, FLIM and SEMI? In-Reply-To: (Katsumi Yamaoka's message of "08 Mar 2000 23:02:11 -0500 (EST)") References: <87ya7s7qig.fsf@nakaji.tutrp.tut.ac.jp> Message-ID: <87ya7sn3w9.fsf@nakaji.tutrp.tut.ac.jp> >>>>> In [semi-gnus-ja : No.5004] >>>>> Katsumi Yamaoka wrote: 中治> どういう組合わせがオススメなのでしょうか? 山岡さん> あまり elips で遊ぶ気が無い方に Nana-gnus 7 や T-gnus の先端 山岡さん> を勧めるとしたら、APEL, FLIM, SEMI は release 版の最新になる 山岡さん> のでしょう。 やはり、そうですか。随分長い間、リリース版というものを使った記憶があり ません。(^^;; では、あまりelisp で遊ぶ気はないのだが、新しいものには目がなくて、つい 飛び付いてしまう私のような人には、どういう組合わせがオススメですか? -- NAKAJI Hiroyuki (中治 弘行) From ari @ atesoft.advantest.co.jp Mon Mar 13 12:20:04 2000 From: ari @ atesoft.advantest.co.jp (Akihiro Arisawa) Date: 13 Mar 2000 12:20:04 +0900 Subject: [emy] mime-display-gzipped Message-ID: <7tek8j7k13v.fsf@atesoft.advantest.co.jp> 有沢です。 FSF Emacs では `buffer-string' は引数を取れないため、 EMY の `mime-display-gzipped' がエラーとなります。 -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: 無し 型: application/octet-stream[base64 サイズ: 6894 バイト 説明: 無し URL: -------------- next part -------------- -- 有沢 明宏 From yoshiki @ xemacs.org Wed Mar 15 04:32:34 2000 From: yoshiki @ xemacs.org (Yoshiki Hayashi) Date: Wed, 15 Mar 2000 04:32:34 +0900 Subject: [emy] mime-display-gzipped In-Reply-To: <7tek8j7k13v.fsf@atesoft.advantest.co.jp> (Akihiro Arisawa's message of "Mon, 13 Mar 2000 12:20:04 +0900") References: <7tek8j7k13v.fsf@atesoft.advantest.co.jp> Message-ID: <87ln3l2vql.fsf@dp50.ecc.u-tokyo.ac.jp> ari @ atesoft.advantest.co.jp (Akihiro Arisawa) writes: > FSF Emacs では `buffer-string' は引数を取れないため、 > EMY の `mime-display-gzipped' がエラーとなります。 おそらく、(buffer-string) か、 (buffer-substring (point-min) (point-max)) と書こうとして間違えたようです。前者を使って修正しました。 ついでに、coding system の自動判別もするようにしたものを commit しました。 -- Yoshiki Hayashi From ari @ atesoft.advantest.co.jp Wed Mar 15 10:39:54 2000 From: ari @ atesoft.advantest.co.jp (Akihiro Arisawa) Date: 15 Mar 2000 10:39:54 +0900 Subject: [emy] mime-display-gzipped In-Reply-To: <87ln3l2vql.fsf@dp50.ecc.u-tokyo.ac.jp> (Yoshiki Hayashi's message of "Wed, 15 Mar 2000 04:32:34 +0900") References: <7tek8j7k13v.fsf@atesoft.advantest.co.jp> <87ln3l2vql.fsf@dp50.ecc.u-tokyo.ac.jp> Message-ID: <7teya7l6mfp.fsf@atesoft.advantest.co.jp> 有沢です。 yoshiki @ xemacs.org (Yoshiki Hayashi) writes: > おそらく、(buffer-string) か、 > (buffer-substring (point-min) (point-max)) > と書こうとして間違えたようです。前者を使って修正しました。 T-gnus では問題無く gzipped な添付ファイルをインライン表示 できるようになりました:-) が、なぜか Wanderlust では |gzip: stdin: invalid compressed data--format violated と言われてしまいます。 multibyte-string になっているようだったので、以下のように してみたら問題無かったのですが、もしかしたら Wanderlust 側で 対処するべきことなのかもしれません。 -------------- next part -------------- Index: mime-view.el =================================================================== RCS file: /cvs/root/semi/mime-view.el,v retrieving revision 1.149.2.20.4.14 diff -u -r1.149.2.20.4.14 mime-view.el --- mime-view.el 2000/03/14 10:32:43 1.149.2.20.4.14 +++ mime-view.el 2000/03/15 01:22:57 @@ -852,6 +852,7 @@ "Ungzip gzipped part and display." (insert (with-temp-buffer + (set-buffer-multibyte nil) (insert (mime-entity-content entity)) (as-binary-process (call-process-region (point-min) (point-max) "gzip" t t -------------- next part -------------- > ついでに、coding system の自動判別もするようにしたものを > commit しました。 ;; コード変換されないみたいなんですが。 -- 有沢 明宏 From kose @ wizard.tamra.co.jp Wed Mar 15 13:15:40 2000 From: kose @ wizard.tamra.co.jp (=?iso-2022-jp?b?GyRCPi40WBsoQiAbJEI1SEInGyhC?= (KOSEKI Yoshinori)) Date: 15 Mar 2000 13:15:40 +0900 Subject: What is a recommended combination of APEL, FLIM and SEMI? In-Reply-To: NAKAJI Hiroyuki's message of "09 Mar 2000 13:50:14 +0900" References: <87ya7s7qig.fsf@nakaji.tutrp.tut.ac.jp> <87ya7sn3w9.fsf@nakaji.tutrp.tut.ac.jp> Message-ID: <2000Mar15r9dckgwj.kose@wizard.tamra.co.jp> ちゃちゃ、かなぁ。半分以上真面目。 >>>>> In [emacs-mime-ja : No.00472] >>>>> “中治” = NAKAJI Hiroyuki さん 中治> では、あまりelisp で遊ぶ気はないのだが、新しいものには目がなくて、つい 中治> 飛び付いてしまう私のような人には、どういう組合わせがオススメですか? 「誰についていくか(師匠とも言う:-)決めましょう。」 で、その人の User-Agent を追っかけるってのはどぉ??? 少なくともその組合せでは問題なく動きますよね。:-) -- こせき @ Windows9x/NT で XEmacs をコンパイルしよう! http://www.NetLaputa.ne.jp/~kose/Software/compile/ kose @ yk.NetLaputa.ne.jp From nakaji @ tutrp.tut.ac.jp Wed Mar 15 13:22:26 2000 From: nakaji @ tutrp.tut.ac.jp (NAKAJI Hiroyuki) Date: 15 Mar 2000 13:22:26 +0900 Subject: What is a recommended combination of APEL, FLIM and SEMI? In-Reply-To: <2000Mar15r9dckgwj.kose@wizard.tamra.co.jp> (=?ISO-2022-JP?B?GyRCPi40WBsoQiAbJEI1SEInGyhC?= (KOSEKI Yoshinori)'s message of "15 Mar 2000 13:15:40 +0900") References: <87ya7s7qig.fsf@nakaji.tutrp.tut.ac.jp> <87ya7sn3w9.fsf@nakaji.tutrp.tut.ac.jp> <2000Mar15r9dckgwj.kose@wizard.tamra.co.jp> Message-ID: <87aek06ewt.fsf@nakaji.tutrp.tut.ac.jp> >>>>> In [semi-gnus-ja : No.5053] >>>>> 小関 吉則 (KOSEKI Yoshinori) wrote: 小関さん> ちゃちゃ、かなぁ。半分以上真面目。 そうですね。よく考えれば、こういうのは愚問です。 中治> では、あまりelisp で遊ぶ気はないのだが、新しいものには目がなくて、 中治> つい飛び付いてしまう私のような人には、どういう組合わせがオススメ 中治> ですか? 小関さん> 「誰についていくか(師匠とも言う:-)決めましょう。」 小関さん> で、その人の User-Agent を追っかけるってのはどぉ??? いただきます。 小関さん> 少なくともその組合せでは問題なく動きますよね。:-) ソニーにお勤めのさるお方をこっそり師匠としていますが、メールをなくして しまうこともあるようなので、3歩下がって、影を踏まないようにしようと思 います。:-) 今後ともよろしうに。m(__)m -- NAKAJI Hiroyuki (中治 弘行) From yoshiki @ xemacs.org Thu Mar 16 10:08:41 2000 From: yoshiki @ xemacs.org (Yoshiki Hayashi) Date: Thu, 16 Mar 2000 10:08:41 +0900 Subject: [emy] mime-display-gzipped In-Reply-To: <7teya7l6mfp.fsf@atesoft.advantest.co.jp> (Akihiro Arisawa's message of "Wed, 15 Mar 2000 10:39:54 +0900") References: <7tek8j7k13v.fsf@atesoft.advantest.co.jp> <87ln3l2vql.fsf@dp50.ecc.u-tokyo.ac.jp> <7teya7l6mfp.fsf@atesoft.advantest.co.jp> Message-ID: <87wvn3202u.fsf@buck.sodan.org> ari @ atesoft.advantest.co.jp (Akihiro Arisawa) writes: > T-gnus では問題無く gzipped な添付ファイルをインライン表示 > できるようになりました:-) > > が、なぜか Wanderlust では > |gzip: stdin: invalid compressed data--format violated > と言われてしまいます。 > multibyte-string になっているようだったので、以下のように > してみたら問題無かったのですが、もしかしたら Wanderlust 側で > 対処するべきことなのかもしれません。 (mime-entity-content) の値は Wanderlust でも T-gnus でも同じ ように見えるのに、Wanderlust のときだけ temporary buffer に insert するときに binary が文字に化けているようです。 FSF Emacs の unibyte, multibyte 部分は考えたくもないので、原 因を探すのはあきらめて、ありさわさんの patch のようにして対 処しました。 # temp buffer 毎にこういうことをしなきゃいけないなんて悪夢と # しか思えない。RMS のばかぁ。;-) > > ついでに、coding system の自動判別もするようにしたものを > > commit しました。 > > ;; コード変換されないみたいなんですが。 file に書くのを忘れていました。今回は大丈夫だと思います。 (^^;; -- Yoshiki Hayashi From yamaoka @ jpl.org Thu Mar 16 10:30:54 2000 From: yamaoka @ jpl.org (Katsumi Yamaoka) Date: 15 Mar 2000 20:30:54 -0500 (EST) Subject: [emy] mime-display-gzipped References: <7tek8j7k13v.fsf@atesoft.advantest.co.jp> <87ln3l2vql.fsf@dp50.ecc.u-tokyo.ac.jp> <7teya7l6mfp.fsf@atesoft.advantest.co.jp> <87wvn3202u.fsf@buck.sodan.org> Message-ID: >>>>> In [emacs-mime-ja : No.00478] >>>>> Yoshiki Hayashi wrote: 林さん> FSF Emacs の unibyte, multibyte 部分は考えたくもないので、原 林さん> 因を探すのはあきらめて、ありさわさんの patch のようにして対 林さん> 処しました。 林さん> # temp buffer 毎にこういうことをしなきゃいけないなんて悪夢と 林さん> # しか思えない。RMS のばかぁ。;-) 余談ですが、enable-multibyte-characters の値を一時的にトグルしてちょっ とした処理を行なう場合に、current-buffer の内容物は処理対象ではないの に (let ((flag enable-multibyte-characters)) (unwind-protect (progn (set-buffer-multibyte nil) (あれや) (これや)) (set-buffer-multibyte flag))) てなことを行なうと、もう大変。 current-buffer の内容物を全部 unibyte に変換して再び multibyte に戻す 作業が行なわれてしまいます。:-< ;; それで作ったのが `vm-with-(unibyte|multibyte)-buffer'。 -- Katsumi Yamaoka From ari @ atesoft.advantest.co.jp Thu Mar 16 13:01:41 2000 From: ari @ atesoft.advantest.co.jp (Akihiro Arisawa) Date: 16 Mar 2000 13:01:41 +0900 Subject: [emy] mime-display-gzipped In-Reply-To: <87wvn3202u.fsf@buck.sodan.org> (Yoshiki Hayashi's message of "Thu, 16 Mar 2000 10:08:41 +0900") References: <7tek8j7k13v.fsf@atesoft.advantest.co.jp> <87ln3l2vql.fsf@dp50.ecc.u-tokyo.ac.jp> <7teya7l6mfp.fsf@atesoft.advantest.co.jp> <87wvn3202u.fsf@buck.sodan.org> Message-ID: <7teem9b4l7e.fsf@atesoft.advantest.co.jp> 有沢です。 yoshiki @ xemacs.org (Yoshiki Hayashi) writes: > > が、なぜか Wanderlust では > > |gzip: stdin: invalid compressed data--format violated > > と言われてしまいます。 > FSF Emacs の unibyte, multibyte 部分は考えたくもないので、原 > 因を探すのはあきらめて、ありさわさんの patch のようにして対 > 処しました。 すみません、今度はなぜか T-gnus の方で "invalid compressed data" と言われるようになってしまいました(;_;) > # temp buffer 毎にこういうことをしなきゃいけないなんて悪夢と > # しか思えない。RMS のばかぁ。;-) ;; EMY が FSF Emacs をサポート外にしてしまう日が近い気が(^^;;; -- 有沢 明宏 From okazaki @ be.to Thu Mar 16 16:56:01 2000 From: okazaki @ be.to (OKAZAKI Tetsurou) Date: Thu, 16 Mar 2000 16:56:01 +0900 Subject: mime-preview-toggle-{header,content} for a default invisible part. Message-ID: <86zorzcpri.wl@dolphin.be.to> 岡崎です。 User-Agent な環境(ChaoはCVSの現時点での最新版です)で、 Content-Type: multipart/mixed な message を表示させていて、 mime-preview-toggle-{header,content} で MIME header や MIME content の表示を切り替える時に気になることがあります。 MIME-View に最初から表示されている part では、C-c C-t C-f や C-c C-t C-c をそれぞれ一度だけ使えば header や content を非表示にできるのですが、 始めから非表示になっている part では、C-c C-t C-f や C-c C-t C-c を 二度実行しないと、表示されません。実際に M-x list-text-properties-at でこの part の text property: mime-view-situation の値を確認してみると、 最初の非表示状態では、 mime-view-situation ((major-mode . mmelmo-original-mode)) … (1) になっています。ここで C-c C-t C-c を一回実行すると、part の内容は 非表示のままで、 mime-view-situation ((*body . invisible) (major-mode . mmelmo-original-mode)) … (2) と変化します。この後、C-c C-t C-c をさらにもう一回実行すると、 part の内容が表示されて、 mime-view-situation ((*body . visible) (major-mode . mmelmo-original-mode)) … (3) と変わります。これ以降は (2)⇔(3) の間を行き来します。 mime-preview-toggle-display の現在の実装では、(1) の様に mime-view-situation に該当する property が存在しない場合、 (現在の状態が) visible だとみなして (2) に遷移させています。 これがこの関数の仕様だとすると、body/header の visible/invisible の初期状態を mime-view-situation にあらかじめ設定しておく方が いいのかな、と思います。 ;; が、どこを触るべきか判らなかったので、報告だけ… m(_ _)m -- 岡崎哲朗 From okada @ opaopa.org Thu Mar 16 17:13:30 2000 From: okada @ opaopa.org (=?ISO-2022-JP?B?GyRCMixFRBsoQiAbJEI3cjBsGyhC?= / Kenichi OKADA) Date: Thu, 16 Mar 2000 17:13:30 +0900 Subject: =?ISO-2022-JP?B?GyRCJWolVyVpJSQkRyUoJWkhPBsoQg==?= In-Reply-To: In your message of "Wed, 15 Mar 2000 12:30:44 +0900" References: Message-ID: おかだです。 In the message "リプライでエラー" Toshihiko Kodama (小玉 利彦) wrote: > 特定のメッセージに A で返事を書こうとするとエラーになってしまいます。 > どの様な時に起こるのか判らないのですが… > #とりあえずバックトレースを添付します。 > Signaling: (wrong-type-argument integer-or-marker-p nil) > get-text-property(nil mime-view-entity) > mime-preview-entity-boundary() > mime-preview-follow-current-entity() > (save-restriction (set-buffer (wl-current-message-buffer)) (widen) (mime-preview-follow-current-entity)) > (save-excursion (save-restriction (set-buffer ...) (widen) (mime-preview-follow-current-entity))) > (if (get-buffer (wl-current-message-buffer)) (save-excursion (save-restriction ... ... ...))) > (let ((wl-draft-buffer ...) (mime-view-following-method-alist ...) (mime-preview-following-method-alist ...)) (if (get-buffer ...) (save-excursion ...))) > wl-draft-yank-current-message-entity() EMY 固有の問題だと思いますが、 わたしのところでは、再現できません. なんで、point が nil になっているんでしょうね? | (or point | (setq point (point))) | (and (eq point (point-max)) | (setq point (1- (point-max)))) | (let ((entity (get-text-property point 'mime-view-entity)) M-x debug-on-entry mime-preview-entity-boundary してみて、 point がどこで、nil になっているかわかりますか? -- 岡田 健一 URLs: mailto:okada @ opaopa.org http://www.opaopa.org From kodama @ ayame.mfd.cs.fujitsu.co.jp Thu Mar 16 17:27:46 2000 From: kodama @ ayame.mfd.cs.fujitsu.co.jp (Toshihiko Kodama (=?ISO-2022-JP?B?GyRCPi42TBsoQiAbJEJNeEknGyhC?=)) Date: Thu, 16 Mar 2000 17:27:46 +0900 Subject: =?ISO-2022-JP?B?GyRCJWolVyVpJSQkRyUoJWkhPBsoQg==?= In-Reply-To: In your message of "Thu, 16 Mar 2000 17:13:33 +0900" References: Message-ID: 小玉です。 >>>>> In [Wanderlust : No.04439] >>>>> okada @ opaopa.org (岡田 健一 / Kenichi OKADA) wrote: 岡田> M-x debug-on-entry mime-preview-entity-boundary 岡田> してみて、 point がどこで、nil になっているかわかりますか? 以下のようになりました -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: Backtrace 型: application/octet-stream サイズ: 1375 バイト 説明: 無し URL: -------------- next part -------------- -- 富士通(株) コンピュータ事業本部 三コンピ)第三開発部 小玉 利彦 (Kodama Toshihiko) kodama @ ayame.mfd.cs.fujitsu.co.jp TEL:044-754-3245 / ext:7113-4943 #2000年問題とは2000年が20世紀か21世紀かという問題である XD From tomo @ etl.go.jp Thu Mar 16 17:34:03 2000 From: tomo @ etl.go.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko) Date: 16 Mar 2000 17:34:03 +0900 Subject: mime-preview-toggle-{header,content} for a default invisible part. In-Reply-To: OKAZAKI Tetsurou's message of "Thu, 16 Mar 2000 16:56:01 +0900" References: <86zorzcpri.wl@dolphin.be.to> Message-ID: >>>>> In [emacs-mime-ja : No.00481] >>>>> "岡崎" = OKAZAKI Tetsurou wrote: 岡崎> User-Agent な環境(ChaoはCVSの現時点での最新版です)で、 岡崎> Content-Type: multipart/mixed な message を表示させていて、 岡崎> mime-preview-toggle-{header,content} で MIME header やMIME 岡崎> content の表示を切り替える時に気になることがあります。 岡崎> MIME-View に最初から表示されている part では、C-c C-t C-f や C-c 岡崎> C-t C-cをそれぞれ一度だけ使えば header や content を非表示にでき 岡崎> るのですが、始めから非表示になっている part では、C-c C-t C-f や 岡崎> C-c C-t C-c を二度実行しないと、表示されません。実際に M-x 岡崎> list-text-properties-atでこの part の text property: 岡崎> mime-view-situation の値を確認してみると、最初の非表示状態では、 岡崎> mime-view-situation ((major-mode . mmelmo-original-mode)) … (1) 岡崎> になっています。ここで C-c C-t C-c を一回実行すると、part の内容 岡崎> は非表示のままで、 岡崎> mime-view-situation ((*body . invisible) (major-mode . mmelmo-original-mode)) 岡崎> … (2) 岡崎> と変化します。この後、C-c C-t C-c をさらにもう一回実行すると、 岡崎> part の内容が表示されて、 岡崎> mime-view-situation ((*body . visible) (major-mode . mmelmo-original-mode)) 岡崎> … (3) 岡崎> と変わります。これ以降は (2)⇔(3) の間を行き来します。 岡崎> mime-preview-toggle-display の現在の実装では、(1) の様に 岡崎> mime-view-situation に該当する property が存在しない場合、 岡崎> (現在の状態が) visible だとみなして (2) に遷移させています。 岡崎> これがこの関数の仕様だとすると、body/header の visible/invisible 岡崎> の初期状態を mime-view-situation にあらかじめ設定しておく方が 岡崎> いいのかな、と思います。 御報告ありがとうございます。 つまり、header と body に関する default value の扱いが mime-display-entity と mime-preview-toggle-display で不一致になってい る訳ですね。(^_^;;; button, header, body で mime-preview-toggle-display を共有したい気がするので、 header と body の default value を button に合わせるか、岡崎さんがおっ しゃっているように default value を生じないようにすれば良いんでしょう ね。 岡崎さんの案で行く場合、mime-display-entity を (let ((button-is-invisible (eq (cdr (or (assq '*entity-button situation) (assq 'entity-button situation))) 'invisible)) (header-is-visible (if (eq (cdr (or (assq '*header situation) (assq 'header situation))) 'visible) t (setq situation (put-alist '*header 'invisible situation)))) (body-is-visible (if (eq (cdr (or (assq '*body situation) (assq 'body situation))) 'visible) t (setq situation (put-alist '*body 'invisible situation)))) (children (mime-entity-children entity))) みたいに修正すれば良いでしょうか?(未確認です) あと、なんとなく、header と body も default では visible とする方が良 いような気もするので、この方向も試したいと思います。 -- ===『幾千億の分子に分かれても ======================================== 決して忘れない。 この宇宙が終るまで』 守岡 知彦 (MORIOKA Tomohiko) ======================================== Email: ===== From ari @ atesoft.advantest.co.jp Thu Mar 16 17:53:51 2000 From: ari @ atesoft.advantest.co.jp (Akihiro Arisawa) Date: 16 Mar 2000 17:53:51 +0900 Subject: [emy] mime-display-gzipped In-Reply-To: <7teem9b4l7e.fsf@atesoft.advantest.co.jp> (Akihiro Arisawa's message of "16 Mar 2000 13:01:41 +0900") References: <7tek8j7k13v.fsf@atesoft.advantest.co.jp> <87ln3l2vql.fsf@dp50.ecc.u-tokyo.ac.jp> <7teya7l6mfp.fsf@atesoft.advantest.co.jp> <87wvn3202u.fsf@buck.sodan.org> <7teem9b4l7e.fsf@atesoft.advantest.co.jp> Message-ID: <7te4sa747og.fsf@atesoft.advantest.co.jp> 有沢です。 ari @ atesoft.advantest.co.jp (Akihiro Arisawa) writes: > > > が、なぜか Wanderlust では > > > |gzip: stdin: invalid compressed data--format violated > > > と言われてしまいます。 > すみません、今度はなぜか T-gnus の方で "invalid compressed data" > と言われるようになってしまいました(;_;) いくつかの MUA で確認してみたところ、以下のようになりました。 ● (set-buffer-multibyte nil) としなければならない Wanderlust (2.2.12) SEMI-VM (6.75-19991026-1) EMH (1.10.1) CMAIL (2.60+20000216) ● (set-buffer-multibyte nil) としてはいけない T-gnus (6.14.1 r12) RMAIL-MIME (1.13.0) mime-edit-preview-message ;; 私には原因がサッパリ分からないです。 -- 有沢 明宏 From nakaji @ tutrp.tut.ac.jp Thu Mar 16 20:06:57 2000 From: nakaji @ tutrp.tut.ac.jp (NAKAJI Hiroyuki) Date: 16 Mar 2000 20:06:57 +0900 Subject: mime-w3 error [Re: =?ISO-2022-JP?B?bmV3cxskQiU1ITwlUCQsTGQbKEI=?= =?ISO-2022-JP?B?GyRCQmokSiROJCshIiVqITwlQCROTGRCahsoQl0=?= In-Reply-To: (Keiichi Suzuki's message of "16 Mar 2000 19:31:07 +0900") References: Message-ID: <86r9db2my6.fsf_-_@xa12.heimat.gr.jp> 中治@豊橋です。fj.news.reader からです。 >>>>> In >>>>> Keiichi Suzuki wrote: KS> 森さんは W3 をインストールしていませんよね? W3 をインストールすると、 KS> SEMI がそれを使って表示するようになります。 KS> これは、 Gnus 5.8 系列ではさらに強力(?)で、 W3 がインストールされている KS> 状態でこの手のメッセージを読むと、ヘッダを見ない限り multipart であるこ KS> とすら分かりません。 w3-version's value is "WWW xp 1999/12/05" というのをインストールしているのですが、User-Agent の環境で、HTML パー トの付いたメールを表示しようとすると、 -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: Backtrace 型: application/octet-stream サイズ: 17095 バイト 説明: 無し URL: -------------- next part -------------- というエラーになりました。普段は、 (setq mime-setup-enable-inline-html nil) (require 'mime-setup) として、「モダン」な使い方をしていませんが、久しぶりにモダンな使い方を してみるかと思ったところができませんでした。今は、また「プレモダン」で す。 Signaling: (void-function url-register-protocol) とのことですが、 semi/mime-w3.el の終りの方、 (url-register-protocol "cid" 'url-cid 'url-identity-expander) だと思います。 -- NAKAJI Hiroyuki (中治 弘行) From okazaki @ be.to Fri Mar 17 07:06:33 2000 From: okazaki @ be.to (OKAZAKI Tetsurou) Date: Fri, 17 Mar 2000 07:06:33 +0900 Subject: mime-preview-toggle-{header,content} for a default invisible part. In-Reply-To: In your message of "16 Mar 2000 17:34:03 +0900" References: <86zorzcpri.wl@dolphin.be.to> Message-ID: <86itymvac6.wl@dolphin.be.to> 岡崎です。wl @ lists.airs.net は外しました。 In the ML [emacs-mime-ja 00484] tomo @ etl.go.jp (守岡 知彦 / MORIOKA Tomohiko) wrote: 守岡> >>>>> In [emacs-mime-ja : No.00481] 守岡> >>>>> "岡崎" = OKAZAKI Tetsurou wrote: 岡崎> mime-view-situation ((major-mode . mmelmo-original-mode)) … (1) 岡崎> mime-view-situation ((*body . invisible) (major-mode . mmelmo-original-mode)) 岡崎> … (2) 岡崎> mime-preview-toggle-display の現在の実装では、(1) の様に 岡崎> mime-view-situation に該当する property が存在しない場合、 岡崎> (現在の状態が) visible だとみなして (2) に遷移させています。 岡崎> これがこの関数の仕様だとすると、body/header の visible/invisible 岡崎> の初期状態を mime-view-situation にあらかじめ設定しておく方が 岡崎> いいのかな、と思います。 守岡> つまり、header と body に関する default value の扱いが 守岡> mime-display-entity と mime-preview-toggle-display で不一致になってい 守岡> る訳ですね。(^_^;;; button, header, body で どんな状況なのかがわかりました。;; なんとなく… 守岡> mime-preview-toggle-display を共有したい気がするので、 守岡> header と body の default value を button に合わせるか、岡崎さんがおっ これは、mime-display-entity の側でも (1) の時に header/body を visible とみなして表示する、という理解でよいでしょうか。 守岡> しゃっているように default value を生じないようにすれば良いんでしょう 守岡> ね。 守岡> 岡崎さんの案で行く場合、mime-display-entity を ... 守岡> みたいに修正すれば良いでしょうか?(未確認です) 試しに関数定義を置き換えてみたら、header も body も invisible に 出来なくなってあせった(^_^;のですが、 (let ((button-is-invisible (eq (cdr (or (assq '*entity-button situation) (assq 'entity-button situation))) 'invisible)) (header-is-visible (if (eq (cdr (or (assq '*header situation) (assq 'header situation))) 'visible) t (setq situation (put-alist '*header 'invisible situation)) nil)) (body-is-visible (if (eq (cdr (or (assq '*body situation) (assq 'body situation))) 'visible) t (setq situation (put-alist '*body 'invisible situation)) nil)) でよかった様です。しばらくこれで使ってみます。 守岡> あと、なんとなく、header と body も default では visible とする方が良 守岡> いような気もするので、この方向も試したいと思います。 -- 岡崎哲朗 From teranisi @ gohome.org Fri Mar 17 15:18:16 2000 From: teranisi @ gohome.org (Yuuichi Teranishi) Date: Fri, 17 Mar 2000 15:18:16 +0900 Subject: [emy] mime-display-gzipped In-Reply-To: In your message of "16 Mar 2000 17:53:51 +0900" <7te4sa747og.fsf@atesoft.advantest.co.jp> References: <7tek8j7k13v.fsf@atesoft.advantest.co.jp> <87ln3l2vql.fsf@dp50.ecc.u-tokyo.ac.jp> <7teya7l6mfp.fsf@atesoft.advantest.co.jp> <87wvn3202u.fsf@buck.sodan.org> <7teem9b4l7e.fsf@atesoft.advantest.co.jp> <7te4sa747og.fsf@atesoft.advantest.co.jp> Message-ID: At 16 Mar 2000 17:53:51 +0900, Akihiro Arisawa wrote: > > いくつかの MUA で確認してみたところ、以下のようになりました。 > > ● (set-buffer-multibyte nil) としなければならない > Wanderlust (2.2.12) > SEMI-VM (6.75-19991026-1) > EMH (1.10.1) > CMAIL (2.60+20000216) > ● (set-buffer-multibyte nil) としてはいけない > T-gnus (6.14.1 r12) > RMAIL-MIME (1.13.0) > mime-edit-preview-message > もしかして、Wanderlust 側で以下のようにすると EMY はもとのままでも大丈夫ではないでしょうか? -------------- next part -------------- --- mmelmo-2.el 2000/03/07 09:13:25 1.1.1.1.2.8 +++ mmelmo-2.el 2000/03/17 06:08:46 @@ -129,6 +129,13 @@ mime-elmo-entity)) (luna-call-next-method) (run-hooks 'mmelmo-entity-content-inserted-hook)) + +(luna-define-method mime-entity-content ((entity mime-elmo-entity)) + (mime-decode-string + (with-current-buffer (mime-buffer-entity-buffer-internal entity) + (buffer-substring (mime-buffer-entity-body-start-internal entity) + (mime-buffer-entity-body-end-internal entity))) + (mime-entity-encoding entity))) (provide 'mmelmo-2) -------------- next part -------------- -- Yuuichi Teranishi (寺西裕一) PGP 5.0i Public Key: http://www.gohome.org/pgp5/teranisi.key "The love you take is equal to the love you make..." From tomo @ etl.go.jp Fri Mar 17 17:21:27 2000 From: tomo @ etl.go.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko) Date: 17 Mar 2000 17:21:27 +0900 Subject: mime-preview-toggle-{header,content} for a default invisible part. In-Reply-To: OKAZAKI Tetsurou's message of "Fri, 17 Mar 2000 07:06:33 +0900" References: <86zorzcpri.wl@dolphin.be.to> <86itymvac6.wl@dolphin.be.to> Message-ID: >>>>> In [emacs-mime-ja : No.00487] >>>>> "岡崎" = OKAZAKI Tetsurou wrote: 岡崎> mime-view-situation ((major-mode . mmelmo-original-mode)) … (1) (略) 守岡> mime-preview-toggle-display を共有したい気がするので、header と 守岡> body の default value を button に合わせるか、岡崎さんがおっ 岡崎> これは、mime-display-entity の側でも (1) の時に header/body を 岡崎> visible とみなして表示する、という理解でよいでしょうか。 そのつもりです。default は表示で、抑制側を明示する方が、非 MIME message に対して連続的?かなと思ったりした訳ですが気のせいかも知れませ ん。(^_^;;; こうしたとしても、岡崎さんの御提案のように、明示する方が良い気がします。 守岡> しゃっているように default value を生じないようにすれば良いんで 守岡> しょうね。 守岡> 岡崎さんの案で行く場合、mime-display-entity を 岡崎> ... 守岡> みたいに修正すれば良いでしょうか?(未確認です) 岡崎> 試しに関数定義を置き換えてみたら、header も body も invisible に 岡崎> 出来なくなってあせった(^_^;のですが、 岡崎> (let ((button-is-invisible 岡崎> (eq (cdr (or (assq '*entity-button situation) 岡崎> (assq 'entity-button situation))) 岡崎> 'invisible)) 岡崎> (header-is-visible 岡崎> (if (eq (cdr (or (assq '*header situation) 岡崎> (assq 'header situation))) 岡崎> 'visible) 岡崎> t 岡崎> (setq situation (put-alist '*header 'invisible situation)) 岡崎> nil)) 岡崎> (body-is-visible 岡崎> (if (eq (cdr (or (assq '*body situation) 岡崎> (assq 'body situation))) 岡崎> 'visible) 岡崎> t 岡崎> (setq situation (put-alist '*body 'invisible situation)) 岡崎> nil)) 岡崎> でよかった様です。しばらくこれで使ってみます。 (このつもりでした。すみません(^_^;;;) とりあえず、上記修正を commit することにします。 -- === ……つまり ======================================================= ====== 隠されているかもしれない可能性にかけてみようということです ==== 守岡 知彦 (MORIOKA Tomohiko) Email: From ari @ atesoft.advantest.co.jp Fri Mar 17 19:23:01 2000 From: ari @ atesoft.advantest.co.jp (ari @ atesoft.advantest.co.jp) Date: Fri, 17 Mar 2000 19:23:01 +0900 Subject: [emy] mime-display-gzipped In-Reply-To: In your message of "Fri, 17 Mar 2000 15:18:16 +0900" References: <7tek8j7k13v.fsf@atesoft.advantest.co.jp> <87ln3l2vql.fsf@dp50.ecc.u-tokyo.ac.jp> <7teya7l6mfp.fsf@atesoft.advantest.co.jp> <87wvn3202u.fsf@buck.sodan.org> <7teem9b4l7e.fsf@atesoft.advantest.co.jp> <7te4sa747og.fsf@atesoft.advantest.co.jp> Message-ID: <7teu2i5j3p6.wl@puyo.atesoft.advantest.co.jp> At Fri, 17 Mar 2000 15:18:16 +0900, teranisi @ gohome.org (Yuuichi Teranishi) wrote: > もしかして、Wanderlust 側で以下のようにすると > EMY はもとのままでも大丈夫ではないでしょうか? 添付の patch を当ててみたところ、`mime-display-gzipped' にて (set-buffer-multibyte nil) を評価してもしなくても、 問題無く表示できました。 ということで、mmbuffer.el の `mime-entity-content' を同様に してみたところ、前述の全てのMUA で問題無く表示できました:-) -- 有沢 明宏 From yoshiki @ xemacs.org Sat Mar 18 10:35:24 2000 From: yoshiki @ xemacs.org (Yoshiki Hayashi) Date: Sat, 18 Mar 2000 10:35:24 +0900 Subject: [emy] mime-display-gzipped In-Reply-To: <7teu2i5j3p6.wl@puyo.atesoft.advantest.co.jp> (ari@atesoft.advantest.co.jp's message of "Fri, 17 Mar 2000 19:23:01 +0900") References: <7tek8j7k13v.fsf@atesoft.advantest.co.jp> <87ln3l2vql.fsf@dp50.ecc.u-tokyo.ac.jp> <7teya7l6mfp.fsf@atesoft.advantest.co.jp> <87wvn3202u.fsf@buck.sodan.org> <7teem9b4l7e.fsf@atesoft.advantest.co.jp> <7te4sa747og.fsf@atesoft.advantest.co.jp> <7teu2i5j3p6.wl@puyo.atesoft.advantest.co.jp> Message-ID: <8766ulhxgj.fsf@buck.sodan.org> ari @ atesoft.advantest.co.jp writes: > At Fri, 17 Mar 2000 15:18:16 +0900, > teranisi @ gohome.org (Yuuichi Teranishi) wrote: > > > もしかして、Wanderlust 側で以下のようにすると > > EMY はもとのままでも大丈夫ではないでしょうか? > > 添付の patch を当ててみたところ、`mime-display-gzipped' にて > (set-buffer-multibyte nil) を評価してもしなくても、 > 問題無く表示できました。 > > ということで、mmbuffer.el の `mime-entity-content' を同様に > してみたところ、前述の全てのMUA で問題無く表示できました:-) なるほど、今の FLIM の実装だと raw buffer の enable-multibyte-characters の値を引き継ぐので、insert 時に その buffer で同じ値でないと各 representation に変換されてし まうわけですね。 寺西さんの patch を当てると、temp buffer と enable-multibyte-characters の値が常に同じになるので大丈夫で ある、と。 現時点ではさらに EMY に ugly hack をほどこして、T-gnus でも Wanderlust でも動作するようにしました。 # cvs.m17n.org が反応してくれないのでまだ commit していませ # ん。 寺西さんの patch を FLIM 1.13.2 に当ててしまおうと思っていま すが、その後で FLIM 1.13.3 を release して頂きたいです。どう でしょう、守岡さん。 -- Yoshiki Hayashi From yoshiki @ xemacs.org Sat Mar 18 10:17:55 2000 From: yoshiki @ xemacs.org (Yoshiki Hayashi) Date: Sat, 18 Mar 2000 10:17:55 +0900 Subject: =?ISO-2022-JP?B?GyRCJWolVyVpJSQkRyUoJWkhPBsoQg==?= In-Reply-To: (Toshihiko Kodama's message of "Thu, 16 Mar 2000 17:27:46 +0900") References: Message-ID: <87aejxhy9o.fsf@buck.sodan.org> Toshihiko Kodama (小玉 利彦) writes: > >>>>> In [Wanderlust : No.04439] > >>>>> okada @ opaopa.org (岡田 健一 / Kenichi OKADA) wrote: > > 岡田> M-x debug-on-entry mime-preview-entity-boundary > 岡田> してみて、 point がどこで、nil になっているかわかりますか? > > 以下のようになりました たぶん、multipart で part をたぐっていっているときに nil に なっているのだと思います。 (let ((child (car (last (mime-entity-children entity))))) (while (not (eq (get-text-property point 'mime-view-entity) child)) (setq point (next-single-property-change point 'mime-view-entity))) (setq entity child)))) で、multipart の部分の最後の part がまったく表示されていない と error になります。ですが、EMY の実装上は body が表示され ないときは常に button が表示されるようになっているので、その ような状況は本来は発生しないはずなのです。 もし問題が無ければ、その message を私宛に送っていただけない でしょうか? 駄目な場合は、その message と全く同じ構造のもの で、問題が再現するようならその message を送っていただけませ んか? # もしかして IMAP の partial fetch 関連だったりするんでしょ # うか。 -- Yoshiki Hayashi From tomo @ etl.go.jp Mon Mar 20 17:58:54 2000 From: tomo @ etl.go.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko) Date: 20 Mar 2000 17:58:54 +0900 Subject: [emy] mime-display-gzipped In-Reply-To: Yoshiki Hayashi's message of "Sat, 18 Mar 2000 10:35:24 +0900" References: <7tek8j7k13v.fsf@atesoft.advantest.co.jp> <87ln3l2vql.fsf@dp50.ecc.u-tokyo.ac.jp> <7teya7l6mfp.fsf@atesoft.advantest.co.jp> <87wvn3202u.fsf@buck.sodan.org> <7teem9b4l7e.fsf@atesoft.advantest.co.jp> <7te4sa747og.fsf@atesoft.advantest.co.jp> <7teu2i5j3p6.wl@puyo.atesoft.advantest.co.jp> <8766ulhxgj.fsf@buck.sodan.org> Message-ID: >>>>> [emacs-mime-ja : No.00491] にて >>>>> “Yoshiki”= Yoshiki Hayashi さま曰く: Yoshiki> 寺西さんの patch を FLIM 1.13.2 に当ててしまおうと思っていま Yoshiki> すが、その後で FLIM 1.13.3 を release して頂きたいです。どう Yoshiki> でしょう、守岡さん。 保留します。 寺西さんの patch というのが良く判っていないのですが、 のことであれば、これ自体は問題ない気もするんです が、後述するように若干不安要因があります。また、これで直るのだとすると 問題は MEL 層に関連している可能性があり、原因を究明して直したとは言え ないと思います。 もし、抜本的に直すのなら、mime-entity-content の返り値は unibyte 文字 列であることを明示するような修正が良いと思います。 また、EMY 1.13 の mime-display-gzipped を眺めてみましたが、この code は原理的な問題を抱えている気がします。まず、mime-entity-content の返り 値を挿入する temporary-buffer は byte 列ですから unibyte buffer を用意 する必要があります。これの実現の仕方はちょっとうげげではあるんですが、 (let (default-enable-multibyte-characters) (with-temp-buffer ...) か (with-temp-buffer (set-buffer-multibyte nil) ...) 見たいな感じでしょうか? gzip での処理は byte 列の処理ですから unibyte として扱うのが正しいと思 います。 で、問題は decode-coding-region で、これは入力は byte 列、出力は文字列 のような処理だと考えられますが、単一の buffer では byte と文字の見分け はつかないので、両者の混在状態を作ってしまう decode-coding-region の使 用は望ましくないです。特に、この関数では decode-coding-region を用いる 必然性は全くないと思います。この場合、decode-coding-string を使った方 が無難でしょう。 ;; [補足] FLIM/SEMI の世界では以下のことが期待されています: ;; ・整数と文字は違う抽象型として区別する ;; ・byte 列と文字列は違う抽象型として区別する ;; ・byte 列は unibyte で表現する ;; ・文字列は unibyte/multibyte のどちらかを取り得る ;; ・STD 11 の世界は byte 列として解釈する ;;; もちろん、FLIM/SEMI 自体がこの観点から見ておかしい可能性があります ;;; が、その場合は扱っているのが byte 列なのか文字列なのかを判断して適 ;;; 切に修正するのが望ましいと思います。 Yoshiki> > ということで、mmbuffer.el の `mime-entity-content' を同様に Yoshiki> > してみたところ、前述の全てのMUA で問題無く表示できました:-) Yoshiki> なるほど、今の FLIM の実装だと raw buffer の Yoshiki> enable-multibyte-characters の値を引き継ぐので、insert 時に Yoshiki> その buffer で同じ値でないと各 representation に変換されてし Yoshiki> まうわけですね。 Emacs は文字列を「byte 列」ではなく「文字列」として解釈します。一方、 `mime-entity-content' の返り値は「byte 列」です。よって、意味的には unibyte 文字列であることが望ましいと言えます。 ;; raw-buffer は MUA が unibyte buffer にしているはずなので、MEL が変 ;; なことをしてなければ返り値も unibyte になることが期待できる訳です。 また、preview buffer のような概念的に文字列であるところに `mime-entity-content' の返り値を挿入するのは誤った操作であると考えられ ます。 Yoshiki> 寺西さんの patch を当てると、temp buffer と Yoshiki> enable-multibyte-characters の値が常に同じになるので大丈夫で Yoshiki> ある、と。 新たに生成される buffer が unibyte か multibyte かを決めるのは変数 default-enable-multibyte-characters で、 はこのこ とを保証していないと思います。また、FLIM 的には multibyte 表現を返すの はおかしいと言えます。いずれにしてもこの修正が効果を持つのだとすればな にやら良からぬことが起こっていると考えられます。 という訳で、再検討をお願いします。 -- ===『幾千億の分子に分かれても ======================================== 決して忘れない。 この宇宙が終るまで』 守岡 知彦 (MORIOKA Tomohiko) ======================================== Email: ===== From yoshiki @ xemacs.org Mon Mar 20 22:21:51 2000 From: yoshiki @ xemacs.org (Yoshiki Hayashi) Date: Mon, 20 Mar 2000 22:21:51 +0900 Subject: =?ISO-2022-JP?B?GyRCJWolVyVpJSQkRyUoJWkhPBsoQg==?= In-Reply-To: <87aejxhy9o.fsf@buck.sodan.org> (Yoshiki Hayashi's message of "Sat, 18 Mar 2000 10:17:55 +0900") References: <87aejxhy9o.fsf@buck.sodan.org> Message-ID: <87aejtixow.fsf@buck.sodan.org> Yoshiki Hayashi writes: > もし問題が無ければ、その message を私宛に送っていただけない > でしょうか? 駄目な場合は、その message と全く同じ構造のもの > で、問題が再現するようならその message を送っていただけませ > んか? 小玉さんに message を送って頂いたので、原因が判明しました。 multipart/mixed の最後の part が multipart/digest の場合のあ つかいに問題がありました。 # multipart の entity は普通は button が表示されないので # preview buffer には表示されません。 以下のように対処したので試してみてください。 root entity に対しては (point-max) を即座に返すようにしたの で、Wanderlust での reply では error は絶対に発生しなくなっ たと思います。 # 逆に bug が見つかりにくくなったとも言う。(^^;; -------------- next part -------------- --- mime-view.el~ Sat Mar 18 00:52:22 2000 +++ mime-view.el Mon Mar 20 20:55:06 2000 @@ -1525,6 +1525,7 @@ (if header-exists (delete-region (goto-char (point-min)) (re-search-forward "^$")) + (goto-char (point-min)) (insert "\n")) (goto-char (point-min)) (let ((current-entity @@ -1730,20 +1731,34 @@ (let ((entity (get-text-property point 'mime-view-entity)) (start (previous-single-property-change (1+ point) 'mime-view-entity nil (point-min))) - (end point) - done) - (while (and (mime-entity-children entity) - (not done)) - (if (not (mime-view-body-is-visible - (get-text-property point 'mime-view-situation))) - (setq done t) - ;; If the part is shown, search the last part. - (let ((child (car (last (mime-entity-children entity))))) - (while (not (eq (get-text-property point 'mime-view-entity) child)) - (setq point (next-single-property-change point 'mime-view-entity))) - (setq entity child)))) - (setq end (next-single-property-change point 'mime-view-entity - nil (point-max))) + end done) + (if (not (mime-entity-node-id entity)) + (setq end (point-max)) + (while (and (mime-entity-children entity) + (not done)) + (if (not (mime-view-body-is-visible + (get-text-property point 'mime-view-situation))) + (setq done t) + ;; If the part is shown, search the last part. + (let* ((child (car (last (mime-entity-children entity)))) + (node-id (mime-entity-node-id child)) + (tmp-node-id (mime-entity-node-id + (get-text-property point + 'mime-view-entity)))) + (while (or (< (length tmp-node-id) + (length node-id)) + (not (eq (nthcdr (- (length tmp-node-id) + (length node-id)) + tmp-node-id) + node-id))) + (setq point + (next-single-property-change point 'mime-view-entity) + tmp-node-id (mime-entity-node-id + (get-text-property point + 'mime-view-entity)))) + (setq entity child)))) + (setq end (next-single-property-change + point 'mime-view-entity nil (point-max)))) (cons start end))) (defun mime-preview-toggle-header (&optional show) -------------- next part -------------- -- Yoshiki Hayashi From teranisi @ gohome.org Tue Mar 21 18:31:32 2000 From: teranisi @ gohome.org (Yuuichi Teranishi) Date: Tue, 21 Mar 2000 18:31:32 +0900 Subject: [emy] mime-display-gzipped In-Reply-To: In your message of "20 Mar 2000 17:58:54 +0900" References: <7tek8j7k13v.fsf@atesoft.advantest.co.jp> <87ln3l2vql.fsf@dp50.ecc.u-tokyo.ac.jp> <7teya7l6mfp.fsf@atesoft.advantest.co.jp> <87wvn3202u.fsf@buck.sodan.org> <7teem9b4l7e.fsf@atesoft.advantest.co.jp> <7te4sa747og.fsf@atesoft.advantest.co.jp> <7teu2i5j3p6.wl@puyo.atesoft.advantest.co.jp> <8766ulhxgj.fsf@buck.sodan.org> Message-ID: At 20 Mar 2000 17:58:54 +0900, 守岡さん wrote: > > ;; raw-buffer は MUA が unibyte buffer にしているはずなので、MEL が変 > ;; なことをしてなければ返り値も unibyte になることが期待できる訳です。 > 有沢さんが示された下の 3 つは、 raw-buffer が multibyte になっていると思われるので、 これらの方を直すのが正しい気がします。 At 16 Mar 2000 17:53:51 +0900, 有沢さん wrote: > > ● (set-buffer-multibyte nil) としなければならない > Wanderlust (2.2.12) > SEMI-VM (6.75-19991026-1) > EMH (1.10.1) > CMAIL (2.60+20000216) > ● (set-buffer-multibyte nil) としてはいけない > T-gnus (6.14.1 r12) > RMAIL-MIME (1.13.0) > mime-edit-preview-message mime-edit-preview-message は、直すとするとここらへんでしょうか。 --- mime-edit.el~ Wed Sep 29 19:19:09 1999 +++ mime-edit.el Tue Mar 21 18:02:18 2000 @@ -2580,6 +2580,7 @@ (concat "^" (regexp-quote separator) "$")) (replace-match "") ) + (set-buffer-multibyte nil) (mime-view-buffer) )) EMY の mime-display-gzipped はこんなかんじですかね..。 (defun mime-display-gzipped (entity situation) "Ungzip gzipped part and display." (insert (decode-coding-string (with-temp-buffer (set-buffer-multibyte nil) (insert (mime-entity-content entity)) (as-binary-process (call-process-region (point-min) (point-max) "gzip" t t nil "-cd")) (buffer-string)) 'undecided)) t) -- Yuuichi Teranishi (寺西裕一) PGP 5.0i Public Key: http://www.gohome.org/pgp5/teranisi.key "There will be an answer, let it be..." From tomo @ etl.go.jp Tue Mar 21 18:54:36 2000 From: tomo @ etl.go.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko) Date: 21 Mar 2000 18:54:36 +0900 Subject: bytes vs. characters problem (Re: [emy] mime-display-gzipped) In-Reply-To: Yuuichi Teranishi's message of "Tue, 21 Mar 2000 18:31:32 +0900" References: <7tek8j7k13v.fsf@atesoft.advantest.co.jp> <87ln3l2vql.fsf@dp50.ecc.u-tokyo.ac.jp> <7teya7l6mfp.fsf@atesoft.advantest.co.jp> <87wvn3202u.fsf@buck.sodan.org> <7teem9b4l7e.fsf@atesoft.advantest.co.jp> <7te4sa747og.fsf@atesoft.advantest.co.jp> <7teu2i5j3p6.wl@puyo.atesoft.advantest.co.jp> <8766ulhxgj.fsf@buck.sodan.org> Message-ID: >>>>> In [emacs-mime-ja : No.00495] >>>>> "寺西" = Yuuichi Teranishi wrote: 寺西> > ;; raw-buffer は MUA が unibyte buffer にしているはずなので、 寺西> > ;; MEL が変なことをしてなければ返り値も unibyte になることが期 寺西> > ;; 待できる訳です。 寺西> At 16 Mar 2000 17:53:51 +0900, 寺西> 有沢さん wrote: 寺西> > 寺西> > ● (set-buffer-multibyte nil) としなければならない 寺西> > Wanderlust (2.2.12) 寺西> > SEMI-VM (6.75-19991026-1) 寺西> > EMH (1.10.1) 寺西> > CMAIL (2.60+20000216) 寺西> > ● (set-buffer-multibyte nil) としてはいけない 寺西> > T-gnus (6.14.1 r12) 寺西> > RMAIL-MIME (1.13.0) 寺西> > mime-edit-preview-message 寺西> 有沢さんが示された下の 3 つは、 寺西> raw-buffer が multibyte になっていると思われるので、 寺西> これらの方を直すのが正しい気がします。 そうですね。 寺西> mime-edit-preview-message は、直すとするとここらへんでしょうか。 寺西> --- mime-edit.el~ Wed Sep 29 19:19:09 1999 寺西> +++ mime-edit.el Tue Mar 21 18:02:18 2000 寺西> @@ -2580,6 +2580,7 @@ 寺西> (concat "^" (regexp-quote separator) "$")) 寺西> (replace-match "") 寺西> ) 寺西> + (set-buffer-multibyte nil) 寺西> (mime-view-buffer) 寺西> )) うーん、げろげろだけどここしかないかな。 ;; げろげろなのは mime-edit のせいですね。(^_^;;; とりあえず、FLIM 1.13 は修正なしで良いでしょうか? -- ┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━ ││ ─ │ ─ / ─ ┼─ ┬ ─ ─┼ ┬┴─ ┼┼─┼|〓━─┼ 守岡 知彦 (MORIOKA Tomohiko) ─ ─┬ ┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━> From ari @ atesoft.advantest.co.jp Wed Mar 22 14:04:49 2000 From: ari @ atesoft.advantest.co.jp (Akihiro Arisawa) Date: 22 Mar 2000 14:04:49 +0900 Subject: bytes vs. characters problem (Re: [emy] mime-display-gzipped) In-Reply-To: (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko's message of "21 Mar 2000 18:54:36 +0900") References: <7tek8j7k13v.fsf@atesoft.advantest.co.jp> <87ln3l2vql.fsf@dp50.ecc.u-tokyo.ac.jp> <7teya7l6mfp.fsf@atesoft.advantest.co.jp> <87wvn3202u.fsf@buck.sodan.org> <7teem9b4l7e.fsf@atesoft.advantest.co.jp> <7te4sa747og.fsf@atesoft.advantest.co.jp> <7teu2i5j3p6.wl@puyo.atesoft.advantest.co.jp> <8766ulhxgj.fsf@buck.sodan.org> Message-ID: <7teya7bd28e.fsf@atesoft.advantest.co.jp> >>>>> In [emacs-mime-ja : No.00496] >>>>> tomo @ etl.go.jp (守岡 知彦 / MORIOKA Tomohiko) wrote: 有沢> T-gnus (6.14.1 r12) 有沢> RMAIL-MIME (1.13.0) 有沢> mime-edit-preview-message 寺西> 有沢さんが示された下の 3 つは、 寺西> raw-buffer が multibyte になっていると思われるので、 寺西> これらの方を直すのが正しい気がします。 守岡> そうですね。 T-gnus, RMAIL-MIME 共に以下のように変更し、mime-display-gzipped を [emacs-mime-ja : No.00495] のようにしたところ、問題なく表示できました。 -------------- next part -------------- --- gnus-art.el.orig Tue Feb 15 10:02:00 2000 +++ gnus-art.el Wed Mar 22 12:39:46 2000 @@ -2792,6 +2792,7 @@ ;; Init original article buffer. (save-excursion (set-buffer (gnus-get-buffer-create gnus-original-article-buffer)) + (set-buffer-multibyte nil) (setq major-mode 'gnus-original-article-mode) (make-local-variable 'gnus-original-article)) (if (get-buffer name) -------------- next part -------------- --- rmail-mime.el.orig Wed Mar 22 13:04:28 2000 +++ rmail-mime.el Wed Mar 22 13:04:05 2000 @@ -74,6 +74,7 @@ (defun rmail-show-mime-message () ;; (rmail-show-all-header) (rmail-toggle-header 0) + (set-buffer-multibyte nil) (let ((abuf (current-buffer)) (buf-name (concat "*View-" (buffer-name) "*")) buf win) -------------- next part -------------- ;; どちらもこれでいいのかは分かってないですが。 ;;; RMAIL は rmail.el の方を変更するべきな気が(^^; -- 有沢 明宏 From keiichi @ nanap.org Wed Mar 22 15:41:05 2000 From: keiichi @ nanap.org (Keiichi Suzuki) Date: 22 Mar 2000 15:41:05 +0900 Subject: bytes vs. characters problem (Re: [emy] mime-display-gzipped) In-Reply-To: <7teya7bd28e.fsf@atesoft.advantest.co.jp> (ari@atesoft.advantest.co.jp's message of "22 Mar 2000 14:04:49 +0900") References: <7tek8j7k13v.fsf@atesoft.advantest.co.jp> <87ln3l2vql.fsf@dp50.ecc.u-tokyo.ac.jp> <7teya7l6mfp.fsf@atesoft.advantest.co.jp> <87wvn3202u.fsf@buck.sodan.org> <7teem9b4l7e.fsf@atesoft.advantest.co.jp> <7te4sa747og.fsf@atesoft.advantest.co.jp> <7teu2i5j3p6.wl@puyo.atesoft.advantest.co.jp> <8766ulhxgj.fsf@buck.sodan.org> <7teya7bd28e.fsf@atesoft.advantest.co.jp> Message-ID: ;; すみません、時間がとれませんので、ちょっと困ることだけです。 >>>>> emacs-mime-ja の No. 00497 >>>>> Message-Id: <7teya7bd28e.fsf @ atesoft.advantest.co.jp> で、 >>>>> "有沢" == ari @ atesoft.advantest.co.jp (Akihiro Arisawa)さま曰く... 有沢> T-gnus (6.14.1 r12) 有沢> RMAIL-MIME (1.13.0) 有沢> mime-edit-preview-message 寺西> 有沢さんが示された下の 3 つは、 寺西> raw-buffer が multibyte になっていると思われるので、 寺西> これらの方を直すのが正しい気がします。 守岡> そうですね。 有沢> T-gnus, RMAIL-MIME 共に以下のように変更し、mime-display-gzipped を 有沢> [emacs-mime-ja : No.00495] のようにしたところ、問題なく表示できました。 有沢> ;; Init original article buffer. 有沢> (save-excursion 有沢> (set-buffer (gnus-get-buffer-create gnus-original-article-buffer)) 有沢> + (set-buffer-multibyte nil) gnus-original-article-buffer をこうしてしまうと、 (set-buffer gnus-original-article-buffer) している系の、 BBDB の update-record がうまく field を decode できなくなっ て破綻するようです。(gnus 付属の gnus-bbdb.el のものも含まれます。) ;; ちなみに、本家 Gnus 5.8.3 ではわざわざ enable にしているようですね。 -- 鈴木圭一 / keiichi @ nanap.org PGP finger print (DH/DSS) 0B32 B37E 6DE9 3BC1 68A4 4089 7AAF 2B03 ECBD 614B From yoshiki @ xemacs.org Fri Mar 24 16:19:03 2000 From: yoshiki @ xemacs.org (Yoshiki Hayashi) Date: Fri, 24 Mar 2000 16:19:03 +0900 Subject: bytes vs. characters problem (Re: [emy] mime-display-gzipped) In-Reply-To: <7teya7bd28e.fsf@atesoft.advantest.co.jp> (Akihiro Arisawa's message of "Wed, 22 Mar 2000 14:04:49 +0900") References: <7tek8j7k13v.fsf@atesoft.advantest.co.jp> <87ln3l2vql.fsf@dp50.ecc.u-tokyo.ac.jp> <7teya7l6mfp.fsf@atesoft.advantest.co.jp> <87wvn3202u.fsf@buck.sodan.org> <7teem9b4l7e.fsf@atesoft.advantest.co.jp> <7te4sa747og.fsf@atesoft.advantest.co.jp> <7teu2i5j3p6.wl@puyo.atesoft.advantest.co.jp> <8766ulhxgj.fsf@buck.sodan.org> <7teya7bd28e.fsf@atesoft.advantest.co.jp> Message-ID: <87u2hw7s48.fsf@buck.sodan.org> ari @ atesoft.advantest.co.jp (Akihiro Arisawa) writes: > >>>>> In [emacs-mime-ja : No.00496] > >>>>> tomo @ etl.go.jp (守岡 知彦 / MORIOKA Tomohiko) wrote: > > 有沢> T-gnus (6.14.1 r12) > 有沢> RMAIL-MIME (1.13.0) > 有沢> mime-edit-preview-message > 寺西> 有沢さんが示された下の 3 つは、 > 寺西> raw-buffer が multibyte になっていると思われるので、 > 寺西> これらの方を直すのが正しい気がします。 > 守岡> そうですね。 > > T-gnus, RMAIL-MIME 共に以下のように変更し、mime-display-gzipped を > [emacs-mime-ja : No.00495] のようにしたところ、問題なく表示できました。 今の CVS 版の EMY の code で、T-gnus の変更無しでも動くと思 うのですが、有沢さんのところでも動きますよね。 # 新しい方にしたら、という話だと思うけど、念のため。(^^; 寺西さんが書かれたものの方がすっきりとしていて、Right Thing を実行していますが、EMY 側では最新の MUA に update すること を要求したくはないので、今の code のままにしようと思います。 ちょっと試してみたところでは、FSF Emacs では、internal code の byte sequence が見えかくれして嫌な感じなのですが、 decode-coding-region も動いているようにみえます。source code は見てないので想像ですが、buffer を multibyte にしたときに、 internal code に存在する byte sequence は文字に変換されてし まうようですが、decode-coding-region は文字の internal code の byte sequence を使うようなので動作するようです。 FSF Emacs 上ではかなり気持悪いことになっていますが、とりあえ ず動けば良いことにしておきます。:-) # 山岡さんが書かれていた問題そのものだけど、FSF Emacs では普 # 通に string を処理しているときに、current buffer の # multibyte-ness で結果が変わるのだけはどうしても耐えられな # い。寺西さんの code でも、間違って decode-coding-string を # with-temp-buffer の中に書くと、^[$B とかになるし。 ;; Emacs/Mule is broken. :-) -- Yoshiki Hayashi