MIME-Edit, MIME-View file attachment

[Yoshiki Hayashi]

tomo ＠ etl.go.jp (守岡 知彦 / MORIOKA Tomohiko) writes:

> SEMI API 定義文書はとりあえず現在の構想では
> 
> 第１部 MUA 界面
> 第２部 method 界面および内部表現
> 第３部 利用者界面
> 第４部 標準 method
> 
> からなるものとし、具体的な挙動や見かけに関する規定は極力行わないように
> しようと思っています。

API の定義をお待ちしております。:-)

> ;; 個人的には SEMI および semi-* は私の安定版の私的枝に使いたいんです
> ;; が、公的枝化し、APEL に準じた運用を行った方が良いかなとも思っていま
> ;; す。API 開発・検証用実装には REMI を用いる予定です。

> MUA は要求する SEMI API の部と実装水準を持つあらゆる SEMI API の実装と
> 組合せ可能であることを目指します。このため、SEMI API の実装はどの部を
> どの水準まで実装したかを主張することにします。
> 
> このことにより、例えば林さんが SEMI API 第 1,3,4 部実装水準１を満たす
> 実行状況モデルを採用しない MIME UI 実装を作ることができます。で、EMH
> と cmail は実装水準１で動くとするとそれらを組み合わせることができると
> いう訳です。

ということは、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