From tomo ＠ m17n.org  Mon Jun  3 18:52:42 2002
From: tomo ＠ m17n.org (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= /
 MORIOKA Tomohiko)
Date: 03 Jun 2002 18:52:42 +0900
Subject: FLIM 1.14.4 =?ISO-2022-JP?B?KBskQjNgODY/QDVcQTAbKEIp?=
Message-ID: <htx6610g045.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>

[Status] beta


[Recommended environment]

APEL: 10.3


[Changes]

2002-06-03  MORIOKA Tomohiko  <tomo ＠ kanji.zinbun.kyoto-u.ac.jp>

	* FLIM: Version 1.14.4 (Kashiharajingū-mae) released.

2002-01-16  Hiroya Murata     <lapis-lazuli ＠ pop06.odn.ne.jp>

	* luna.el (luna-class-find-member): Don't search parents'
	method-spaces.

2002-02-01  Kenichi OKADA     <okada ＠ opaopa.org>

	* eword-encode.el (mime-header-encode-method-alist): New variable.
	(mime-encode-field-body): Use `mime-header-encode-method-alist'.
	(mime-encode-header-in-buffer): Error if cannot encode.

2001-11-03  Shuhei KOBAYASHI  <shuhei ＠ aqua.ocn.ne.jp>

	* hmac-md5.el: Removed kludge for Emacs 21 prerelease versions.

2001-07-16  Katsumi Yamaoka   <yamaoka ＠ jpl.org>

	* smtpmail.el (smtpmail-send-it): Work even if the first line of
	the subject field has no content (synch with Emacs 20.3).

2001-07-30  AMAKAWA Shuhei    <sa264 ＠ cam.ac.uk>

	* smtp.el (smtp-submit-package): Send EHLO after starttls.

-------------- next part --------------

  It is available from

    http://www.kanji.zinbun.kyoto-u.ac.jp/~tomo/comp/emacsen/lisp/flim/flim-1.14/

-------------- next part --------------
-- 
===????????????? ========================================
     ????????    
     ??????????              ?? ?? (MORIOKA Tomohiko)
====================== Email: <tomo ＠ kanji.zinbun.kyoto-u.ac.jp> ======

From tomo ＠ kanji.zinbun.kyoto-u.ac.jp  Fri Jun  7 17:26:11 2002
From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?=
 =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko)
Date: 07 Jun 2002 17:26:11 +0900
Subject: ms-tnef =?ISO-2022-JP?B?GyRCJE4bKEI=?= SEMI
 =?ISO-2022-JP?B?GyRCRXkkRyROGyhC?= parse.
In-Reply-To: Tatsuya Ichikawa's message of "21 May 2002 06:49:01 -0500"
References: <yosu4rh0alle.fsf@jpl.org>
Message-ID: <htxadq7jxzw.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>

守岡です。

御無沙汰してます。(^_^;

>>>>> In [emacs-mime-ja : No.01026] 
>>>>>	"市川さん" = Tatsuya Ichikawa <ichikawa ＠ jpl.org> wrote:

市川さん>   application/ms-tnef 形式の添付ファイルを SEMI/FLIM 等で 
市川さん>   parse/decodeして、play 出来るようにする方法、と言うものは
市川さん>   あるんでしょうか?
市川さん>   現状、application/ms-tnef の部分を保存し、tnef と言う
市川さん>   parser/decoder でファイルを取り出していますが、結構不便だっ
市川さん>   たりします。これを Emacs 上(SEMI/LIMIT/APEL/Gnus)を使用し
市川さん>   ています)から直接Parse/Decode (例えば base64 のように…)す
市川さん>   ることは出来るんでしょうか?  もしくは、もうやっている人は…
市川さん>   いますか?

あんまり良く判ってないのですが、.mailcap にその tnef コマンドを設定す
るのではだめなんでしょうか？

-- 
===『幾千億の分子に分かれても ========================================
     決して忘れない。    
     この宇宙が終るまで』              守岡 知彦 (MORIOKA Tomohiko)
====================== Email: <tomo ＠ kanji.zinbun.kyoto-u.ac.jp> ======



From tomo ＠ kanji.zinbun.kyoto-u.ac.jp  Fri Jun  7 17:44:09 2002
From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?=
 =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko)
Date: 07 Jun 2002 17:44:09 +0900
Subject: default value of mime-file-types in mime-edit.el
In-Reply-To: Yoichi NAKAYAMA's message of "Sun, 05 May 2002 03:52:27 +0900"
References: <wybsbveoes.wl@eken6.eken.phys.nagoya-u.ac.jp>
Message-ID: <htx7klbjx5y.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>

>>>>> [emacs-mime-ja : No.01015] にて
>>>>> “なかやまさん”= Yoichi NAKAYAMA
      <yoichi ＠ eken.phys.nagoya-u.ac.jp> さま曰く:

なかやまさん> 某所で application/octet-stream なメイルを弾く設定につい
なかやまさん> ての話をしている中で、「patch は text/x-patch が正しいの
なかやまさん> だ」と言われたので少し調べて見たのですが、RFC2046 を見る
なかやまさん> と、text のとこにはmaterial which is principally textual
なかやまさん> in form とあって、一方でoctet-stream のとこには 
なかやまさん> arbitrary binary data とあるので、diffは通常 text だから 
なかやまさん> text/* のが適切なのかと思ってしまったのですがデフォルト
なかやまさん> の設定としてはどうなんでしょうか？

思い付く論点としては、

(a) なるべく x-* を使わない vs. x-* を使ってでも固有の media-type があっ
    た方が良い

(b) diff は誰が何のために見る・使うものか？（patch が使うものである
    vs. 人間が見るものである）

があります。

(a) に関していえば、application/octet-stream は default の media-type
なので、他に適切な media-type があればそれを付けた方が良いということは
言えそうですが、x-* を使う程かということはあります。あと、固有な
media-type を付けることのメリットの一つは自動処理がしやすくなるという
ことがありますが、なんとなく自動的に patch を当てるのは良くないような
気もします。

(b) に関していえば、text/* は人間が見るために改行や文字符号の変換が行
われる可能性があり、charset パラメーターを指定したりする訳ですが、これ
が diff に適切かどうかという議論があります。もちろん、人間が見るものと
いう位置付けであればそれで良い訳ですが。そして、diff は patch のための
ものだとすると、仮に media-type を与えるとすれば、
application/vnd.patch みたいなのが適切な気がします。

個人的には text/x-patch はあんまり良くない気がしてるんですが、実際問題
そっちが流通しているとか、そうじゃないと困るという意見が多ければ、
default を変えることに反対しません。

-- 
===『幾千億の分子に分かれても ========================================
     決して忘れない。    
     この宇宙が終るまで』              守岡 知彦 (MORIOKA Tomohiko)
====================== Email: <tomo ＠ kanji.zinbun.kyoto-u.ac.jp> ======



From shuhei ＠ aqua.ocn.ne.jp  Fri Jun  7 23:34:44 2002
From: shuhei ＠ aqua.ocn.ne.jp (Shuhei KOBAYASHI)
Date: 07 Jun 2002 23:34:44 +0900
Subject: flim-1_14-rfc2231-encoder
References: <1023138012.18859@cvs.m17n.org>
Message-ID: <86k7pbtawr.fsf@aqua.ocn.ne.jp>

少し前のことですが, flim-1_14-rfc2231-encoder branch が作成されました.
;; m17n の cvs-info watchers に発見されることを期待していたのですが...


現状の問題点は extended-parameter に比べると regular-parameter の分割が
少し手抜きであること(この辺は私のせい)と, field-body が US-ASCII のみの
場合は mime-encode-header-in-buffer が素通ししてしまうので encoder には
渡らない(これは message/external-body の URL parameter などで問題になる)
ということです.

後者については, 岡田さんによる mime-header-encode-method-alist の導入前
ならば, mime-encode-header-in-buffer から以下のように US-ASCII の判定を
なくした上で

(defun mime-encode-header-in-buffer (&optional code-conversion)
  "Encode header fields to network representation, such as MIME encoded-word.

It refer variable `mime-field-encoding-method-alist'."
  (interactive "*")
  (save-excursion
    (save-restriction
      (std11-narrow-to-header mail-header-separator)
      (goto-char (point-min))
      (let ((default-cs (mime-charset-to-coding-system default-mime-charset))
	    beg end field-name)
	(while (re-search-forward std11-field-head-regexp nil t)
	  (setq beg (match-end 0)
		field-name (buffer-substring (match-beginning 0) (1- beg))
		end (std11-field-end))
          (let ((method (eword-find-field-encoding-method field-name)))
            (cond ((eq method 'mime)
                   (insert
                    (prog1
                        (mime-encode-field-body
                         (buffer-substring beg end)
                         field-name)
                      (delete-region beg end))))
                  (code-conversion
                   (encode-coding-region
                    beg end
                    (or (mime-charset-to-coding-system method)
                        default-cs))))))))))

