岡部＠京大です。

message/partial が簡単に decode できるようになったので、tm-comp.el
をいつも使うようにしようと思ったのですが、使いはじめてみるといろいろ
不満がでてきました。

・送信に失敗しても、なにごともなく終ってしまい、うまく送れたか
  どうか確認できない(バッファもなくなる)
・mh-letter-mode からの送信の場合、mh-send-letter が本来もつ
  機能である、prefix argument による切替えや、annotate の
  機能が使えなくなる。
・news-reply-mode の場合、nntp-server が open されていないと
  こける。これは gnus-post-news を単独に起動した場合や
  書いているうちに connection が切れた場合に困る。
・news-inews-hook や mh-before-send-letter-hook も効かない。
・分割後のメッセージのボディ部の先頭に、分割前のメッセージの
  ヘッダ部が入るが、そこに Fcc: や Dcc: が見えてかっこ悪い。

などの問題点がありました。そこでこれらを踏まえて大幅に改良して
みました。改良点のあらましは、

1、分割されないメッセージの場合には、mime/message-default-sender-alist
  に書かれた本来の関数(mh-letter-mode なら mh-send-letter)が呼ばれるよ
  うにした(これで tm-comp を標準設定にいれてしまってもほぼ問題ないと
  思います)。

2. 分割したメッセージをそれぞれ送る方法 mime/message-sender-alist とは
  別に、分割送信前と分割送信後にそれぞれ一回づつ実行される hook を
  書けるようにした。

3. mime/message-sender-alist に登録する method の初期値として、
  mh-send-letter および gnus-inews-news での機能をほぼとりこむ
  ようにした。

4. 一つの記事の行の制限を mime/message-default-max-length とし
  さらに、mode ごとの制限も mime/message-max-length-alist に
  書けるようにした。

5. MIME で書いた記事の preview のための関数として、
  mime/draft-preview というのを用意した(これはおまけ)。

などです。パッチをつくったらもとより大きくなってしまったので、
全体をお届けします。

＃ alist の中身が長くなりすぎたのですが、別の関数として独立させた
  方がいいでしょうか？