mime-encode-field-body の途中にその判定を移すという手を考えたのですが,

(defun mime-encode-field-body (field-body field-name)
  "Encode FIELD-BODY as FIELD-NAME, and return the result.
A lexical token includes non-ASCII character is encoded as MIME
encoded-word.  ASCII token is not encoded."
  (setq field-body (std11-unfold-string field-body))
  (if (string= field-body "")
      ""
    (let (start)
      (if (symbolp field-name)
	  (setq start (1+ (length (symbol-name field-name))))
	(setq start (1+ (length field-name))
	      field-name (intern (capitalize field-name))))
      (cond ((eq field-name 'Content-Type)
             (eword-encode-Content-Type-field-body field-body start))
            ((eq field-name 'Content-Disposition)
             (eword-encode-Content-Disposition-field-body field-body start))
            ((null (find-non-ascii-charset-string field-body))
             field-body)
            ((memq field-name
		   '(Reply-To
		     From Sender
		     Resent-Reply-To Resent-From
		     Resent-Sender To Resent-To
		     Cc Resent-Cc Bcc Resent-Bcc
		     Dcc))
	     (eword-encode-address-list field-body start))
	    ((eq field-name 'In-Reply-To)
	     (eword-encode-in-reply-to field-body start))
	    ((memq field-name '(Mime-Version User-Agent))
	     (eword-encode-structured-field-body field-body start))
	    (t
	     (eword-encode-unstructured-field-body field-body start))))))

mime-header-encode-method-alist には各 field に対する encoder を手軽に
変更できるという利点があるので, (mime-field-encoding-method-alist も
含めて?)この辺は見直した方が良いような気がします.

;; mime-field-encoding-method-alist の docstring は実装と合っていない.
-- 
Shuhei KOBAYASHI



From ichikawa ＠ jpl.org  Fri Jun  7 15:48:58 2002
From: ichikawa ＠ jpl.org (Tatsuya Ichikawa)
Date: 07 Jun 2002 01:48:58 -0500
Subject: ms-tnef =?ISO-2022-JP?B?GyRCJE4bKEI=?= SEMI
 =?ISO-2022-JP?B?GyRCRXkkRyROGyhC?= parse.
In-Reply-To: <htxadq7jxzw.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>
 (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko's
 message of "07 Jun 2002 17:26:11 +0900")
References: <yosu4rh0alle.fsf@jpl.org>
	<htxadq7jxzw.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <yosun0u6zov9.fsf@jpl.org>

>>>>> In [emacs-mime-ja : No.01029]
>>>>> tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡 知彦 / MORIOKA Tomohiko) wrote:

守岡> 御無沙汰してます。(^_^;

  本当に御無沙汰しています (^^)

市川>   application/ms-tnef 形式の添付ファイルを SEMI/FLIM 等で
市川>   parse/decodeして、play 出来るようにする方法、と言うものは
市川>   あるんでしょうか?
市川>   現状、application/ms-tnef の部分を保存し、tnef と言う
市川>   parser/decoder でファイルを取り出していますが、結構不便だっ
市川>   たりします。これを Emacs 上(SEMI/LIMIT/APEL/Gnus)を使用し
市川>   ています)から直接Parse/Decode (例えば base64 のように…)す
市川>   ることは出来るんでしょうか?  もしくは、もうやっている人は…
市川>   いますか?

守岡> あんまり良く判ってないのですが、.mailcap にその tnef コマンドを
守岡> 設定するのではだめなんでしょうか？

  tnef コマンドはあくまで ms-tnef を parse し解凍/ファイルの保存するた
  めのものです。
  また ms-tnef は複数の添付ファイルを一まとめにして encode するので、
  複数くっついていても SEMI/FLIM で解析すると 1 添付ファイルに見えてし
  まいます。

   [<application/ms-tnef base64...>]

  と言う風に見えます。

  私が求めている方法は、(どんな方法を取るにしても)、ms-tnef 形式のもの
  を解析し

   [foo.doc <application/hogehoge ....>]
   [bar.doc <application/hogehoge ....>]

  等と中身に入っているものをすべてリストアップでき、"v" で一発アプリケー
  ション起動! と言うのが欲しいんですね (^^)

  こうすると、中身が確認できて、さらに 1 つ 1 つ確認しながらの起動が出
  来ますよね??

  反応が無い…と言うのはだれも困っていない…と言うことですね。

-- 
  Tatsuya - Tim - Ichikawa <ichikawa ＠ jpl.org>



From batta ＠ beige.ocn.ne.jp  Mon Jun 10 01:04:53 2002
From: batta ＠ beige.ocn.ne.jp (KAWABATA, Taichi)
Date: Mon, 10 Jun 2002 01:04:53 +0900
Subject: flim-1_14-rfc2231-encoder
In-Reply-To: <86k7pbtawr.fsf@aqua.ocn.ne.jp>
 (Shuhei KOBAYASHI's message of "07 Jun 2002 23:34:44 +0900")
References: <1023138012.18859@cvs.m17n.org> <86k7pbtawr.fsf@aqua.ocn.ne.jp>
Message-ID: <m3ofeko2u2.fsf@beige.ocn.ne.jp>

川幡です。

>>>>> [emacs-mime-ja : No.01031] (flim-1_14-rfc2231-encoder) で
>>>>> 小林さん は書きました

> 少し前のことですが, flim-1_14-rfc2231-encoder branch が作成されました.
> ;; m17n の cvs-info watchers に発見されることを期待していたのですが...

小林さん、報告ありがとうございます。

本来は私がするべき筈だったのですが、一昨日に京都へ出張があり、昨日も用
事ありで、ちょっとどたばたしていました。

＃ でもついでに、守岡さんに会うことができました。(^_^;

問題点は、小林さんに報告してもらった通りなのですが、個人的な欲望である
「添付ファイル名に日本語を使いたい！」というのは満たしています。

この方面で寂しい思いをしていた方は、お試しして頂けると助かります。

＃ 余談ですが、Unix/FreeBSD系のみなさんは、ファイル名の文字コードに何
＃ を使っていますか？ ファイル名に非ASCII文字を使わない、という選択は、
＃ そろそろつらくなっている気がするのですが…

-- 
----------------------------------------
KAWABATA, Taichi (batta ＠ beige.ocn.ne.jp)
----------------------------------------



From yoichi ＠ eken.phys.nagoya-u.ac.jp  Tue Jun 11 01:39:23 2002
From: yoichi ＠ eken.phys.nagoya-u.ac.jp (Yoichi NAKAYAMA)
Date: Tue, 11 Jun 2002 01:39:23 +0900
Subject: default value of mime-file-types in mime-edit.el
In-Reply-To: <htx7klbjx5y.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>
References: <wybsbveoes.wl@eken6.eken.phys.nagoya-u.ac.jp>
	<htx7klbjx5y.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <wy1ybf2imc.wl@eken3.eken.phys.nagoya-u.ac.jp>

なかやまです
解説ありがとうございます。その後ちょっと考えてみたのですが、

守岡さん> (b) に関していえば、text/* は人間が見るために改行や文字符号の変換が行
守岡さん> われる可能性があり、

ということで patch の場合には、text/* で添付するのは場合に
よっては不適切ですね。というわけで、デフォルトは今のままで
いいと思うようになりました。
-- 
Yoichi Nakayama
# application/octet-stream を問答無用ではじく設定にしちゃってる
# 某所がよろしくないんです…。



From yamaoka ＠ jpl.org  Tue Jun 11 09:22:08 2002
From: yamaoka ＠ jpl.org (Katsumi Yamaoka)
Date: Tue, 11 Jun 2002 09:22:08 +0900
Subject: default value of mime-file-types in mime-edit.el
References: <wybsbveoes.wl@eken6.eken.phys.nagoya-u.ac.jp>
	<htx7klbjx5y.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>
	<wy1ybf2imc.wl@eken3.eken.phys.nagoya-u.ac.jp>
Message-ID: <yotlvg8qr7ex.fsf@jpl.org>

>>>>> In [emacs-mime-ja : No.01034]
>>>>>	Yoichi NAKAYAMA <yoichi ＠ eken.phys.nagoya-u.ac.jp> wrote:

中山さん> 解説ありがとうございます。その後ちょっと考えてみたのですが、

守岡さん> (b) に関していえば、text/* は人間が見るために改行や文字符号
守岡さん> の変換が行われる可能性があり、

中山さん> ということで patch の場合には、text/* で添付するのは場合によっ
中山さん> ては不適切ですね。というわけで、デフォルトは今のままでいいと
中山さん> 思うようになりました。

ところで、Gnus では *.diff や *.patch という名前のファイルを添付
しようとすると text/x-patch になり、そういう記事を読む場合には
diff-mode でインライン表示するのがデフォルトです。ぼくはパッチを
自動で当てる度胸は無いのですが、個人的に「とりあえず見たい」ので、

(eval-after-load "mime-view"
  '(ctree-set-calist-strictly
    'mime-preview-condition
    '((type . text) (subtype . x-patch)
      (body . visible)
      (body-presentation-method . mime-display-text/plain))))

としています。でもなぜか、最近あまりお目にかかりませんが。
-- 
Katsumi Yamaoka <yamaoka ＠ jpl.org>