[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6. 選択方法

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Select+Methods"
"gnus/選択方法"へのコメント(無し)

「外部グループ」(foreign group) とは、普通 (もしくはディフォルト) の方法 で読まれないグループのことです。例えばそれは別の NNTP サーバー のグループであったり、仮想グループであったり、個人的なメールグループであっ たりするでしょう。

外部グループ (あるいは実際にどんなグループでも) は「名前」と「選択方法」 で指定されます。先に後者を例に出すと、選択方法はリストで、最初の要素がど のバックエンドを使うか (例えば nntp, nnspool, nnml) を、二つめの要素が「サーバー名」を表します。選択方法には、 その当のバックエンドにとって特別の意味を持つ値である追加の要素があるかも しれません。

選択方法とは「仮想サーバー」を定義することだ、と言うことができます---で すから私たちはまさにそれをしました (see 節 6.1 サーバーバッファー)。

グループの「名前」は、バックエンドがそのグループを認識する名前です。

例えば `some.where.edu' という NNTP サーバーにあ る `soc.motss' グループは、名前 `soc.motss' と選択方 法 (nntp "some.where.edu") を持ちます。nntp バックエンドは このグループを `soc.motss' として知っているだけですが、Gnus はこの グループを `nntp+some.where.edu:soc.motss' と呼びます。

もちろん、違った方法はすべてそれ特有の要素を持っています。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.1 サーバーバッファー

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Server+Buffer"
"gnus/サーバーバッファー"へのコメント(無し)

伝統的に、「サーバー」は誰かがそれに接続して、それからの情報を要求するマ シンかソフトウェアの断片です。Gnus は実際のどんなサーバーにも直接には接 続せず、何かのバックエンドを通してすべての処理を行ないます。しかしそれは まさしく実際の媒体と Gnus の間に一つ以上の階層を置くことであって、ちょう どそれぞれのバックエンドが疑似的なサーバーに相当すると言っても良いでしょ う。

例えば nntp バックエンドは、複数の別々に実在す る NNTP サーバー、あるいは実在する同じ NNTP サーバー の異なるポートに接続するために用いられます。あなたはどのバックエンドを使 うか、そしてどんなパラメーターを設定するかを選択方 法 (select method) に設定して Gnus に指示します。

選択方法の指定は、ときに極めて面倒なものになります---えーと、例え ば `news.funet.fi' という NNTP サーバーのポート 13 を読み たいのだけれど、NOV ヘッダーを取り寄せようとすると固まってしま うし、間違った記事を選択してしまうような場合です。うおっほん。とにかくこ のサーバーを使うそれぞれのグループについてそういうことを設定しなければな らないとしたら、大変な作業になってしまうでしょう。そこで Gnus は、そうい う作業をサーバーバッファーで行なうために、選択方法に名前を付ける手段を設 けているのです。

サーバーバッファーに入るためには、グループバッファー で ^ (gnus-group-enter-server-mode) コマンドを使ってくださ い。

6.1.1 サーバーバッファーの表示様式   
6.1.2 サーバー命令   
6.1.3 方法の例   
6.1.4 仮想サーバーを作成する   
6.1.5 サーバー変数   
6.1.6 サーバーと選択方法   
6.1.7 使用不可能なサーバー   

サーバーバッファーを作成するときに gnus-server-mode-hook が実行さ れます。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.1.1 サーバーバッファーの表示様式

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Server+Buffer+Format"
"gnus/サーバーバッファーの表示様式"へのコメント(無し)

サーバーバッファーの行の外見を、変数 gnus-server-line-format 変数 を変更することによって変えることができます。これは format のよう な変数で、少しばかり単純な拡張がなされています:

`h'
どのようにニュースが取得されるか---バックエンドの名前。

`n'
サーバーの名前。

`w'
どこからニュースが取得されるか---アドレス。

`s'
サーバーの接続の 開いた/閉じた/拒否された 状態。

`a'
そのサーバーがエージェント化されているかどうか。

モード行も変数 gnus-server-mode-line-format を使うことによってカ スタマイズすることができます (see 節 9.4.2 モード行書法仕様)。

[訳注: 現在この変数は使われていません。]

以下の仕様が理解されます:

`S'
サーバー名。

`M'
サーバーの選択方法。

9.4 書法仕様変数 も参照してください。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.1.2 サーバー命令

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Server+Commands"
"gnus/サーバー命令"へのコメント(無し)

v
v キーはユーザー用に予約されています。そのまま何かのコマンドに割り 当てても構いませんが、接頭キーとして使う方が良いでしょう。

a
新しいサーバーを追加します (gnus-server-add-server)。

e
サーバーを編集します (gnus-server-edit-server)。

S
サーバーの定義を表示します (gnus-server-show-server)。

SPACE
現在のサーバーを眺めます (gnus-server-read-server)。

訳注: 実際には gnus-server-read-server-in-server-buffer 命令を呼 びますが、gnus-server-browse-in-group-buffer の値がディフォルト の nil であれば gnus-server-read-server と同じです。 gnus-server-browse-in-group-buffer を nil 以外の値にするこ とはまったくお勧めできませんが、あなたが何をするのも自由です。詳細はソー スコードを読むか、実際に試して痛い目に会ってください。;-p

q
グループバッファーに戻ります (gnus-server-exit)。

k
現在のサーバーを切り取ります (kill します) (gnus-server-kill-server)。

y
先ほど切られた (killed) サーバーを貼り付けます (yank します) (gnus-server-yank-server)。

c
現在のサーバーを複写します (gnus-server-copy-server)。

l
すべてのサーバーの一覧を表示します (gnus-server-list-servers)。

s
サーバーにそのソースから新しい記事を調べるように要求しま す (gnus-server-scan-server)。主にメールサーバーが意味のある動作 をします。

g
サーバーにすべてのデータ構造を再作成させま す (gnus-server-regenerate-server)。これは同期が外れてしまったメー ルバックエンドがあるときに役に立ちます。

z

現在位置のサーバーのすべてのグループを圧縮します。今のところ nnml (see 節 6.4.13.3 メールスプール) だけに実装されています。これは記事番号のすきまを取 り除くので、正しい全記事数を得ることができるようになります。

サーバーを閉じ、禁止し、および再開するための他のコマンドについて は 6.1.7 使用不可能なサーバー。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.1.3 方法の例

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Example+Methods"
"gnus/方法の例"へのコメント(無し)

ほとんどの選択方法は、説明する必要が無いくらいにかなり単純です:

  
(nntp "news.funet.fi")

直接スプールから読むのはもっと単純です:

  
(nnspool "")

見ての通り、選択方法の最初の要素はバックエンドの名前で、二番目は「アドレ ス」(address)、もしくはそう呼びたいのであれば「名前」です。

これらの二つの要素の後には、任意の数 の (変数 様式) の対を置くことができます。

最初の例に戻りましょう---そのマシンのポート 15 から読みたいのだと思って ください。これがその時に、そうなるはずの選択方法です:

  
(nntp "news.funet.fi" (nntp-port-number 15))

どの変数が関連するかを見つけ出すために、それぞれのバックエンドの説明文書 を読むべきでしょうが、これは nnmh の例です。

nnmh はスプールのような構造を読むためのメールバックエンドです。例 えばアクセスしたい二つの構造があるとしましょう: 一つはあなたの私的なメー ルスプールで、他方は公的なものです。これは私的なメールのために使うことが できる指定です:

  
(nnmh "private" (nnmh-directory "~/private/mail/"))

(それでこのサーバーは `private' と呼ばれますが、あなたはすでに推測 していたかもしれませんね。)

これは公的なスプールのための方法です:

  
(nnmh "public"
      (nnmh-directory "/usr/information/spool/")
      (nnmh-get-new-mail nil))

あなたが防壁 (firewall) の中にいて、防壁マシンを通して NNTP サー バーに接続するしかないのであれば、防壁マシンに rlogin して、そこ から netcat で NNTP サー バーに接続するように Gnus に指示することができます。こんなことをするのは いささかばかげているのですが、でも仮想サーバーの定義はおそらくこのような ものになるはずです:

  
(nntp "firewall"
      (nntp-open-connection-function nntp-open-via-rlogin-and-netcat)
      (nntp-via-address "the.firewall.machine")
      (nntp-address "the.real.nntp.host"))

あの素敵な ssh プログラムを、モデムを経由する通信を圧縮するために 使いたいのならば、上記の例に以下の設定を加えることができます。

  
      (nntp-via-rlogin-command "ssh")

nntp-via-rlogin-command-switches も参照してください。間接的に接続 する場合の例です:

  
(setq gnus-select-method
      '(nntp "indirect"
             (nntp-address "news.server.example")
             (nntp-via-user-name "intermediate_user_name")
             (nntp-via-address "intermediate.host.example")
             (nntp-via-rlogin-command "ssh")
             (nntp-via-rlogin-command-switches ("-C"))
             (nntp-open-connection-function nntp-open-via-rlogin-and-netcat)))

もちろん、自動認証を行なわせるためには ssh-agent を適切に設定しな ければなりません。

防壁の中にいたとしても "runsocks" のようなラッパーコマンドを通して外の世 界に直接アクセスできるのならば、以下のように socks 化された netcat でニュー スサーバーに接続することができるでしょう:

  
(nntp "outside"
      (nntp-pre-command "runsocks")
      (nntp-open-connection-function nntp-open-netcat-stream)
      (nntp-address "the.news.server"))


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.1.4 仮想サーバーを作成する

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Creating+a+Virtual+Server"
"gnus/仮想サーバーを作成する"へのコメント(無し)

永続記事を使ってたくさんの記事をキャッシュに保存しているのであれば、キャッ シュを読むための仮想サーバーを作る必要があるでしょう。

最初に新しいサーバーを追加する必要があります。それをするのは a 命 令です。おそらくキャッシュを読むためには nnml を使うのが一番良い でしょう。nnspool や nnmh も使えるでしょうれけど。

a nnml RET cache RET とタイプしてください。

今やあなたは真新しい `cache' という nnml の仮想サーバーを手 に入れたはずです。次はそれを編集して、正しい定義を与えましょう。サーバー を編集するには e をタイプしてください。あなたは以下のものを含むバッ ファーに入ります:

  
(nnml "cache")

それを次のように変更してください:

  
(nnml "cache"
      (nnml-directory "~/News/cache/")
      (nnml-active-file "~/News/cache/active"))

サーバーバッファーに戻るには C-c C-c をタイプしてください。今では この仮想サーバーで RET を押すと、閲覧バッファーに入って、表示され ているどのグループにでも入ることができるはずです。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.1.5 サーバー変数

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Server+Variables"
"gnus/サーバー変数"へのコメント(無し)

変数を (バックエンドと Emacs 一般の両方で) 定義する際の一つのやっかいな 点は、いくつかの変数は、概してその変数の定義がロードされるときに他の変数 で初期化されることです。「基」になる変数がロードされた後でそれを変更して も、「派生」した変数は変更されません。

これは一般にディレクトリーやファイルの変数に影響します。例え ば nnml-directory はディフォルトでは `~/Mail/' で、また、す べての nnml ディレクトリー変数はその変数によって初期化されるので、 nnml-active-file は `~/Mail/active' になります。新し い nnml 仮想サーバーを定義する場合、nnml-directory を設定 するだけでは十分では ありません---あなたはすべてのファイル変数を、 そうしたいと望んだ値に明示的に設定しなければなりません。それぞれのバック エンドのための完全な変数のリストを見るには、このマニュアルの後に続くそれ ぞれのバックエンドの部分を読んでください。でも nnml の定義の例は ここにあります:

  
(nnml "public"
      (nnml-directory "~/my-mail/")
      (nnml-active-file "~/my-mail/active")
      (nnml-newsgroups-file "~/my-mail/newsgroups"))

サーバー変数はしばしば「サーバーパラメーター」と呼ばれます。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.1.6 サーバーと選択方法

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Servers+and+Methods"
"gnus/サーバーと選択方法"へのコメント(無し)

普通に選択方法を使う (例えば外部サーバーから記事を読むときにグループを選 択する手段として gnus-secondary-select-method 使う) 場面ではどこ でも、代わりに仮想サーバーの名前を使うことができます。これによって、たく さんキーボードを叩かなくて済むかもしれません。そして、どんなときでもその 方が良いです。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.1.7 使用不可能なサーバー

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Unavailable+Servers"
"gnus/使用不可能なサーバー"へのコメント(無し)

あるサーバーに接続することができないように見えるとき、Gnus はそのサーバー に拒否された (denied) ことを記録します。その後でそのサーバーと接 続しようとするどんな試みも、単に無視されます。実際にそうかどうかを少しも 確かめずに、Gnus は「接続を開くことができません」と (英語で) 告げます。

それはずいぶんお行儀が悪いと思うかもしれませんが、たいていの場合は有意義 なのです。例えば `nephelococcdyia.com' というサーバーで十個のグルー プを購読しているとしましょう。サーバーはどこかとても遠いところにあって、 そのマシンはとても遅いので、今日それが接続を拒否するかどうかを調べるだけ でも一分かかります。もし Gnus がそれを十回試すようになっていたとすると、 とても煩わしいでしょう。ですから Gnus はそれを試そうとはしません。一度で も「接続が拒否された」(connection refused) という結果を受け取ったなら、 それはサーバーが「落ちている」(down) のだ、とみなします。

では、一時的にそのマシンの機嫌が悪いだけだったら何が起こるのでしょう? マ シンが復活したかどうかをどうすれば調べることができるのでしょう?

それには、サーバーバッファーに移動して (see 節 6.1 サーバーバッファー)、以下の命 令で突いてみてください:

O
現在の行のサーバーとの接続を確立しようとしま す (gnus-server-open-server)。

C
サーバーとの接続 (もしあれば) を閉じま す (gnus-server-close-server)。

D
現在のサーバーに接続不可の印を付けま す (gnus-server-open-all-server)。

M-o
バッファーにあるすべてのサーバーとの接続を開きま す (gnus-server-open-all-servers)。

M-c
バッファーにあるすべてのサーバーとの接続を閉じま す (gnus-server-close-all-servers)。

R
Gnus が接続を拒否されたすべてのサーバーの、すべての印を消去し ます (gnus-server-remove-denials)。

c
サーバーをコピーして新しい名前を付けま す (gnus-server-copy-server)。これは、複雑な接続方法の定義がすで にあって、それと同じ定義を異なる (物理) サーバーのために使う必要がある場 合に役立つはずです。

L
サーバーの状態をオフラインにします (gnus-server-offline-server)。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.2 ニュースの取得

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Getting+News"
"gnus/ニュースの取得"へのコメント(無し)

ニュースリーダーは普通はニュースを読むために使われます。Gnus は現在はニュー スを取得するための二つの方法だけを提供しています---NNTP サーバー から、またはローカルスプールから読むことができます。

6.2.1 NNTP    NNTP サーバーからニュースを読む
6.2.2 ニューススプール   


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.2.1 NNTP

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=NNTP"
"gnus/NNTP"へのコメント(無し)

NNTP サーバーから外部グループを購読するのは比較的簡単です。単 に選択方法として nntp を指定し、NNTP サーバーのアドレス を、うーん、アドレスとして指定するだけです。

NNTP サーバーが標準ではないポート (port) に設置されているとき は、選択方法の三番目の要素をこのポートの番号に設定すれば、正しいポートに 接続することができるでしょう。そのためにはグループ情報を編集しなければな りません (see 節 2.9 外部グループ)。

外部グループの名前は基本グループと同じでも構いません。実際、あなたの思う ままに同じグループを可能な限りの違ったサーバーから購読することができます。 名前の衝突は起こりません。

以下の変数は仮想 nntp サーバーを作るために使われます:

nntp-server-opened-hook
は接続ができた後に実行されます。それは NNTP サーバーに接続した 後に、それに命令を送るために使うことができます。ディフォルトで は MODE READER 命令が、nntp-send-mode-reader 関数によって サーバーに送られるようになっています。この関数は常にこのフックにあるべき です。

nntp-authinfo-function
この関数は NNTP サーバーに `AUTHINFO' を送るために使われ ます。ディフォルトの関数は nntp-send-authinfo で、適切な記載事項 を探すために `~/.authinfo' (もしくは nntp-authinfo-file 変数 に設定した何でも) を調べます。もし一つも見つからなかったら、ログイン名と パスワードの入力を要求します。`~/.authinfo' ファイルの様式 は ftp のための `~/.netrc' ファイルと (ほとんど) 同じです。 それは ftp のマニュアルページで定義されていますが、ここに顕著な実 例があります:

  1. ファイルは一つ以上の行を含み、それぞれは一つのサーバーを定義します。

  2. それぞれの行は任意の数の標章 (token) と値の対を含むことができます。

    有効な標章は `machine', `login', `password', `default' です。加えて、Gnus は `.netrc'/ftp の構文の原 型には現れない二つの新しい標章、名付けて `port' と `force' を 導入します。(これが `.authinfo' ファイルの様式が `.netrc' ファ イルの様式から逸脱する唯一の方法です。) `port' はサーバーのどのポー トを認証に用いるかを示し、`force' は以下で説明します。

これがそのファイルの例です:

  
machine news.uio.no login larsi password geheimnis
machine nntp.ifi.uio.no login larsi force yes

標章と値の対はどんな順番ででも現れることができます。例え ば `machine' が最初でなければならない必要はありません。

この例では、前者のサーバーにログイン名とパスワードの両方が与えられている のに対して、後者にはログイン名だけがあり、利用者はパスワードの入力を求め られるでしょう。後者は `force' タグも持っていて、これによって接続時 に nntp サーバーに認証情報 (authinfo) が送られます。ディフォル ト (すなわち、`force' タグが無いとき) では、nntp サーバーが認 証情報を尋ねない限りそれを nntp サーバーに送りません。

`machine' 行に合致しないすべてのサーバーに適用され る `default' 行を追加することもできます。

  
default force yes

これは、それ以前に書かれていないすべてのサーバーに `AUTHINFO' 命令 を強制的に送ります。

`~/.authinfo' ファイルを世界中が読めるような設定のままで放置しない ように注意してください。

nntp-server-action-alist
これはサーバーの型に合致する正規表現と、合致が起こったときに取られる動作 の連想リストです。例えば、Gnus に innd に接続したときに毎回ビープ音を鳴 らしたいのであれば、次のようにすることができます:

  
(setq nntp-server-action-list
      '(("innd" (ding))))

まぁ、そんなことをしたいとは思わないでしょうけれどね。

ディフォルトの値は

  
'(("nntpd 1\\.5\\.11t"
   (remove-hook 'nntp-server-opened-hook
                'nntp-send-mode-reader)))

で、これは nntpd 1.5.11t には MODE READER 命令を確実に送らないよ うにします。なぜなら、その命令はサーバーの息の根を止めると聞いているから です。

nntp-maximum-request
もし NNTP サーバーが NOV ヘッダーをサポートしていな いのであれば、このバックエンドは head 命令をいくつも送って、ヘッ ダーを集めます。この動作を速くするために、バックエンドは返答を待たずにこ の命令をたくさん送り、それからすべての返答を読みます。これは変 数 nntp-maximum-request によって制御され、ディフォルトで 400 です。 もしネットワークの具合が良くないようなら、この変数を 1 に設定するべきで しょう。

nntp-connection-timeout
定期的に接続している外部 nntp グループがたくさんあると、ちゃんと 応答しなかったり常識的な時間内に返答できないくらいの負荷がかかってい る NNTP サーバーの問題があるはずです。これはやっかいな問題をも たらしますが、nntp-connection-timeout を設定することによってある 程度解消することができます。これは接続を諦める前に、nntp バックエ ンドが何秒待つかを示す整数です。もしこれが nil であると、それがディ フォルトですが、時間切れによる切断は行ないません。

nntp-nov-is-evil
NNTP サーバーが NOV をサポートしていない場合は、この 変数を t に設定すれば良いでしょう。でも nntp は普通 は NOV が使えるかどうかを自動的に調べます。(訳注: ですから、わ ざわざ設定しなくても構いません。)

nntp-xover-commands
サーバーから NOV 行を取得するための命令として使われる文字列の リストです。この変数のディフォルトの値は ("XOVER" "XOVERVIEW") で す。(訳注: それらを順に試します。)

nntp-nov-gap
nntp は、普通はサーバーに NOV 行のための一つの大きな要 求を送ります。サーバーは一つの巨大な行のリストで応答します。しかし、グルー プの 2-5000 の記事を読んだ後で 1 と 5001 を読みたいだけだとしても、 nntp は必要の無い 4999 個の NOV 行を取得することになり ます。この変数は、どれくらい大きな二つの連続した記事群の間の隔た り (gap) まで XOVER の要求を分割せずに送るかを決定します。ネット ワークが速い場合に、この変数を本当に小さな数値に設定してしまうと、おそら く取得が遅くなることに注意してください。この変数が nil ならば、 nntp は要求を分割しません。ディフォルトは 5 です。

nntp-xref-number-is-evil
ユーザーが指定した Message-ID を持っている記事、または現在のもの の親記事の Message-ID を持っている記事を参照すると き (see 節 3.23 親記事を探す)、Gnus はそれがどこにあるかを知るため に NNTP サーバーに HEAD コマンドを送ります。そしてサー バーは、Xref ヘッダーにグループと記事番号の対を含んでいるデータを 返します。そのデータが、その記事が現在のグループにあることを示すなら、通 常 Gnus はその記事を参照するのに記事番号を使用します、そうでなけれ ば Message-ID を使いますが。ところが、あるニュースサーバー (例え ば Diablo を実行するもの) は、同じ記事群を有する複数のエンジンを運転して いて、それらの間では記事番号が同期されていません。その場 合 Xref ヘッダーに現われる記事番号は、どのエンジンが選ばれるかに よって変化するので、例えば現在のグループにある親記事を参照することができ ません。そのようなサーバーに接続するのであれば、この変数を nil で はない値に設定してください。そうすれば Gnus は記事番号を使いません。例え ば:

  
(setq gnus-select-method
      '(nntp "newszilla"
             (nntp-address "newszilla.example.com")
             (nntp-xref-number-is-evil t)
             ...))

このサーバー変数のディフォルト値は nil です。

nntp-prepare-server-hook
NNTP サーバーに接続を試みる前に実行するフックです。

nntp-record-commands
これを nil でない値にすると、nntp は NNTP サーバー に送ったすべての命令を (時刻と共に) `*nntp-log*' バッファーに記録し ます。これは動作していないように見える Gnus の NNTP 接続をデバッ グしているときに役に立ちます。

nntp-open-connection-function
どのように NNTP サーバーと接続するかをカスタマイズすることがで きます。nntp-open-connection-function パラメーターを設定しておく と、Gnus は接続を確立するためにその関数を使います。そのために七つの関数 があらかじめ用意されています。それらは二種類に分類することができ、直接接 続するための関数群 (四つ) と間接的に接続するためのもの (三つ) があります。

nntp-never-echoes-commands
非-nil で NNTP サーバーがコマンドをエコーバックしないこ とを意味します。報告によると、ある種の NNTPS サーバーはコマン ドをエコーバックしないそうです。したがって、例え ば nntp-open-connection-function を nntp-open-ssl-stream に 設定してあるそのようなサーバーのための選択方法の中で、この変数を 非-nil に設定する必要があるでしょう。ディフォルト値 は nil です。この変数の値 nil は、 nntp-open-connection-functions-never-echo-commands 変数でくつがえ されることに注意してください。

nntp-open-connection-functions-never-echo-commands
コマンドをエコーバックしない関数のリストです。 nntp-open-connection-function に設定した関数がコマンドをエコーバッ クしないならば、それをこのリストに加えてください。 nntp-never-echoes-commands 変数の nil でない値が、この変数 をくつがえすことに注意してください。ディフォルト値 は (nntp-open-network-stream) です。

nntp-prepare-post-hook
記事を投稿する直前に実行されるフックです。もし記事 に Message-ID ヘッダーが無くてニュースサーバーが推奨 ID を提供し てくれるならば、このフックが実行される前にそれが記事に加えられます。これ は、もしあなたが Gnus が Message-ID ヘッダーを付けないようにして いても、Cancel-Lock ヘッダーを作るために利用することができます。 それにはこうすれば良いでしょう:

  
(add-hook 'nntp-prepare-post-hook 'canlock-insert-header)

すべてのサーバーが推奨 ID をサポートしているわけではないことに注意してく ださい。これは例えば INN 2.3.0 以上で動作します。

nntp-server-list-active-group
もし nil だったら `LIST ACTIVE' の代わりに常 に `GROUP' を使います。これは普通遅いのですが、誤って active ファイ ルを頻繁に更新しないように設定されているサーバーでは助けになるはずです。

6.2.1.1 直接接続するための関数   
6.2.1.2 間接的に接続するための関数   
6.2.1.3 共通の変数   


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.2.1.1 直接接続するための関数

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Direct+Functions"
"gnus/直接接続するための関数"へのコメント(無し)

これらの関数は、あなたのマシンと NNTP サーバーを接続するために 直接呼ばれます。また、それらの動作はそれらが共通に参照する変数に影響され ます (see 節 6.2.1.3 共通の変数)。

nntp-open-network-stream
これはディフォルトで、単純に遠隔システムのポートもしくは別のものに接続し ます。もし Emacs とサーバーの両方がサポートしていれば、その接続は自動的 に暗号化された STARTTLS 接続に昇格されます。

network-only
上記に同じ。ただし自動で STARTTLS への昇格は行ないません。

nntp-open-tls-stream
「安全な」チャンネルを使ってサーバーに接続します。これを使うために は GnuTLS をインストールして おかなければなりません。それからサーバーを次のように定義します:

  
;; ポート 563 が "nntps" として `/etc/services' で定義済み
;; であっても、`gnutls-cli -p' でその名前は使えません。
;;
(nntp "snews.bar.com"
      (nntp-open-connection-function nntp-open-tls-stream)
      (nntp-port-number 563)
      (nntp-address "snews.bar.com"))

nntp-open-ssl-stream
「安全な」チャンネルを使ってサーバーに接続します。これを使うために は OpenSSL また は SSLeay をインストールし ておかなければなりません。それからサーバーを次のように定義します:

  
;; ポート 563 が "snews" として `/etc/services' で定義済みで
;; あっても、`openssl s_client -port' でその名前は使えません。
;;
(nntp "snews.bar.com"
      (nntp-open-connection-function nntp-open-ssl-stream)
      (nntp-port-number 563)
      (nntp-address "snews.bar.com"))

nntp-open-netcat-stream
netcat コマンドを使って NNTP サーバーに接続します。ディ フォルトの nntp-open-network-stream がそれをするのにもかかわらず、 なぜこの関数があるのか不思議に思うかもしれません。その理由 (の一つ) は、 もしあなたが防壁の中にいたとしても runsocks のようなコマンドラッ パーのおかげで外の世界を直接アクセスできるならば、それをこのように使うこ とができるのです:

  
(nntp "socksified"
      (nntp-pre-command "runsocks")
      (nntp-open-connection-function nntp-open-netcat-stream)
      (nntp-address "the.news.server"))

ディフォルトのメソッドのままでそれを行なうには Emacs のセッション全体を ラップする必要があるでしょうが、それは良い考えではありません。

nntp-open-telnet-stream
nntp-open-netcat-stream に似ていますが、netcat ではな くて telnet を使います。行末コードを変更したりするの で telnet はいささか堅実さに欠けるのですが、netcat が無い 場合もあります。前の例はこのように書き換えられるでしょう:

  
(nntp "socksified"
      (nntp-pre-command "runsocks")
      (nntp-open-connection-function nntp-open-telnet-stream)
      (nntp-address "the.news.server")
      (nntp-end-of-line "\n"))


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.2.1.2 間接的に接続するための関数

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Indirect+Functions"
"gnus/間接的に接続するための関数"へのコメント(無し)

これらの関数は、実際に NNTP サーバーに接続する前に中間のホスト に接続するために間接的に呼ばれます。すべてのこれらの関数と関連する変数は “via”接続の仲間に属しているとも言えるので、それを明確にするためにすべ て“via”という接頭語が付けられます。また、それらの動作はそれらが共通に 参照する変数に影響されます (see 節 6.2.1.3 共通の変数)。

nntp-open-via-rlogin-and-netcat
遠隔システムに `rlogin' して、そこから本当の NNTP サーバー に接続するために netcat を使います。これは、例えばあなたが始めに 防壁マシンに接続しなければならない場合に便利です。

nntp-open-via-rlogin-and-netcat-用の変数:

nntp-via-rlogin-command
中間のホストにログインするために使われるコマンドです。ディフォルト は `rsh' ですが、`ssh' が人気のある代替手段です。

nntp-via-rlogin-command-switches
nntp-via-rlogin-command のコマンドのスイッチとして使われる文字列 のリストです。ディフォルトは nil です。も し `ssh' を nntp-via-rlogin-command の値として使うならば、す べてのデータ接続を圧縮するために `("-C")' を使うことができます。

nntp-open-via-rlogin-and-telnet
本質的には同じことなのですが、中間のホストから本当の NNTP サー バーに接続するために、`netcat' の代わりに telnet を使います。 行末コードを変更したりするので telnet はいささか堅実さに欠けるの ですが、netcat が無い場合もあるでしょう。

nntp-open-via-rlogin-and-telnet-用の変数:

nntp-telnet-command
中間のホストから本当の NNTP サーバーに接続するために使われるコ マンドです。ディフォルトは `telnet' です。

nntp-telnet-switches
nntp-telnet-command のコマンドのスイッチとして使われる文字列のリ ストです。ディフォルトは ("-8") です。

nntp-via-rlogin-command
中間のホストにログインするために使われるコマンドです。ディフォルト は `rsh' ですが、`ssh' が人気のある代替手段です。

nntp-via-rlogin-command-switches
nntp-via-rlogin-command のコマンドのスイッチとして使われる文字列 のリストです。`ssh' を使う場合に、もし中間のホストで telnet コマン ドが疑似端末を必要とするならば、これを `("-t" "-e" "none")' また は @samp {("-C" "-t" "-e" "none")} にする必要があるでしょう。ディフォル トは nil です。

nntp-end-of-line の値を `\n' に変更する必要があるであろうこ とに注意してください (see 節 6.2.1.3 共通の変数)。

nntp-open-via-telnet-and-telnet
これもまた本質的には同じことなのですが、中間のホストに接続するため に `rlogin' の代わりに `telnet' を使います。

nntp-open-via-telnet-and-telnet-用の変数:

nntp-via-telnet-command
中間のホストに telnet するために使われるコマンドです。ディフォル トは `telnet' です。

nntp-via-telnet-switches
nntp-via-telnet-command のコマンドのスイッチとして使われる文字列 のリストです。ディフォルトは `("-8")' です。

nntp-via-user-password
中間のホストにログインするときに使われるパスワードです。

nntp-via-envuser
もし非-nil なら、中間の telnet のセッション (クライアント とサーバーの両方) で ENVIRON オプションをサポートし、ログイン名の 入力を要求しません。これは例えば Solaris の telnet で動作します。

nntp-via-shell-prompt
中間のホストでのシェルのプロンプトに合致する正規表現です。ディフォルト は `bash\\|\$ *\r?$\\|> *\r?' です。

nntp-end-of-line の値を `\n' に変更する必要があるであろうこ とに注意してください (see 節 6.2.1.3 共通の変数)。

これらは上記のすべての関数が参照する付加的な変数です:

nntp-via-user-name
中間のホストに接続するときに使う利用者名です。

nntp-via-address
接続する中間のホストのアドレスです。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.2.1.3 共通の変数

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Common+Variables"
"gnus/共通の変数"へのコメント(無し)

以下の変数は、すべての、またはいくつかのあらかじめ用意されている関数の動 作に影響を及ぼします。設定されていなければ、すべての関数が影響されま す (それぞれの仮想サーバーにおいて、サーバー変数として個々に値が設定され ていない場合に、以下の値がディフォルトで使われます)。

nntp-pre-command
素の接続用の関数ではないも の (nntp-open-network-stream、nntp-open-tls-stream また は nntp-open-ssl-stream 以外のすべて) を通して接続するときに使う コマンドラッパーです。例えばあなたは `SOCKS' ラッパーを割り当てるで しょう。(訳注: telnet などの外部コマンドに被せて使われます。)

nntp-address
NNTP サーバーのアドレスです。

nntp-port-number
接続する NNTP サーバーのポート番号です。ディフォルト は `nntp' です。TLS/SSL を介し た NNTP を使うには、ポートの名前ではなくて整数 (つま り `snews' や `nntps' ではなくて `563') を指定する必要が あります。外部の TLS/SSL ツールはポートの名前では動 作しないからです。

nntp-end-of-line
NNTP サーバーとお話をしているときに行の終わりの印として使われ る文字列です。これはディフォルトで `\r\n' ですが、素ではない接続用 の telnet 同等の関数を使っているときは `\n' であるべきです。

nntp-netcat-command
`netcat' を通して NNTP サーバーと接続するときに使うコマン ドです。これは中間のホストと接続するためのものでは ありません。こ れはまさに本当の NNTP サーバーと接続するためのものです。ディフォ ルトは `nc' です。

nntp-netcat-switches
nntp-netcat-command に渡すスイッチのリストです。ディフォルト は `()' です。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.2.2 ニューススプール

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=News+Spool"
"gnus/ニューススプール"へのコメント(無し)

ローカルスプールから外部グループを購読することは極めて簡単だし便利かもし れません。非常に大きな記事があるグループ---例え ば `alt.binaries.pictures.furniture' を読む速度が速くなります。

とにかく、nnspool を選択方法として、かつ "" (もしくは何で も) をアドレスとして指定するだけです。

もしローカルスプールにつなぐことが可能なら、おそらくそれを基本選択方法と して使うべきでしょう (see 節 1.1 ニュースを見つける)。それは普通 は nntp 選択方法を使うより速いですが、そうでないかもしれません。 それは場合によります。何があなたのサイトで一番良いかを見つけるために、い ろいろと試してみなければなりません。

nnspool-inews-program
記事を投稿するために使われるプログラムです。

nnspool-inews-switches
記事を投稿するときに inews プログラムに与えられるパラメーターです。

nnspool-spool-directory
nnspool が記事を探すところです。これは普通 は `/usr/spool/news/' です。

nnspool-nov-directory
nnspool が NOV ファイルを探すところです。これは普通 は `/usr/spool/news/over.view/' です。

nnspool-lib-dir
ニュースのライブラリーが置かれているディレクトリーの場所です (ディフォル トで `/usr/lib/news/' です)。

nnspool-active-file
アクティブファイルの絶対パス名です。

nnspool-newsgroups-file
`newsgroups' ファイルの絶対パス名です。

nnspool-history-file
`history' ファイルの絶対パス名です。

nnspool-active-times-file
`active.times' ファイルの絶対パス名です。

nnspool-nov-is-evil
nil でないと、nnspool はそれが見つけたどん な NOV ファイルも使おうとはしません。

nnspool-sift-nov-with-sed
nil でないと、これがディフォルトですが、概観ファイ ル (overview) から関連する部分を得るために sed を使います。も し nil だと、nnspool はファイル全体をバッファーに読み込ん で、そこで実行します。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.3 IMAP を使う

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Using+IMAP"
"gnus/IMAPを使う"へのコメント(無し)

おそらく最も人気があるメール・バックエンドは nnimap です。それ は IMAP サーバーに接続します。IMAP サーバーはメール をサーバーに格納するので、クライアントは何もローカルに格納しません。もし、 いろいろな場所から、またはいろいろなユーザー・エージェントでメールを読ん でいるのであれば、それは便利な選択だと言えます。

6.3.1 IMAP サーバーに接続する    IMAP を始める
6.3.2 IMAP 接続をカスタマイズする    IMAP 接続のための変数
6.3.3 クライアント側での IMAP 分割    正しいメールボックスにメールを置く


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.3.1 IMAP サーバーに接続する

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Connecting+to+an+IMAP+Server"
"gnus/IMAPサーバーに接続する"へのコメント(無し)

IMAP サーバーへの接続はとても簡単なはずです。グループバッファー で B を叩くか、または (もしあなたの第一の関心事がメールを読むこと であるなら) 以下のようなことをしてください:

  
(setq gnus-select-method
      '(nnimap "imap.gmail.com"))

ユーザー名とパスワードを尋ねられます。それに飽きたなら、以下のもの を `~/.authinfo' ファイルに加えてください:

  
machine imap.gmail.com login  password  port imap

ほとんどのユーザーには、それだけで良いはずです。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.3.2 IMAP 接続をカスタマイズする

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Customizing+the+IMAP+Connection"
"gnus/IMAP接続をカスタマイズする"へのコメント(無し)

もっと複雑な接続方法の例:

  
(nnimap "imap.gmail.com"
        (nnimap-inbox "INBOX")
        (nnimap-split-methods default)
        (nnimap-expunge t)
        (nnimap-stream ssl))

nnimap-address
サーバーのアドレスです。`imap.gmail.com' のようなもの。

nnimap-server-port
サーバーのポートが標準とは異なるなら、ここで設定できます。代表的なポート は "imap" あるいは "imaps" でしょう。

nnimap-stream
nnimap がどうやってサーバーに接続するかを指定します。使える値は:

undecided
これがディフォルトです。最初に ssl 設定を、次に network 設 定を試します。

ssl
標準の TLS/SSL 接続を使います。

network
暗号化されないので安全ではない、ストレートなソケット接続です。しかし、も し Emacs とサーバーの両方がサポートしていれば、暗号化され た STARTTLS 接続に昇格します。

starttls
正規の IMAP ポート上で暗号化された STARTTLS を使いま す。

shell
もしサーバーに接続するために他のホストをトンネルする必要があるなら、この オプションを使って nnimap-shell-program を必要に応じてカスタマイ ズすることができます。

nnimap-authenticator
いくつかの IMAP サーバーは匿名ログインを許容しています。その場 合、これを anonymous に設定する必要があります。

nnimap-expunge
もし nil でなければ、記事を消去した後でそれらを永久に取り除きます。 これはサーバーに UID EXPUNGE の機能があれば常に実行されますが、ディフォ ルトではサーバーにそのコマンドが無ければ実行しません。

nnimap-streaming
事実上すべての IMAP サーバーはデータの高速ストリーミングをサポー トしています。もしサーバーへの接続に問題があるのなら、これ を nil に設定してみてください。

nnimap-fetch-partial-articles
もし nil 以外の値だったら、サーバーから記事の部分を取り込みます。 もし文字列が設定されていたら、それは正規表現であると解釈され、そのタイプ が合致する部分が取り込まれます。例えば `"text/"' 場合はすべてのテキ スト型の部分を取り込みますが、残りはサーバーに置いたままになります。

nnimap-record-commands
もし nil でなければ、すべての IMAP コマンド を `"*imap log*"' バッファーに記録します。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.3.3 クライアント側での IMAP 分割

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Client%2DSide+IMAP+Splitting"
"gnus/クライアント側でのIMAP分割"へのコメント(無し)

多くの人々が、メールを IMAP サーバー上のそれぞれのメールボック スに並び換え/分割することを好みます。そうすれば、さほど関心が無いメール をダウンロードする必要がありません。

もしクライアント側でメール分割をする必要があるのなら、関連する変数は次の 通りです:

nnimap-inbox
新着メールが調べられる IMAP メールボックスです。これはメールボッ クス名のリストでもかまいません。

nnimap-split-methods
nnmail-split-methods と同じ構文を使います (see 節 6.4.3 メールの分割)。ただし default というシンボルである場合は例外で、 nnmail-split-methods の値を使います。

nnimap-split-fancy
nnmail-split-fancy と同じ構文を使います。

nnimap-unsplittable-articles
分割を行なっているときに無視すべきフラグのシンボルのリスト。すなわち、そ れらのフラグをもっている記事は、分割を行なう対象として考慮されないという ことです。ディフルトは `(%Deleted %Seen)' です。

以下は、クライアント側で "特級" メール分割を行なう nnimap バッ クエンドの完全な例です:

  
(nnimap "imap.example.com"
        (nnimap-inbox "INBOX")
        (nnimap-split-methods
         (| ("MailScanner-SpamCheck" "spam" "spam.detected")
            (to "[email protected]" "foo")
            "undecided")))


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.4 メール取得

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Getting+Mail"
"gnus/メール取得"へのコメント(無し)

ニュースリーダーでメールを読むなんて実に奇妙ですよね? いや、もちろんで きるのですが。

6.4.1 ニュースリーダーでメール   
6.4.2 メールを読むことを始める   
6.4.3 メールの分割   
6.4.4 メールソース    どこからメールを取ってくるかを Gnus に知らせる方法
6.4.5 メールバックエンド変数   
6.4.6 特級メール分割    Gnus は入って来たメールを、身の毛のよだつような分割をすることができる
6.4.7 グループメール分割   
6.4.8 古いメールを取り込む   
6.4.9 メールの期限切れ消去   
6.4.10 メール洗濯   
6.4.11 重複   
6.4.12 メールを読むのではない   
6.4.13 メールバックエンドを選ぶ    Gnus は色々なメール様式を読むことができる


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.4.1 ニュースリーダーでメール

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Mail+in+a+Newsreader"
"gnus/ニュースリーダーでメール"へのコメント(無し)

使い慣れた伝統的なメールリーダーから Gnus に乗り換えることを決断したなら ば、かなりのカルチャーショックを経験することになるでしょう。

Gnus は伝統的なメールリーダーのようなふるまいをしません。あなたが望むな らそのようにもできますが、それは骨折り損のくたびれ儲けです。

Gnus はふつう同じ手法ですべてのグループを扱います。あるグループを選んで 新しい、または未読のメッセージを読むと、それらには既読の印が付けられ、 (意図的に要求しなければ) 以後はそれらを目にすることはありません。これっ てとてもニュースリーダー的でしょ。

メッセージを消すために、取り立てて何かを行なうことはありません。

このことは既読のメッセージはすべて消されてしまうことを意味するのかっ て? そりゃあんまりですよね!

しかし、そうではありません。古いメッセージは何らかの仕組みによって期限切 れ消去 (expire) されるのです。ニュースのメッセージはニュースの管理 人 (が管理しているサーバー) によって期限切れ消去の処理が制御され、メール の期限切れ消去の処理はあなたが制御します。メールの期限切れ消去については、 6.4.9 メールの期限切れ消去 で徹底的に網羅されています。

多くの Gnus の利用者が、それをニュースとメールの両方でしばらく使ってみた 後で気が付くのは、その配送の機構がメッセージの扱い方に関して行なうことが、 ほんの少ししか無いことです。

多くの人たちが複数のメーリングリストを講読しています。それら は SMTP で配送されるもの、すなわちメールです。それらのメッセー ジに返答をしないまま、あるいはさらに、それらを非常に注意深くは読まないま まに、私たちは何週間も過ごすかもしれません。でも、そういうメッセージを保 存しておく必要はありません。なぜならば、もう一度読む必要が生じたとしても、 それらはどこかに保存されているからです。

ある人たちは小人数に利用されているローカルニュースグループを講読していま す。それらは NNTP で配送されるもの、すなわちニュースです。私た ちは自分の仕事に役立てるために、それらの膨大なメッセージの断片を読んだり 返事をしなければなりません。しかもそれらがどこかに保存されているとは限ら ないので、興味のあるメッセージを個人メールと同じように保存しなければなり ません。

配送の仕組みの違いはどうでもよいことで、大事なのはいかに主題に興味を持っ ているかと、もう一度読みたいときにいかに簡単に呼び出せるかなのです。

Gnus はメールをニュースグループのように「グループ」に並べ変えて、各々の グループ (メールかニュース) を別個に扱うための豊富な機能を提供します。

ある人たちは Gnus (えっへん) のやりかたに満足できなくて、Gnus が 男 (male) になること、もとい、メールリーダーになることを欲します。 Gnus をもっとメールリーダー的なものにするために鞭打つことは可能ではある のですが、前にも言ったように簡単ではありません。いわゆるメールリーダーが 好みならば VM を使いましょう。これは優秀な、厳密な意味でのメールリー ダーです。

脅かすわけではないのですが、はっきりさせておきたいのは、あなたにメッセー ジについての新しいやり方を修得して欲しいということです。あなたが Gnus の やり方を受け入れてくれた暁には、きっとあなたは Gnus が好きになるでしょう。 請け合いますよ。(少くとも、私が Gnus に入れた Emacs のサブリミナル脳味噌 洗濯関数を売ってくれた人はそれを保証しています。あなたも同化します。あな たは Gnus を愛します。あなたは Gnus でのメールの方法を愛します。絶対に。)


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.4.2 メールを読むことを始める

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Getting+Started+Reading+Mail"
"gnus/メールを読むことを始める"へのコメント(無し)

Gnus を使って新しいメールを読むことはまったく簡単です。あなたが選んだメー ルバックエンドを gnus-secondary-select-methods に放り込むだけで、 自動的に読むことができるようになります。

例えば nnml (これは「一メールにつき一ファイル」のバックエンドで す) を使いたいなら、次のものを `~/.gnus.el' ファイルに入れれば良い でしょう:

  
(setq gnus-secondary-select-methods '((nnml "")))

そうすると、次に Gnus を起動したときにこのバックエンドは新しい記事を求め、 すべてのメッセージをスプールファイルからそのディレクトリー (ディフォルト では `~/Mail/') に移します。新しいグループ (`mail.misc') が作 られて、他のグループと同じように読むことができるようになります。

たぶんメールをいくつかのグループに分割したいでしょうけれど:

  
(setq nnmail-split-methods
      '(("junk" "^From:.*Lars Ingebrigtsen")
        ("crazy" "^Subject:.*die\\^Organization:.*flabby")
        ("other" "")))

これは三つの新しい nnml メールグループ `nnml:junk', `nnml:crazy' および `nnml:other' を作ることになります。初めの 二つのグループにふさわしくないすべてのメールは、最後のグループに置かれま す。

Gnus でメールを読むにはこれで十分なはずです。マニュアルのこの部分の他の 章を熟読する必要があるかもしれませんが。特に 6.4.13 メールバックエンドを選ぶ と 6.4.9 メールの期限切れ消去 を。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.4.3 メールの分割

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Splitting+Mail"
"gnus/メールの分割"へのコメント(無し)

訳注: このマニュアルの多方面で使われている「分割」という語のうち、受信し たメールをいろいろなグループに「区分け」することを意味するもの は“split”という語に対応します。ある一つのメールを「分解」するのではな くて、外からやって来た複数のメールをそれぞれの格納先に一通ずつ「振り分け る」意味で使っています。

変数 nnmail-split-methods は入ってくるメールをどのようにグループ 分けするかを指定します。

  
(setq nnmail-split-methods
  '(("mail.junk" "^From:.*Lars Ingebrigtsen")
    ("mail.crazy" "^Subject:.*die\\|^Organization:.*flabby")
    ("mail.other" "")))

この変数はリストのリストで、それぞれのリストの最初の要素はメールグループ の名前、二つめの要素はそれぞれのメールがそのグループに属するかどうかをヘッ ダーで判定するために使う正規表現です (ところで、メールグループの名前 が `mail' で始まる必要はありません)。最初の文字列は、 replace-match が合致した文章から取り出した副表現を挿入するために 使われるような、`\\1' の様式を含むかもしれません。例えば:

  
("list.\\1" "From:.* \\(.*\\)[email protected]")

この場合、挿入されるテキストを小文字にすべきかどうか を nnmail-split-lowercase-expanded が制御します。See 節 6.4.6 特級メール分割.

二番目の要素は関数でも構いません。その場合、それは規則の最初の要素 (メー ルグループの名前) を引数として、ヘッダーだけに範囲を狭められたバッファー で呼ばれます。メールがそのグループに属すると判断したら、その関数 は nil でない値を返す必要があります。

これらのグループの最後は常に総合的なものであるべきで、その正規表現は他の 正規表現に合致しなかったメールに合致するために、 いつも `""' でなければなりません。(これらの規則は連想リスト の初めから終わりまで順番に処理されます。クロスポストを有効にしていない限 り、最初に合致した規則が「勝ち」ます。クロスポストを有効にしている場合は、 すべての合致した規則が「勝ち」ます。) 合致する規則がなかったら、メール は最後に `bogus' グループで終わります。メール分割によって新しいグルー プが作られた場合は、それらを見るため に gnus-group-find-new-groups を実行する必要があるでしょう。これ は `bogus' グループにも当てはまります。

あなた自身でこれをいじくりまわしたいときは、あなたの選んだ関数をこの変数 に設定することができます。この関数は入って来たメールメッセージのヘッダー に範囲を狭められたバッファーで、引数無しで呼ばれます。この関数は、そのメー ルメッセージをが行くべきだと判断するグループ名のリストを返さなければなり ません。

この変数は特級メール分割であっても良いです。構文については See 節 6.4.6 特級メール分割.

すべてのメールバックエンドは、入って来た気の毒な無実のヘッダーを乱暴に扱っ ても良いことに注意してください。それらはすべて Lines ヘッダーを追 加します。いくつかは X-Gnus-Group ヘッダーを加えます。たいていの ものは Unix の mbox の From 行を何か別のものに変えます。

すべてのメールバックエンドはクロスポストをサポートします。複数の正規表現 が合致すると、メールはそれらすべてのグループに「クロスポスト」されます。 nnmail-crosspost はこの機能を使うかどうかを指定します。どの記事も 総合の (`""') グループにクロスポストされないことに注意してください。

nnmh と nnml はクロスポストされた記事にハードリン ク (hardlink) を作ることによってクロスポストを行ないます。しかし、すべて のファイルシステムがハードリンクの機能を提供しているわけではありません。 もしあなたがその場合に当てはまるのであれば、 nnmail-crosspost-link-function を copy-file に設定してくだ さい。(この変数はディフォルトで add-name-to-file です。)

以前に行なわれたメール分割がメッセージをどこに入れたかを見たい場合は、 M-x nnmail-split-history 命令を使ってください。これからスプールし 直そうとするメッセージがどこに入るかを見たい場合は、 gnus-summary-respool-trace および関連する命令 (see 節 3.26 メールグループ命令) を使ってください。

nnmail-split-header-length-limit の制限より長いヘッダー行は、分割 関数の処理対象から除外されます。

ディフォルトでは分割の処理においてヘッダーを MIME デコードしな いので、非-ASCII 文字列に合致させることができません。しかし、 生のヘッダーのデータを元に記事の合致を判定したい場合には役立つでしょう。 それを可能にするには nnmail-mail-splitting-decodes 変数 を nil ではない値に設定してください。加え て nnmail-mail-splitting-decodes が nil ではない場合に、 nnmail-mail-splitting-charset 変数の値が MIME ではない エンコードされた文字列 (訳注: iso-2022-jp でエンコードされた生の データなど) をデコードするために使われます。ディフォルトは nil で、 MIME ではないエンコードされた文字列をデコードしません。あなた にとって好都合な値はおそらく undecided か、またはあなたが興味があ るメールで通常使われている文字セット (訳注: 実際は coding system) になる でしょう。

ディフォルトでは入ってくるすべてのメッセージに対して分割の処理が行なわれ ます。しかし、もし mail-sources 変数 (see 節 6.4.4.1 メールソース指示子) に directory の項目を設定すると、ディフォルトでは分 割は 行なわれません。変 数 nnmail-resplit-incoming を nil ではない値に設定すれば、 この場合でも分割を起こさせることができます。(この変数は他の種類の項目に 対しては効果がありません。)

Gnus はあなた自身に災いが及ぶ可能性あっても、あなたが望むすべての機会を 提供します。例えば、あなたの上司からくるすべてのメールを入れるグループを 作ったとしましょう。その後、偶発的にそのグループの購読をやめてしまうとど うなるでしょう。それでも Gnus は上司からのすべてのメールを未購読のグルー プに入れるので、上司が「月曜日までにその報告書を準備しないと首だ!」とい うメールをあなたに送っても、あなたはそれを見ることはなく、火曜日になって 本当は翌月の家賃を払うために空のボトルを集めるべきであっても、まだ有給で 雇われていると信じているかもしれません。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.4.4 メールソース

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Mail+Sources"
"gnus/メールソース"へのコメント(無し)

メールはたくさんの別のソース (source) から取得することができます---例え ばメールスプールから、POP メールサーバーから、procmail ディレ クトリーから、maildir から。

6.4.4.1 メールソース指示子   
6.4.4.3 メールソースのカスタマイズ   
6.4.4.4 メールの取得   


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.4.4.1 メールソース指示子

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Mail+Source+Specifiers"
"gnus/メールソース指示子"へのコメント(無し)

「メールソース指示子」に メールソース (see 節 6.4.4.4 メールの取得) を 設定して、Gnus にメールを取得する方法を指示しましょう。

例です:

  
(pop :server "pop3.mailserver.com" :user "myname")

ご覧のように、メールソース指示子はリストで、最初の要素は「メールソースの 型」、それに任意の数の「キーワード」が続きます。明示的に指定されていない キーワードはディフォルト値になります。

mail-sources はすべてのグループに対して共通です。しかし特定のグルー プのために、mail-sources に group メールソース指示子を持た せて、かつ単一のメールソースを指定する mail-source グループパラメー ター (see 節 2.10 グループパラメーター) を設定することによって、メールソースを追 加することができます。これを使う場合の mail-sources は、一般には 単なる (group) です。そしてグループのための mail-source パ ラメーターはこのようなものになるでしょう:

  
(mail-source . (file :path "home/user/spools/foo.spool"))

これは、そのグループは (このグループだけは) メッセージをスプールファイ ル `/user/spools/foo.spool' から取得することを意味します。

以下のメールソースの型が使用可能です:

file
単一のファイルからメールを取得します。普通はメールスプールです。

キーワード:

:path
ファイルの名前です。ディフォルトは MAIL 環境変数の値 か rmail-spool-directory の値 (普通 は `usr-mail/spool/user-name' のようなもの) です。

:prescript
:postscript
それぞれのメールを取得する前と後で実行するスクリプトです。

ファイルメールソースの例:

  
(file :path "/usr/spool/mail/user-name")

もしくは、ディフォルトのファイル名を使うと:

  
(file)

メールスプールファイルがローカルマシンに無い場合は、 POP や IMAP などでメールを取得するのが最善です。ここ では ange-ftp のファイル名は使用できません---メールを移動しているときに メールスプールをロックする方法がありません。

適当なサーバーを設置することが不可能なら、変わりに ssh を使うことができ ます。

  
(setq mail-sources
      '((file :prescript "ssh host bin/getmail >%t")))

`getmail' スクリプトは以下のようなものになるでしょう:

  
#!/bin/sh
#  getmail - move mail from spool to stdout
#  [email protected]

MOVEMAIL=/usr/lib/emacs/20.3/i386-redhat-linux/movemail
TMP=$HOME/Mail/tmp
rm -f $TMP; $MOVEMAIL $MAIL $TMP >/dev/null && cat $TMP

あなたが使いたい `movemail' と一時ファイルに合わせて、スクリプトを 書き換えてください。

directory
特定のディレクトリーにある複数のファイルからメールを取得します。これは普 通は procmail に新しいメールをいくつかのファイルに分割させているときに使 われます。すなわち、そのディレクトリーにあるファイルとグループは一対一で 対応しているので、`foo.bar.spool' ファイルにあるメール は foo.bar グループに置かれます (接尾語の .spool は変更可 能です)。nnmail-scan-directory-mail-source-once を nil 以 外の値にすると、Gnus に新しいメールソースを一回だけ調べさせることができ ます。これは特に、指定したレベルのメールグループだけを調べたいときに便利 です。

nnmail-resplit-incoming という変数もあり、これを非-nil に すると通常の分割処理がそのディレクトリーにあるすべてのファイルに対して行 なわれます (see 節 6.4.3 メールの分割)。

キーワード:

:path
ファイルがあるディレクトリーの名前です。これにはディフォルト値はありませ ん。

:suffix
この接尾語で終わる名前ファイルだけが使われます。ディフォルト は `.spool' です。

:predicate
この述語が nil でない値を返すファイルだけが使われます。ディフォル トは identity です。これは追加の選別器として使用されます---正しい 接尾語で、かつ この述語を満足するファイルだけが対象になります。

訳注: この場合の述語は関数で、正しい接尾語を持つファイルの名前が引数とし て渡されます。

:prescript
:postscript
それぞれのメールを取得する前と後で実行するスクリプトです。

ディレクトリーメールソースの例です:

  
(directory :path "/home/user-name/procmail-dir/"
           :suffix ".prcml")

pop
POP サーバーからメールを取得します。

キーワード:

:server
POP サーバーの名前です。ディフォルトは MAILHOST 環境変数 から取得されます。

:port
POP サーバーのポート番号です。これは数値 (例え ば `:port 1234') か文字列 (例えば `:port "pop3"') です。もし文 字列なら Unix システムにおける `/etc/services' に載っているサービス 名でなければなりません。ディフォルトは `"pop3"' です。システムによっ ては `"pop-3"' としなければならないかもしれません。

:user
POP サーバーに与える利用者名です。ディフォルトはログイン名です。

:password
POP サーバーに与えるパスワードです。設定しないと利用者は入力を 求められます。

:program
POP サーバーからメールを取得するために使用されるプログラムです。 これは format で使うような文字列でなければなりません。例です:

  
fetchmail %u@%s -P %p %t

有効な書法仕様指示子は:

`t'
メールがそこに移動させられるファイルの名前です。これは常にこの文字列に含 まれていなければなりません。

`s'
サーバーの名前です。

`P'
サーバーのポート番号です。

`u'
使用する利用者名です。

`p'
使用するパスワードです。

これらの仕様で使われる値は、対応するキーワードに与えた値から取られます。

:prescript
メールを取得する前に実行されるスクリプトです。構文は :program キー ワードと同じです。これは実行される関数であることもできます。

これの良く知られている使い道は、POP サーバーに接続するため の SSH トンネルをお膳立てすることです、ここに例があります:

  
(pop :server "127.0.0.1"
     :port 1234
     :user "foo"
     :password "secret"
     :prescript
     "nohup ssh -f -L 1234:pop.server:110 remote.host sleep 3600 &")

(訳注: 原典 は http://article.gmane.org/gmane.emacs.gnus.general/81249。)

:postscript
メールを取得した後で実行されるスクリプトです。構文は :program キー ワードと同じです。これは実行される関数であることもできます。

:function
POP サーバーからメールを取得するために使う関数です。その関数は 一つのパラメーター (メールがそこへ移動されるべきファイルの名前) とともに 呼ばれます

:authentication
これは password かシンボル apop のどちらかで、何の認証方式 を使うかを指示します。ディフォルトは password です。

:program と :function キーワードが指定されていない場合 は pop3-movemail が使われます。pop3-movemail を使う場合 に pop3-leave-mail-on-server が非-nil だったら、メールは取 得した後でも POP サーバーに残されます。POP サーバー はセッションとセッションの間の状態の情報を維持しないので、そこにあるクラ イアントが信頼できる情報と、実際にそこにあるものは一致しないかもしれない ことに注意してください。それらが一致しないと、メールをダブって受け取るか、 またはすべてが崩壊して、あなたは壊れたメールボックスとともに置き去りにさ れる可能性があります。

訳注: Gnus に含まれている `pop3.el' を使う場合 に pop3-leave-mail-on-server を非-nil に設定するのは、あま り意味がありません。サーバーに残されたメールは、次回に (何度でも) 再び取 り込まれてしまいます。一度取り込んだメールを二度と取得しないようにする機 能を持つ `pop3.el' は T-gnus に含まれています。これは XEmacs 用に開 発されたものが元になっています。しかし、残念ながら誰が開発したかがわかり ません。したがって FSF への正式な権利譲渡が行なわれていないので、Gnus に 含めることができないのです。

参考: 以下は T-gnus の `pop3.el' を使う場合に自動的に追加されるメー ルソース用のキーワードです:

:connection
サーバーに接続するときに使うストリームで、ssl、tls また は nil を指定することができます。ディフォルトは nil で、安 全ではない接続を用います。ssl と tls では外部プログラムと ライブラリーが必要であることに注意してください:

ssl
SSL を使います。OpenSSL (`openssl' プログラ ム) か SSLeay (`s_client') と外部ライブラリー `ssl.el' が必要 です。

tls
STARTTLS (SSL に類似) を使います。外部ライブラ リー `starttls.el' と `starttls' プログラムが必要です。

:leave
非-nil でメールをサーバーに残し、メッセージの取得に UIDL を使いま す。ディフォルトは nil です。

メールを POP サーバーから取得するための、いくつかの例を挙げま す。ディフォルトの利用者名を使って、ディフォルトの POP サーバー から取得し、ディフォルトの取得方法を使用します:

  
(pop)

指名したサーバーから、指名した利用者とパスワードで取得します:

  
(pop :server "my.pop.server"
     :user "user-name" :password "secret")

メールの移動に `movemail' を使います:

  
(pop :program "movemail po:%u %t %p")

maildir
Maildir からメールを取得します。これは少なくとも qmail と postfix によっ てサポートされているメールボックスの形式で、特別のディレクトリーにあるそ れぞれのファイルは、厳密に一通のメールを含んでいます。

キーワード:

:path
メールが保存されるディレクトリーの名前です。ディフォルトは環境変 数 MAILDIR から取得した値か、または `~/Maildir/' です。
:subdirs
Maildir のサブディレクトリーです。ディフォルトは `("new" "cur")' で す。

リモートマシンからメールを取り寄せることも出来ます。(というのも、 maildir はロックの問題を気にせずに済むからです。)

Maildir メールソースの例をふたつ:

  
(maildir :path "/home/user-name/Maildir/"
         :subdirs ("cur" "new"))

  
(maildir :path "/[email protected]:~/Maildir/"
         :subdirs ("new"))

imap
IMAP サーバーからメールを取得します。何らかの理由で、 IMAP をそれが意図されたようなネットワーク上でメールを読むプロ トコルとしては (すなわち nnimap で) 使いたくないときは、Gnus で は POP サーバーと同様に扱って、指定された IMAP メー ルボックスから記事を取得することができます。詳しく は 6.3 IMAP を使う を参照してください。

キーワード:

:server
IMAP サーバーの名前。ディフォルトは環境変数 MAILHOST か ら得ます。

:port
IMAP サーバーのポート番号。普通はディフォルトは `143' で、 TLS/SSL 接続には `993' です。

:user
IMAP サーバーに渡す利用者名です。ディフォルトはログイン名です。

:password
IMAP サーバーに渡すパスワードです。指定されていないときは、利 用者は入力することを促されます。

:stream
サーバーに接続するときに使うストリーム。imap-stream-alist にある シンボルの中のひとつを設定します。現状では `gssapi', `kerberos4', `starttls', `tls', `ssl', `shell' またはディフォルトの `network' になります。

:authentication
サーバーでの認証にどの認証法を使うか。これに は imap-authenticator-alist で定義されているシンボルの一つを設定 します。現状では `gssapi', `kerberos4', `digest-md5', `cram-md5', `anonymous' またはディフォルトの `login' にな ります。

:program
:stream に `shell' が設定されているときは、この値が変 数 imap-shell-program に割り当てられます。これは format ふ うの文字列 (または文字列のリスト) でなければなりません。例を示しましょう:

  
ssh %s imapd

何物もそのプログラムの出力を邪魔しないようにしてください。例えばエラー出 力は void に振り分けましょう。有効な書法仕様指示子は以下の通りです。

`s'
サーバーの名前。

`l'
imap-default-user で設定された利用者名。

`p'
サーバーのポート番号。

これらの指定に使われる値は、対応するキーワードに与えた値から取ってきます。

:mailbox
メールを取得するメールボックスの名前。ディフォルトは `INBOX' で、こ れは普通は入ってくるメールを受け取るメールボックスです。

:predicate
取得する記事を見つけるために使われる述語。ディフォルトの、`UNSEEN UNDELETED' はおそらくたいていの人には最良の選択でしょうが、ときど き IMAP クライアントでメールボックスを覗いて、いくつかの記事に 既読 (または SEEN) の印を付けるなら、これを `1:*' に設定する必要が あるかもしれません。そうすれば、メールボックスのすべての記事は印の如何に 関わらず取得されます。述語の完全な一覧は、RFC2060 の 6.4.4 節を読んでく ださい。

:fetchflag
サーバーで、取得した記事にフラグを付ける方法。ディフォルト の `\Deleted' はそれらに消去のフラグを付けますが、単に既読のフラグ を付けるための `\Seen' が代案になるでしょう。これらは最もありそうな 二つの選択ですが、他のフラグも RFC2060 の 2.3.2 節で定義されています。

:dontexpunge
nil でなかったら、記事を取得した後で、それらに消去の印が付いてい ても削除しません。

IMAP メールソースの例:

  
(imap :server "mail.mycorp.com"
      :stream kerberos4
      :fetchflag "\\Seen")

group
実際のメールソースとして mail-source グループパラメーターで設定さ れているものを使います。See 節 2.10 グループパラメーター.

Common Keywords
共通キーワードはどんな型のメールソースにも使うことができます。

キーワード:

:plugged
nil でなかったら、Gnus が unplugged (ネットワークから切り離されて いる状態) であってもメールを取得します。ディレクトリーをメールソースに使っ ているのならば、この例のように指定することができます:

  
(setq mail-sources
      '((directory :path "/home/pavel/.Spool/"
                   :suffix ""
                   :plugged t)))

こうしておくことによって unplugged であっても Gnus はメールを取得します。 これはローカルのメールとニュースを使う場合に便利です。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.4.4.2 関数インターフェース

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=6%2E4%2E4%2E2+%B4%D8%BF%F4%A5%A4%A5%F3%A5%BF%A1%BC%A5%D5%A5%A7%A1%BC%A5%B9"
"gnus/関数インターフェース"へのコメント(無し)

上記のいくつかのキーワードは、実行するための Lisp 関数を指定します。関数 が実行されている間だけ、それぞれのキーワード :foo に対し て Lisp 変数 foo が、そのキーワードの値に束縛されます。例えば、以 下のメールソースの設定例について考えてみてください。

  
(setq mail-sources '((pop :user "jrl"
                          :server "pophost" :function fetchfunc)))

関数 fetchfunc が実行されているとき、user というシンボルの 値は "jrl" に束縛され、server というシンボルの値 は "pophost" に束縛されます。port, password, program, prescript, postscript, function お よび authentication の値もまた (それらのディフォルト値に) 束縛さ れます。

それぞれの型のメールソースのためのキーワードのリストについては、前述の説 明を参照してください。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.4.4.3 メールソースのカスタマイズ

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Mail+Source+Customization"
"gnus/メールソースのカスタマイズ"へのコメント(無し)

以下はメールの取得方法に影響する変数の一覧です。普通はこれらのどれも設定 または変更する必要は無いでしょう。

mail-source-crash-box
メールが、それを処理している期間中に格納されている場所です。ディフォルト は `~/.emacs-mail-crash-box' です。

mail-source-delete-incoming
nil でなければ、入って来たメールを一時的に格納したファイルを、そ れを処理した後で消去します。t ではファイルをただちに消去し、 nil ではいかなるファイルも消しません。正の数だった場合は、その日 数以上に古いファイルを消去します (消去は新着メールを受け取るときだけ行な われます)。mail-source-delete-incoming を nil にしておいて、 mail-source-delete-old-incoming をフックで呼ぶか、または対話的に 呼ぶこともできます。mail-source-delete-incoming のディフォルト値 は、アルファ版の Gnus では 10、リリースされた版の Gnus で は 2 です。See 節 11.2.6 Gnus の開発.

mail-source-delete-old-incoming-confirm
非-nil だったら、古い incoming (メールの到着時に使われた) ファイ ルを消去するときに確認を求めます。この変数 は mail-source-delete-incoming が正の数である場合だけ使われます。

mail-source-ignore-errors
非-nil だったら、メールソースからメールを読むときのエラーを無視し ます。

mail-source-directory
入ってきたメールソースのファイルが (もしあれば) 格納されるディレクトリー です。ディフォルトは `~/Mail/' です。現時点でこれが使われる唯一のも のは、変数 mail-source-delete-incoming が nil または数値で あった場合に、入ってきたメールを格納するファイルの置き場所の指定です。

mail-source-incoming-file-prefix
入ってきたメールを一時的に格納するファイルの名前の接頭語です。ディフォル トは `Incoming' で、この場合ファイル は `Incoming30630D_' や `Incoming298602ZD' のようになります。 これが本当に関係するの は mail-source-delete-incoming が nil または数値の場合だけ ですが。

mail-source-default-file-modes
すべての新しいメールファイルはこのファイルモードになります。ディフォルト は #o600 です。

mail-source-movemail-program
nil でなかったら、新着メールを取り込むためのプログラムの名前であ ると解釈されます。nil だったら exec-directory にあ る movemail が使われます。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.4.4.4 メールの取得

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Fetching+Mail"
"gnus/メールの取得"へのコメント(無し)

新しいメールをどこから取得するかを実際に Gnus に指示する手段は、 mail-sources をメールソース指示子のリストに設定することで す (see 節 6.4.4.1 メールソース指示子)。

この変数が nil であれば、メールバックエンドは決して自分自身ではメー ルを取得しようとしません。

ローカルのスプールと POP メールサーバーの両方からメールを取得 したいなら、このようにすることができます:

  
(setq mail-sources
      '((file)
        (pop :server "pop3.mail.server"
             :password "secret")))

あるいは、これらのキーワードのどんなディフォルトも使いたくなければ、この ようにしてください:

  
(setq mail-sources
      '((file :path "/var/spool/mail/user-name")
        (pop :server "pop3.mail.server"
             :user "user-name"
             :port "pop3"
             :password "secret")))

あなたがメールバックエンドを使うとき、Gnus はすべてのメールを inbox から 吸い上げてホームディレクトリーに放り込みます。あなたがメールバックエンド を使っていないときは、Gnus は一通もメールを移動しません---そういう場合に は、最初にたくさんの魔法を唱えなければなりません。まず五芳星を描き、蝋燭 を灯し、山羊を生け贄として捧げ終えた後には、Gnus があなたのメールを移動 したとしても、あなたは実際にはあまり驚かないはずです。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.4.5 メールバックエンド変数

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Mail+Back+End+Variables"
"gnus/メールバックエンド変数"へのコメント(無し)

これらの変数 (のほとんど) は、すべてのさまざまなメールバックエンドに関連 します。

nnmail-read-incoming-hook
すべてのメールバックエンドは、新しいメールを読み込んだ後にこのフックを呼 びます。そうしたければ、何かのメール監視プログラムに知らせるためにこのフッ クを使うことができます。

nnmail-split-hook
それぞれのメッセージがそのヘッダーに基づいて分割がなされる直前に、それが 格納されているバッファーで実行されるフックです。このフックは、それがふさ わしいと考えられるようにするために、どんなやり方ででも自由にバッファーの 内容を編集することができます---バッファーは分割が終わった後で捨てられ、 バッファーで行なわれた変更はどのファイルにも現れません。 gnus-article-decode-rfc1522 は、このフックに加えられることがあり そうな関数の一つです。

nnmail-pre-get-new-mail-hook
nnmail-post-get-new-mail-hook
これらは、入ってくるメールを処理するときに実行される、有用な二つのフック です---nnmail-pre-get-new-mail-hook は新しいメールを処理する直前 に呼ばれ、nnmail-post-get-new-mail-hook はメールの扱う処理が終わっ たときに呼ばれます。以下はこれらの二つのフックを使って、新しいメールのファ イルのファイルモードを変更する例です:

  
(add-hook 'nnmail-pre-get-new-mail-hook
          (lambda () (set-default-file-modes #o700)))

(add-hook 'nnmail-post-get-new-mail-hook
          (lambda () (set-default-file-modes #o775)))

nnmail-use-long-file-names
nil でないなら、メールバックエンドは長いファイル名とディレクトリー 名を使います。`mail.misc' のようなグループは `mail.misc' とい う長い名前のディレクトリーかファイルに収められます (nnml バックエ ンドの場合はディレクトリー、nnfolder バックエンドの場合はファイル です)。nil だったら、同じグループは `mail/misc' に収められま す。

nnmail-delete-file-function
ファイルを消去するために呼ばれる関数です。ディフォルト は delete-file です。

nnmail-cache-accepted-message-ids
nil でないと、バックエンドに (例えば Gcc によって) 入って 来た記事の Message-ID を、メールの重複を発見するためのキャッシュ に入れます。ディフォルトは nil です。

nnmail-cache-ignore-groups
正規表現か正規表現のリストです。名前がどれかの正規表現に合致するグループ の記事は、Message-ID キャッシュに記録されません。

例えば特級分割 (see 節 6.4.6 特級メール分割) を関 数 nnmail-split-fancy-with-parent とともに使っている場合に役立つ でしょう。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.4.6 特級メール分割

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Fancy+Mail+Splitting"
"gnus/特級メール分割"へのコメント(無し)

訳注: Fancy という単語は、創造的、空想的、気まぐれな、好きな、派手 な、上等な、極上の、変わり種の、等々のさまざまな意味で使われますが、ここ では助動詞無しで使える利便を考えて「特級」という訳語を割り当てました。

比較的単純な、標準のメール分割指定の方法では思い通りにならないならば、 nnmail-split-methods を nnmail-split-fancy に設定すると良 いでしょう。そうすると、変数 nnmail-split-fancy で遊ぶことができ るようになります。

まずこの変数の値の例を見てみましょう:

  
;; メイラーデーモンから送られたメッセージが、普通のグループにクロス
;; ポストされないようにします。警告は本当のエラーとは違ったグループ
;; に入れます。
(| ("from" mail (| ("subject" "warn.*" "mail.warning")
                   "mail.misc"))
   ;; エラーでないメッセージはすべての関連するグループにクロスポスト
   ;; しますが、(ding) メーリングリストと他の (ding) 関連のメールの
   ;; ためのグループにはクロスポストしません。
   (& (| (any "ding@ifi\\.uio\\.no" "ding.list")
         ("subject" "ding" "ding.misc"))
      ;; 他のメーリングリスト...
      (any "procmail@informatik\\.rwth-aachen\\.de" "procmail.list")
      (any "SmartList@informatik\\.rwth-aachen\\.de" "SmartList.list")
      ;; 以下のどちらのメーリングリストも同じ接尾語なので、bugs- だ
      ;; けに投稿されたものが mypkg.list にクロスポストされないよう
      ;; にしています。しかし本当にクロスポストされた記事をクロスポ
      ;; ストすることはできるようになっています。
      (any "bugs-mypackage@somewhere" "mypkg.bugs")
      (any "mypackage@somewhere" - "bugs-mypackage" "mypkg.list")
      ;; 人々...
      (any "larsi@ifi\\.uio\\.no" "people.Lars_Magne_Ingebrigtsen"))
   ;; 合致しなかったメールはすべてを捕まえるグループへ行きます。
   "misc.misc")

この変数は「分割」の様式になっています。分割は (ことによると) それぞれの 分割が他の分割を含む再帰的構造です。以下は使うことができる分割の構文です:

group
分割が文字列だったら、それはグループ名であるとみなされます。通常の正規表 現の展開が行なわれます。後述の例 (訳注: `\\&', `\\1'〜`\\9') を見てください。

(field value [- restrict [...] ] split [invert-partial])
この分割は少なくとも三つの要素を含んでいる必要があります。最初の要 素 field (正規表現) に合致するヘッダーが value (これも正規表 現) に合致する文字列を含んでいたならば、split で指定されたグループ にメッセージを格納します。

field の後にあって、しかも合致した value の最後尾より前にあ る何かの文字列に restrict (これもまた正規表現) が合致したら、 split は無視されます。いくつかの restrict のどれもが合致しな ければ split が実行されます。

最後の要素 invert-partial は任意です。これが省略されていなくて、し かも値が nil でなければ、語 (word) の境界をまたいで正規表現の合致 を行なうかどうかの振る舞 い (nnmail-split-fancy-match-partial-words 変数によって制御されま す; 下記参照) が反転します。(Gnus 5.10.7 の新機能)

(| split ...)
分割がリストで、最初の要素が | (垂直棒) だったら、それぞれ の split をそのうちの一つが合致するまで実行します。ここで言う「合 致」とは、ある split がメッセージを一つ以上のグループに格納しよう とすることです。

(& split ...)
分割がリストで、最初の要素が & だったら、そのリストにあるすべて の split を実行します。

junk
もし分割がシンボル junk だったら、そのメッセージを保存しませ ん (すなわち、消去してしまいます)。非常に注意して使ってください。

(: function arg1 arg2 ...)
もし分割がリストで、最初の要素が : だったら、二番目の要素 が args を引数として関数として呼ばれます。関数は split を返 さなければなりません。

例えば以下の関数は、記事のボディーに基づいた分割に使えるでしょう:

  
(defun split-on-body ()
  (save-excursion
    (save-restriction
      (widen)
      (goto-char (point-min))
      (when (re-search-forward "Some.*string" nil t)
        "string.group"))))

function が実行されるとき、バッファーは対象となるメッセージのヘッ ダー部分に狭められています。それが上記の例 で save-excursion と save-restriction の後 で (widen) を呼ぶ必要がある理由です。さらに nnimap バック エンドの場合、ディフォルトでは記事のボディーがダウンロードされないことに 注意してください。それをするために は nnimap-split-download-body を t に設定する必要がありま す (see 節 6.3.3 クライアント側での IMAP 分割)。

(! func split)
分割がリストで最初の要素が ! だったら、split が実行され、 func は split の結果を引数として呼ばれます。func は分 割を返さなければなりません。

nil
分割が nil だったら、それは無視されます。

これらの分割で fileld は完全なフィールド名 (と言うかヘッダー名) に 合致しなければなりません。

通常これらの分割における value は、基礎モード (fundamental mode) 構文テーブル (syntax table) に従って、完全に 語 (word) に合 致しなければなりません。言い換えれば、すべての value は暗 に \<...\> 印 (語の区切り記号) で囲まれます。したがって、例えば以 下の分割を使うと、

  
(any "joe" "joemail")

`[email protected]' からやって来たメッセージは、通 常 `joemail' には格納されないでしょう。この振る舞いを変更したければ、 以下の三つのやり方のどれでもを使うことができます:

  1. nnmail-split-fancy-match-partial-words 変数を nil ではない 値に設定することによって、語の境界を無視させることができます。すると、合 致はより grep ふうになります。この変数は、特級分割で語の境界をまたいだ合 致を行なうかどうかを制御します。ディフォルト値は nil です。

    分割の規則のすべての value に影響することに注意してください。

  2. .* で始まる value は、語の前にある語の境界を無視させます。 同様に .* で終わる value は、語の後ろにある語の境界を無視さ せます。例えば "@example\\.com" とい う value は `[email protected]' に合致しませんが、 ".*@example\\.com" ならば合致します。

  3. この章の最初の方で述べた invert-partial フラグを、 `(field value ...)' 型の分割規則で使うことができま す。このフラグが設定されていると、 nnmail-split-fancy-match-partial-words が nil であっても、 語の両側にある語の境界は無視されます。逆に、このフラグが設定されていると、 nnmail-split-fancy-match-partial-words が nil ではない値で あっても、語の境界は無視されません。(Gnus 5.10.7 の新機能)

field と value は Lisp シンボルであることもできます。その場 合それらは nnmail-split-abbrev-alist で指定された内容に従って展開 されます。これはセルの CAR がキーを含んでいて、CDR が関連付け られた値を持っているコンスセル (cons cell) の連想リストです。以下の項目 が、あらかじめ nnmail-split-abbrev-alist に定義されています:

from
`From'、`Sender' および `Resent-From' の各フィールドに合 致します。
to
`To'、`Cc'、`Apparently-To'、`Resent-To' およ び `Resent-Cc' の各フィールドに合致します。
any
from と to を統合したものです。

nnmail-split-fancy-syntax-table は、これらのすべての分割が実行さ れているときに有効な構文テーブルです。

ヘッダーのいくつかの情報に基づいて、Gnus に動的にグループを作らせた い (例えば、グループ名の一部を replace-match のようなやり方で置き 換えさせたい) ならば、次のようなことができます。

  
(any "debian-\\b\\(\\w+\\)@lists.debian.org" "mail.debian.\\1")

この例では、`[email protected]' に送られたメール は `mail.debian.foo' というグループに入れられます。

文字列が要素 `\\&' を含んでいる場合は、直前に合致した文字列で置き換 えられます。同様に、要素 `\\1' から `\\9' までは、合致した文字 列の一部で置き換えられます (訳注: 正規表現の中 に `\\(' と `\\)' を使ってグループにまとめられたものが一つ以上 ある場合に、`\\n' はその正規表現の n 個目のグループに合 致する文字列の一部で置き換えられます)。

その際、合致した文字列を小文字にしたもので置き換えるべきかどうか を nnmail-split-lowercase-expanded が決定します。これを 非-nil にすることによって、アドレスで大文字と小文字が区別せずに使 われている (例えば mailing-list@domain と Mailing-List@Domain) 場合で も、複数のグループが生成されてしまうことを避けることができます。ディフォ ルトは t です。

関数 nnmail-split-fancy-with-parent は、フォローアップ記事を親記 事と同じグループに振り分けるために使います。メールの振り分けを一生懸命設 定してみても完璧にはできないことがありますね。例えば、上司から個人宛ての メールが届いたとします。自分が携っているプロジェクトとは別の話です。けれ ど「他のメールと区別できるようにこれこれこういう言葉を表題に書いてくださ い」と上司に向かって指図するわけにはいきませんから、結局自分の手を煩わし てひとつひとつメールを正しいグループに振り分けるはめになります。そんなと きにこの関数を使うと、この面倒な作業を一スレッドにつき一回きりで済ますこ とができます。

この機能を利用するためには、まず変 数 nnmail-treat-duplicates およ び nnmail-cache-accepted-message-ids の値を nil ではない値 に設定する必要があります。それができた ら nnmail-split-fancy-with-parent を使ってみてください。コロンを 使ってこんな風に書きます:

  
(setq nnmail-treat-duplicates 'warn     ; または delete
      nnmail-cache-accepted-message-ids t
      nnmail-split-fancy
      '(| (: nnmail-split-fancy-with-parent)
          ;; 残りの振り分け方はここに書く
        ))

この機能は実際、次の様に働いています: 変 数 nnmail-treat-duplicates の値が非-nil の場合、Gnus は見 つけた全記事のメッセージ ID を変 数 nnmail-message-id-cache-file で指定されたファイルに記録します。 このとき、それぞれの記事が格納されたグループの名前を併記します (ただしメー ルではないメッセージの場合は、グループ名は省略されます)。さて、いよいよ メールの振り分けが始まると、関 数 nnmail-split-fancy-with-parent は、分割される各記事 の References (と In-Reply-To) ヘッダーを調べ、 nnmail-message-id-cache-file で指定されたファイルにそれらのメッセー ジ ID があるかどうか調べます。親記事が見つかると、そのグループ名が正規表 現 nnmail-split-fancy-with-parent-ignore-groups に合致しなければ、 この関数は対応するグループ名を返すわけです。ここで、変 数 nnmail-message-id-cache-length の値をディフォルトよりも幾らか 大きな値に設定することを勧めます。そうすると、今調べられたメッセー ジ ID たちは今しばらくキャッシュの中に存続できます (5000 に設定するとキャッ シュファイルの大きさはだいたい 300 キロバイトぐらいになるみたいです)。 さらに、変数 nnmail-cache-accepted-message-ids の値を 非-nil に設定すれば、Gnus は移動された記事のメッセージ ID をも記 録するので、フォローアップ記事は親記事の移動先と同じグループに入るように なります。

特定のグループをキャッシュに記録したくない場合は、変 数 nnmail-cache-ignore-groups も参照してください。例えば、外に出 すすべてのメッセージを“outgoing”グループに保存しているのならば、 nnmail-cache-ignore-groups をそのグループ名に合致するように設定す れば良いでしょう。さもないとあなたのすべてのメッセージに対する返事が “outgoing”グループに入ってしまいます。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.4.7 グループメール分割

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Group+Mail+Splitting"
"gnus/グループメール分割"へのコメント(無し)

何ダースものメーリングリストを購読しているけれど、手でメール分割規則を維 持したくないというときのために、グループメール分割というものがあります。 あなたがしなければならないことは、グループパラメーターかグループカスタマ イズで to-list, to-address の両方もしくはどちらかを設定し て nnmail-split-methods を gnus-group-split に設定するだけ です。分割関数はすべてのグループでこれらのパラメーターを走査し、それに従っ て分割します。すなわち、メールグループのパラメー ター to-list か to-address で指定されたアドレスから投稿さ れたものか、そのアドレスへ投稿されたメッセージがそのグループに保存されま す。

ときには、メーリングリストには複数のアドレスがあり、メール分割にそれらす べてを認識させる必要があるかもしれません: extra-aliases グループ パラメーターを追加のアドレスのリストに設定するだけで終りです。あえて正規 表現を使いたければ、split-regexp を設定してください。

これらのすべてのグループのパラメーターは、nnmail-split-fancy の分 割を作成するために使用されます。その分割の仕様の中身 は、field の値が `any' であり、 value の値 が to-list と to-address と extra-aliases のすべて と split-regexp に合致するもののすべてに合致する単一の正規表現、 そして split がグループの名前になります。restrict も使うこと ができます: それには split-exclude パラメーターを正規表現のリスト に設定してください。

これらのすべてのパラメーターを使って正しい分割が生成されないときや、何か もっと凝ったものが必要なときは、split-spec パラメーター を nnmail-split-fancy の分割に設定することができます。この場合は、 前もって書かれたすべてのパラメーターは gnus-group-split に無視さ れます。特に、split-spec は nil (訳注: これ も nnmail-split-fancy の分割の一種です) に設定することができ、そ の場合そのグループは gnus-group-split に無視されます。

それぞれのグループのために、一つの分割を含む単一の & 特級分割を定 義することによって、gnus-group-split は合致するすべてのグループに クロスポストをします。どの分割にも合致しないメッセージは、どれかのグルー プで split-spec が catch-all に設定されていない場合 は gnus-group-split-default-catch-all-group で指定された名前のグ ループに格納されます。その場合、そのグループはすべてを受け取 る (catch-all) グループとして使われます。この変数はしばしばグループを指 定するためだけに使われますが、任意の複雑な特級分割に設定することもできる ので (結局のところグループ名は特級分割なのです)、個人のメールフォルダー にそれらのメールが格納されるどのメーリングリストにも当てはまらないメール を、分割するのに便利でしょう。なおこの特級分割は、| 分割リス ト (それは、グループパラメーターから抽出された規則を持った & 分割 をも含んでいます) の最後の要素として追加されることに注意してください。

そろそろ例を出すべきでしょう。以下のグループパラメーターが定義されている ことを仮定します:

  
nnml:mail.bar:
((to-address . "[email protected]")
 (split-regexp . ".*@femail\\.com"))
nnml:mail.foo:
((to-list . "[email protected]")
 (extra-aliases "foo@localhost" "foo-redist@home")
 (split-exclude "bugs-foo" "rambling-foo")
 (admin-address . "[email protected]"))
nnml:mail.others:
((split-spec . catch-all))

nnmail-split-methods を gnus-group-split に設定すると、 nnmail-split-fancy が選択されていて、かつ変 数 nnmail-split-fancy が以下のように設定されているかのように振舞 います:

  
(| (& (any "\\(bar@femail\\.com\\|.*@femail\\.com\\)" "mail.bar")
      (any "\\(foo@nowhere\\.gov\\|foo@localhost\\|foo-redist@home\\)"
           - "bugs-foo" - "rambling-foo" "mail.foo"))
   "mail.others")

グループ分割をすべてのメールグループで積極的には使いたくなければ、 nnmail-split-fancy の分割を次のように使用することで、いくつかのグ ループだけで使うことができます。

  
(: gnus-group-split-fancy groups no-crosspost catch-all)

groups は、出力の分割を生成するためにパラメーターが走査されるグルー プ名のリストか、それらのグループ名に合致する正規表現です。 no-crosspost はクロスポストを禁止するために使うことができ、その場 合は、単一の | 分割が出力されます。 catch-all は gnus-group-split-default-catch-all-group のよ うに、最後の手段として使われる特級分割です。 catch-all が nil に設定されているか、split-regexp が どれかの選択されたグループで空の文字列に合致すると、すべてを受け取 る (catch-all) 分割は発行されません。そうでない場合、あるグループ に catch-all に設定されている split-spec があると、そのグ ループは catch-all 引数の値よりも優先されます。

不運なことに、すべてのグループとそれらのパラメーターを走査することは、特 にすべてのメッセージに対して行なわなければならないことを考慮に入れると、 非常に遅くなるでしょう。でも、絶望してはいけません。 gnus-group-split-setup 関数を、はるかに効率的な方法 で gnus-group-split を動作させるために使うことができます。それ は nnmail-split-methods を nnmail-split-fancy に設定し、 nnmail-split-fancy を gnus-group-split-fancy で生成される 分割に設定します。そうすることによって、どんなに分割するメッセージがたく さんあっても、グループパラメーターは一度だけ走査されるようになります。

しかしながら、グループパラメーターを変更すると、 nnmail-split-fancy を手で更新しなければならなくなるでしょう。 gnus-group-split-update を実行することによって、それを行なうこと ができます。どちらかと言えば、それを自動的に更新したい場合には、 gnus-group-split-setup にそれを実行するように指示してください。例 えば、`~/.gnus.el' に以下のものを追加すれば良いでしょう:

  
(gnus-group-split-setup auto-update catch-all)

auto-update が nil でなけれ ば gnus-group-split-update が nnmail-pre-get-new-mail-hook に 追加されるので、二度と nnmail-split-fancy の更新について心配する 必要はありません。catch-all を省略しない場合は (それはオプション で nil と等価で す)、gnus-group-split-default-catch-all-group がその値に設定され ます。

gnus-group-split-update によって設定され た nnmail-split-fancy を後で変更する必要があるときのために、この 関数 (gnus-group-split-update) は終了する直前 に gnus-group-split-update-hook を実行します。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.4.8 古いメールを取り込む

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Incorporating+Old+Mail"
"gnus/古いメールを取り込む"へのコメント(無し)

たいていの人は色々なファイルフォーマットで保存されたたくさんの古いメール を持っているでしょう。Gnus の粋なメールバックエンドの一つを使うように設 定したのであれば、おそらく古いメールをメールグループに取り込みたいと思い ますよね。

それをすることはとても簡単です。

例を挙げましょう: nnml (see 節 6.4.13.3 メールスプール) を使ってメールを読ん でいて、nnmail-split-methods を申し分の無い値に設定しているものと しましょう。重要な、しかし古いメールで、古い Unix mbox ファイルが満たさ れています。あなたはそれを nnml グループに移動したいと思っていま す。

方法です:

  1. グループバッファーに行ってください。

  2. G f をタイプしてください。nndoc グループを作成するための元 になる mbox ファイルの名前を求められるので、それを入力してくださ い (see 節 2.9 外部グループ)。

  3. SPACE をタイプして、新しく作られたグループに入ってください。

  4. M P b をタイプして、グループバッファーのすべての記事に実行印を付け てください (see 節 3.7.6 プロセス印を付ける)。

  5. B r をタイプしてプロセス印の付いたすべての記事を再スプールしてくだ さい。その際に入力を求められるので、`nnml' と答えてくださ い (see 節 3.26 メールグループ命令)。

今や mbox ファイルのすべてのメールメッセージは、あなたの nnml グ ループ群にもばらまかれています。それらに入って、ものごとが変な故障も無く、 うまくいったかどうかを調べてください。大丈夫なようであれば、mbox ファイ ルを消そうと思うかもしれませんが、私はすべてのメールがあるべきところに納 まったことを完全に確認するまでは、そうはしません。

再スプールすることは、あるメールバックエンドを別のものに変更するときにも 便利なものです。古いメールグループにあるメールは、新しいメールバックエン ドを使ってただ再スプールすれば良いのです。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.4.9 メールの期限切れ消去

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Expiring+Mail"
"gnus/メールの期限切れ消去"へのコメント(無し)

伝統的なメールリーダーは、既読の印を付けるとメールの記事を何らかの方法で 削除する傾向があります。Gnus はメールを読むことに対して、基本的に違う方 法を取ります。

基本的に Gnus は、メールを少々変わった方法で受け取られたニュースであると みなします。実際にメールを変更したり、メールメッセージを消す権限があると は考えません。あなたがメールグループに入って記事に「既読」の印を付けたり、 何らかの他のやり方で切ったりしても、メールの記事はまだシステムに存在して います。繰り返します: Gnus はあなたの古い既読のメールを消去しません。も ちろん、あなたがそうしろと要求しない限りの話ですが。

要らないメールを Gnus に削除させるには、記事に「期限切れ消去可能」 (expirable) の印を付けなければなりません。(ディフォルトのキー割り当てで は、E をタイプしなければならないということです。) しかしながら、こ れは記事が即座に消え去るということではありません。一般的にメール記事は、 1) 期限切れ消去可能の印が付いていて、かつ 2) 一週間以上経っている、とい う場合に、システムによって削除されます。記事を期限切れ消去可能にしなけれ ば、それは地獄が凍りつくまでシステムに残り続けます。このことは、もう一度 強調付きで繰り返されるに足るものです: 「もし」あなたが記事を「期限切れ消 去可能」に「しない」なら、Gnus は「決して」それらの「記事」を消去しませ ん。

手作業で記事に期限切れ消去可能の印を付けなければならないわけではありませ ん。Gnus は“auto-expire”および“total-expire”と呼ばれる二つの機能を提 供して、あなたの手助けをします。かいつまんで言えば“auto-expire”はあな たが記事を選択したときに Gnus が E を叩いてくれることを意味します。 そして“total-expire”は、すべての既読の記事は期限切れ消去可能である と Gnus が解釈することを意味します。したがって `E' の印が付けられた 記事に加えて、`r', `R', `O', `K', `Y' (およびそ の類) の印が付けられた記事も期限切れ消去可能であると解釈されます。これら の印の完全なリストは gnus-auto-expirable-marks にあります。

では auto-expire または total-expire は、いつ使用されるべきなのでしょう か? メーリングリストを購読しているほとんどの人々は、それぞれのリストが それ用のグループに分割されるようにして、それらのグループに対し て auto-expire または total-expire を有効にしています。(それぞれのリスト をそれ用のグループへの分割する件についてのさらなる情報は 6.4.3 メールの分割 を参照してください。)

auto-expire と total-expire のどちらが良いのでしょうか? それに答えるの は簡単ではありません。概して言えば、たぶん auto-expire が速いでしょう。 auto-expire の別の利点は、より多くの印を後で読み返すつもりの記事に使うこ とができる、つまり今までどおりに可視 (tick)、保留 (dormant) または既 読 (read) の中から選ぶことができるということです。しかし total-expire で は、dormant と ticked からしか選べません。total-expire の利点は、適応ス コア付け (see 節 7.6 適応スコア付け) で良好に働くことです。auto-expire は 通常のスコア付けでは動作しますが、適応スコア付けではだめです。

正規表現 gnus-auto-expirable-newsgroups に合致するグループでは、 読んだすべての記事に自動的に期限切れ消去可能の印が付けられます。期限切れ 消去可能の印の付いたすべての記事は、概略バッファーの最初の桁 に `E' が表示されます。

自動期限切れ消去を有効にすると、ディフォルトではあなたが読んだすべての記 事に、以前に読まれたかどうかに関わらず、 Gnus は期限切れ消去可能の印を付 けます。既読の印が付いている記事に、自動的に期限切れ消去可能の印が付けら れるのを避けるには、以下のようなものを `~/.gnus.el' ファイルに置い ておけば良いでしょう:

  
(remove-hook 'gnus-mark-article-hook
             'gnus-summary-mark-read-and-unread-as-read)
(add-hook 'gnus-mark-article-hook 'gnus-summary-mark-unread-as-read)

グループを自動期限切れ消去可能にしても、すべての既読の記事が期限切れ消去 されるわけではなく、期限切れ消去可能の印が付いている記事だけが期限切れ消 去されることに気を付けてください。また、d 命令が自動的に記事を期限 切れ消去可能にするのでは無いことにも気を付けてください---自動期限切れ消 去可能にしたグループでは、記事に既読の印が半自動で付けられることによって のみ、記事が期限切れ消去可能になるということです。

2〜3 のメーリングリストを講読していて、読み終わってしばらく経ったら記事 が消えてしまうようにしたいなら、例えばこんな風に設定しましょう:

  
(setq gnus-auto-expirable-newsgroups
      "mail.nosense-list\\|mail.nice-list")

自動期限切れ消去を行なわせるもう一つの方法は、そのグループのグループパラ メーターに auto-expire という要素を持たせることです。

もし適応スコア付け (see 節 7.6 適応スコア付け) と自動期限切れ消去を使用し ていると、問題が起こるでしょう。自動期限切れ消去と適応スコア付けはあまり 良く調和しません。

変数 nnmail-expiry-wait で、期限切れ消去可能な記事をどれくらいの 期間残しておくかのディフォルトの時間を設定します。Gnus はメッセージが送 り出されたときではなく、それが 到着 してからの日数を計算します。 ディフォルトは 7 日間です。

Gnus は記事がどのグループに属しているかに基づいて、それをどのくらい残し ておくかをこまめに設定する関数も提供しています。以下の例で は `mail.private' グループは一ヶ月、`mail.junk' グループは一日、 その他全部は六日間に、それぞれ期限を設定します:

  
(setq nnmail-expiry-wait-function
      (lambda (group)
       (cond ((string= group "mail.private")
               31)
             ((string= group "mail.junk")
               1)
             ((string= group "important")
              'never)
             (t
               6))))

この関数に与えられるグループ名には「装飾」すなわち `nnml:' のような ものは付きません。

変数 nnmail-expiry-wait と関 数 nnmail-expiry-wait-function は、数値 (整数である必要はありませ ん) かシンボルの immediate か never のどちらかにすることが できます。

期限切れ期間を選択的に変更するために、グループパラメーター の expiry-wait を使うこともできます (see 節 2.10 グループパラメーター)。

記事を期限切れ消去するときに取られる通常の動作は、それらを消去することで す。しかし、場合によってはそれらを消去するよりも別のグループに移動した方 が有意義かもしれません。変数 nnmail-expiry-target (とグループパラ メーター expiry-target) はこれを制御します。この変数の値はすべて のグループに対するディフォルトになりますが、特定のグループごとにグループ パラメーターを使って指定すれば、そちらを優先させることができます。ディフォ ルトの値は delete ですが、文字列 (記事を移動する先のグループ名) または移動先のグループ名か delete を返す関数にすることができま す (関数の場合は、記事に範囲を狭めたバッファーで、その記事が存在している グループ名が引数として与えられます)。

グループ名を指定する場合の例:

  
(setq nnmail-expiry-target "nnml:expired")

Gnus には期限切れのメールをグループに移動させるための関数があります。そ れは変数 nnmail-fancy-expiry-targets に従って動作します。例です:

  
 (setq nnmail-expiry-target 'nnmail-fancy-expiry-target
       nnmail-fancy-expiry-targets
       '((to-from "boss" "nnfolder:Work")
         ("subject" "IMPORTANT" "nnfolder:IMPORTANT.%Y.%b")
         ("from" ".*" "nnfolder:Archive-%Y")))

この設定を行なうことにより、表題ヘッダーに IMPORTANT を持っていて、 YYYY 年 MMM 月に発信されたいかなるメールも、期限になる と nnfolder:IMPORTANT.YYYY.MMM グループに移動させられます。また、 From または To ヘッダーが文字列 boss を含んでいるメール は nnfolder:Work に、それ以外のすべてのメール は nnfolder:Archive-YYYY に、それぞれ期限になると移動させられます。

nnmail-keep-last-article が nil でないと、Gnus はメールグ ループの最後の記事を決して期限切れ消去しません。これは procmail の利用者 の人生をより楽にするためのものです。

補足: 上記の、Gnus が決して期限切れ消去可能でない記事を期限切れ消去する ことはない、というのは嘘です。total-expire をグループパラメーター に入れても、記事に期限切れ消去の印が付くことはありませんが、読んだすべて の記事は期限切れ消去の処理に通されます。非常に注意して使ってください。さ らに危険なのは変数 gnus-total-expirable-newsgroups です。この正規 表現に合致するすべてのグループでは、読んだすべての記事が期限切れ消去の処 理に通されます。これは、当のグループの すべて の古いメールの記事 は、しばらく後で削除されるということです。非常に注意して使ってください。 そして、あなたが使った正規表現が間違ったグループに合致してしまい、すべて の重要なメールが消えてしまったと言って、私に泣き付いて来ないでください。 しっかしりなさい! (直訳: 男になりなさい、あるいは女になりなさい、さもな ければもっと気持ちいい何にでもなりなさい!) ほうら、言わんこっちゃない!

たいていの人はほとんどのメールグループを total-expirable (全体期限切れ消 去可能) にしますが。

gnus-inhibit-user-auto-expire が nil でなければ、グループ で自動期限切れ消去が有効になっていても、利用者が印を付ける命令が記事に期 限切れ消去可能の印を付けることはありません。

記事の期限切れ消去可能の印は、自動期限切れ消去が有効になっていないグルー プにコピーするか移動するとき削除されます。これは記事が不意に期限切れ消去 されてしまうことを防ぐためです。一方、自動期限切れ消去が有効になっている グループにコピーまたは移動される記事の期限切れ消去可能の印は、ディフォル トでは変化しません。つまり、そのようなグループにコピーまたは移動されると き、期限切れ消去可能だった記事は期限切れ消去可能のままにされ、期限切れ消 去可能ではなかった記事に期限切れ消去可能の印が付くことはありません。した がって、たとえ自動期限切れ消去のグループであっても、いくつかの記事は期限 切れ消去されないでしょう (それらを再び読まない限りは)。自動期限切れ消去 のグループに期限切れ消去しない記事が紛れ込んでしまうかもしれないその動作 が気に入らないなら、 gnus-mark-copied-or-moved-articles-as-expirable を nil で はない値に設定することができます。その場合、読み終わった記事は自動期限切 れ消去が有効になっているグループにコピーまたは移動するとき、期限切れ消去 可能の印が自動的に付けられます。ディフォルト値は nil です。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.4.10 メール洗濯

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Washing+Mail"
"gnus/メール洗濯"へのコメント(無し)

メイラーやメーリングリストのサーバーは、メールに対して本当に本当に馬鹿げ たことをすることで悪名高いです。「わぁ、RFC822 はサーバーを通っていくメッ セージのすべての行の最後に wE aRe ElItE!!!!!1!! を加えることを明 示的に禁止はしていないぞ。さぁ、やってみよう!!!!1!」えぇ、そのとおりです が、RFC822 はおろか者が読むようには書かれていません。当たり前なこと (訳 注: 良識から逸脱すること) はそこでは議論されていません。ですから、この章 が必要なのです。

適例: ドイツ語版の Microsoft Exchange は返答の表題に `Re: ' の代わ りに `AW: ' を付け加えます。私はこれに動揺して狼狽しているふりをす ることもできましたが、そうする気力がありませんでした。それは笑うべきこと です。

Gnus は表示する記事を洗濯するために多すぎるほどの関数を提供していますが、 メールをディスクに保存する前にふるいにかけることができた方が良いかもしれ ません。その目的のために、三つのフックとそれらのフックに入れることができ る色々な関数を用意しています。

nnmail-prepare-incoming-hook
このフックはメールに何かをする前に呼ばれ、総括的に掃除してきれいにする所 作のためにあります。それは新しいすべての入ってきたメールを含んでいるバッ ファーで呼ばれます。使うことのできる関数は:

nnheader-ms-strip-cr
それぞれの行から、最後にあるキャリッジリターン (carriage return) を取り 除きます。これは MS のマシン上で動作している Emacs のディフォルトです。

nnmail-prepare-incoming-header-hook
このフックはそれぞれのメールのヘッダーに範囲を狭められて呼ばれます。ヘッ ダーをきれいにするときに使うことができます。使うことのできる関数は:

nnmail-remove-leading-whitespace
「役に立つ」メーリングリストのサーバーが、見栄えを良くするためだと称して、 ヘッダーの前の方に付け加えた空白を無くします (訳注: 例え ば `Subject:' などの直後に二つ以上の空白文字があったら、一つを残し て消します)。まったくもう。

(この関数はすべてのメッセージのボディーの中にあるヘッダー (ボディーの中 にある別のメッセージが持っているヘッダー行のようなもの) に対しても動作す るので、使用に際しては潜在的な危険を孕んでいます。したがってバグを修正す るよりは、そういう特徴があることを文書で説明するのが、もちろん正しい解決 の道です。)

nnmail-remove-list-identifiers
いくつかのメーリングリストのサーバーは、そのリストが配信したメールである ことを同定するための識別子---例えば `(idm)'---をすべて の Subject ヘッダーの先頭に付け加えます。石器時代のメールリーダー を使っている人たちには、それは確かに良いことです。この関数は正規表 現 nnmail-list-identifiers に合致する文字列を取り除きます。それは 正規表現のリストでも構いません。ただし正規表現に \\(..\\) を含め てはいけません。

例えば `(idm)' と `nagnagnag' という識別子を取り除きたいのなら:

  
(setq nnmail-list-identifiers
      '("(idm)" "nagnagnag"))

これは gnus-list-identifiers で非破壊的に行なうこともできます。 See 節 3.18.3 記事を隠す.

nnmail-remove-tabs
すべての `TAB' 文字を `SPACE' 文字に変換します。

nnmail-ignore-broken-references
いくつかの MUA (例えば Eudora と Pegasus) は壊れた References ヘッ ダーを作成しますが、In-Reply-To ヘッダーにはちゃんとしたものを入 れます。この関数は、ヘッダー部に正規表 現 nnmail-broken-references-mailers に合致する行があったら、 References ヘッダーを取り除きます。

nnmail-prepare-incoming-message-hook
このフックはそれぞれのメッセージに範囲を狭められて呼ばれます (訳注: 一度 に複数のメールを受信した場合でも、一通ずつ呼ばれるということです)。使う ことのできる関数は:

article-de-quoted-unreadable
Quoted Readable エンコードをデコードします (訳注: 実際に行なうの は quoted printable のデコードです)。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.4.11 重複

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Duplicates"
"gnus/重複"へのコメント(無し)

いくつかのメーリングリストのメンバーなら、時々同じメールを二つ受け取るこ とがあるでしょう。これはとても煩わしいので、nnmail はそれが見つけ たどんな重複をも、調べて処理します。これをするために、nnmail は古 い Message-ID を nnmail-messagge-id-cache-file (ディフォル トでは `~/.nnmail-cache') に保存します。それに保存され る Message-ID のおおよその最大数は変 数 nnmail-message-id-cache-length で制御され、ディフォルト は 1000 です。(ですから千個の Message-ID が溜められます。) これで 怖気をふるったなら、nnmail-treat-duplicates を warn (ディ フォルトではそのようになっていますが) に設定しても良いでしょう。そうする と、nnmail は重複したメールを消去しない代わりに、それが別のメッセー ジの重複であるという警告をメールのヘッダーに挿入します。

この変数は関数であることもできます。その場合、関数は当のメッセージに範囲 を狭められたバッファーから Message-ID を引数として呼ばれます。こ の関数は nil, warn, delete のどれかを返さなければな りません。

変数を nil に設定することによって、この機能を完全に使わないように することができます。

もしすべての重複したメールを特別な duplicates グループに入れたいの であれば、普通のメール分割方法を使ってそれをすることができます:

  
(setq nnmail-split-fancy
      '(| ;; 重複したメッセージは分かれたグループへ。
        ("gnus-warning" "duplicat\\(e\\|ion\\) of message" "duplicate")
        ;; デーモンやポストマスターなどからのメッセージは他へ。
        (any mail "mail.misc")
        ;; 他の規則。
        [ ... ] ))

もしくは次のようなもの:

  
(setq nnmail-split-methods
      '(("duplicates" "^Gnus-Warning:.*duplicate")
        ;; 他の規則。
        [...]))

すてきな使い方があるよ: 受け手である彼女がメールを Gnus で読んでいること と、彼女が nnmail-treat-duplicates を delete に設定してあ ることを知っていれば、彼女がすでに受け取ったことがわかっているメール の Message-ID そのものを使って、考えられる限りたくさんの侮辱を送 ることができるんだぜ。その面白さを考えてみてよ! 彼女はそれらを決して見る ことはないんだ! わぉ!


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.4.12 メールを読むのではない

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Not+Reading+Mail"
"gnus/メールを読むのではない"へのコメント(無し)

あなたが使い始めたどんなメールバックエンドでも、あなたがそれらでメールを 読みたいと思っていると仮定するという、悩ましい癖を持っていることに気が付 くでしょう。これは決して不合理ではないかもしれませんが、あなたの望むこと ではないかもしれません。

mail-sources と nnmail-spool-file を nil に設定すれ ば、どのバックエンドも入ってくるメールを読もうとしなくなって、それは助け になるはずです。

でも、それは行き過ぎでしょう。あなたが、例えば nnml でメールを読 むことと、しまいこんである古い (Emacs 23 より前の) Rmail ファイル を nnbabyl を使ってざっと覗くことだけで、まったく満足していている のならば。すべてのバックエンドには バックエンド-get-new-mail と いう変数があります。もし nnbabyl がメールを読み込みをやめさせたい のであれば、そのグループの仮想サーバー編集して、 nnbabyl-get-new-mail を nil に設定しましょう。

すべてのメールバックエンドは、入ってくるメールを読み込むときに、保存され るべき記事に範囲を狭めて nn*-prepare-save-mail-hook を呼び ます。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.4.13 メールバックエンドを選ぶ

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Choosing+a+Mail+Back+End"
"gnus/メールバックエンドを選ぶ"へのコメント(無し)

メールグループを動作するようにすると Gnus はメールスプールを読み込みます。 メールのファイルはまずあなたのホームディレクトリーに複写されます。その後 で何が起こるかは、メールをどの様式で格納したいかによります。

標準の Gnus では六つの違ったメールバックエンドがあり、さらに多くのバック エンドを個別に手に入れることができます。ほとんどの人が使うメールバックエ ンドは (それがたぶん最速なので) nnml です (see 節 6.4.13.3 メールスプール)。

6.4.13.1 Unix メールボックス    (とても) 標準的な Un*x mbox を使う
6.4.13.2 Babyl    Rmail の旧バージョンは Babyl を使う
6.4.13.3 メールスプール   
6.4.13.4 MH スプール    mhspool のようなバックエンド
6.4.13.5 Maildir    もう一つの１ファイル/１メッセージ形式
6.4.13.10 メールフォルダー   
6.4.13.11 メールバックエンドの比較   


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.4.13.1 Unix メールボックス

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Unix+Mail+Box"
"gnus/Unixメールボックス"へのコメント(無し)

nnmbox バックエンドはメールを格納するために標準の Un*x mbox ファイ ルを用います。nnmbox はそれぞれのメール記事にそれがどのグループに 属しているかを示す追加のヘッダーを加えます。

仮想サーバーの設定:

nnmbox-mbox-file
利用者のホームディレクトリーのメールボックスの名前。ディフォルト は `~/mbox' です。

nnmbox-activate-file
メールボックスのアクティブファイルの名前。ディフォルト は `~/.mbox-active' です。

nnmbox-get-new-mail
nil でなければ、nnmbox は入って来たメールを読み込んでグルー プに分割します。ディフォルトは t です。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.4.13.2 Babyl

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Babyl"
"gnus/Babyl"へのコメント(無し)

nnbabyl バックエンドはメールを格納するために Babyl メールボック スを使います。nnbabyl はそれぞれの記事にそれがどのグループに属し ているかを示す追加のヘッダーを加えます。

仮想サーバーの設定:

nnbabyl-mbox-file
Babyl ファイルの名前。ディフォルトは `~/RMAIL' です。

nnbabyl-active-file
Babyl ファイルのためのアクティブファイルの名前。ディフォルト は `~/.rmail-active' です。

nnbabyl-get-new-mail
nil でなければ、nnbabyl は入ってくるメールを読み込みます。 ディフォルトは t です。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.4.13.3 メールスプール

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Mail+Spool"
"gnus/メールスプール"へのコメント(無し)

nnml スプールメール様式は他の知られている様式とは互換性がありませ ん。それは少し注意して使われるべきです。

このバックエンドを使うと、Gnus は入ってくるメールを、それぞれのメール を 1 ファイルとしてファイルに分割し、記事を変数 nnml-directory で 指定されたディレクトリーの下の対応するディレクトリーに入れます。ディフォ ルトの値は `~/Mail/' です。

前もってディレクトリーを作っておく必要はありません。その面倒は Gnus がす べて見てくれます。

あなたのアカウントに保存できるファイルの数に厳密な制限があるなら、このバッ クエンドを使うべきではありません。それぞれのメールはそれ自身のファイルを 伴うので、数週間で数千の iノードを占有する可能性は十分にあります。あなた にとってこれが問題でなく、親切なシステム管理者が気が狂ったように「誰が僕 の i ノードを食いつぶしているんだ? 誰だ? 誰!?!」と叫びながら歩き回ること も問題でないなら、これがおそらく使うことのできる一番速い様式であるという ことは知っておくべきでしょう。新しいメールを読むためだけに大きな mbox ファ イルを重い足取りで探す必要はありません。

nnml は記事分割に関してはおそらく一番遅いバックエンドでしょう。多 くのファイルを作らなければならず、入ってくるメールのため の NOV データベースも作成しなければなりません。これのために、 メールを読むことに関してはたぶん最速のバックエンドになるのです。

仮想サーバーの設定:

nnml-directory
すべての nnml ディレクトリーはこのディレクトリーの下に置かれます。 ディフォルトは message-directory の値 (そのディフォルト値 は `~/Mail') です。

nnml-active-file
nnml サーバーのためのアクティブファイル。ディフォルト は `~/Mail/active' です。

nnml-newsgroups-file
nnml グループ記述ファイル。See 節 11.7.9.2 ニュースグループファイルの様式. ディフォ ルトは `~/Mail/newsgroups' です。

nnml-get-new-mail
nil でなければ、nnml は入って来たメール読み込みます。ディ フォルトは t です。

nnml-nov-is-evil
nil でなければ、このバックエンドはどの NOV ファイルも無 視します。ディフォルトは nil です。

nnml-nov-file-name
NOV ファイルの名前。ディフォルトは `.overview' です。

nnml-prepare-save-mail-hook
保存する前に一つの記事に範囲を狭めて実行するフックです。

nnml-use-compressed-files
非-nil だったら、nnml は圧縮されたメッセージファイルを扱う ことができるようになります。ただし auto-compression-mode が有効に なっていなければなりません (see 節 `Compressed Files' in
The Emacs Editor
)。nnml-use-compressed-files の値が文字列 だった場合、それは圧縮プログラムを指定するファイル拡張子として使われます。 Emacs がそれをサポートしていれば、それを `.bz2' に設定することがで きます。値 t は `.gz' と等価です。

nnml-compressed-files-size-threshold
メッセージファイルを圧縮するかどうかを判断するための、サイズの閾値です。 nnml-use-compressed-files が非-nil に設定されていて、本文 の文字数がこの変数の値より大きかったら、メッセージファイルは圧縮されます。

nnml グループと NOV ファイルの調子が完全に狂ってしまっ たら、M-x nnml-generate-nov-databases とタイプすることによって、完 全に更新することができます。この命令は、それぞれすべてのファイルを見るこ とによって nnml 階層全体をトロール魚網でさらうので、それが終わる までには時間がかかるかもしれません。この機能へのより良いインターフェース はサーバーバッファーで見つかるでしょう (see 節 6.1.2 サーバー命令)。

訳注: 単一の nnml グループの NOV データベースを再生成さ せるための nnml-generate-nov-databases-1 という命令もあります。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.4.13.4 MH スプール

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=MH+Spool"
"gnus/MHスプール"へのコメント(無し)

nnmh は、NOV データベースを作らないこととアクティブファ イルや印ファイルを保持しないことを除いて、nnml と似ています。この ことは nnmh を nnml より かなり 遅いバックエンドに していますが、procmail のスクリプトを書くことはずっとやりやすくなっても います。

仮想サーバーの設定:

nnmh-directory
すべての nnmh ディレクトリーはこのディレクトリーの下に置かれます。 ディフォルトは message-directory の値 (そのディフォルト は `~/Mail') です。

nnmh-get-new-mail
nil でなければ、nnmh は入ってくるメールを読み込みます。ディ フォルトは t です。

nnmh-be-safe
nil でなければ、nnmh はフォルダーにある記事が実際 に Gnus が考えているものと同じであるかを調べるという馬鹿げたことをやりま す。それは日付と目に入るすべての情報を調べるので、これを t に設定 すると深刻な速度低下が起こります。nnmh の記事を読むのに Gnus 以外 のものを使っていないのであれば、この変数を t に設定する必要はあり ません。ディフォルトは nil です。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.4.13.5 Maildir

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Maildir"
"gnus/Maildir"へのコメント(無し)

nnmaildir は各々の Gnus のグループに対応する maildir に、 maildir フォーマットでメールを格納します。このフォーマット は http://cr.yp.to/proto/maildir.html およ び http://www.qmail.org/man/man5/maildir.html で文書化されていま す。また nnmaildir は maildir の中の `.nnmaildir/' ディレク トリーに追加の情報を格納します。

Maildir フォーマットは、配送と講読を、ロックを必要とせずに同時に行なうこ とができるようにするために設計されました。他のバックエンドでは、メールを 何らかのスプールに渡した後で、そのスプールからグループに分割するために、 Gnus を設定しなければならないでしょう。それは今まで通 り nnmaildir で行なうことができますが、もっと普通のやり方は、 Gnus のグループとして現われる maildir に配送されたメールを、直接手にする ことです。

nnmaildir は完全に信頼できることを目指しています: C-g はメ モリー中のデータを壊さないし、SIGKILL がファイルの中のデータを壊 すことはありません。

nnmaildir は記事の印と NOV データを、それぞれ の maildir に格納します。それによって、ある Gnus の環境から別の場所 に maildir 全体をコピーすることができ、印は保持されます。

仮想サーバーの設定:

directory
それぞれの nnmaildir サーバー (一つを越えるサーバーが必要だとはと ても思えませんが) に対してディレクトリーを作り、それを maildir また は maildir へのシンボリックリンクとして実装する必要がありま す (maildir のためだけにです。他の目的のためにすでに使われているディレク トリーを選んではいけません)。それぞれの maildir は、そのサーバーのニュー スグループとして Gnus に現れ、シンボリックリンクのファイル名がそのグルー プの名前になります。ディレクトリーにある `.' で始まるどんなファイル 名も無視されます。ディレクトリーは最初に Gnus を起動したときとグループバッ ファーで g をタイプしたときはいつでも走査され、どれかの maildir が 削除または追加されていると、nnmaildir はそのときにそれを知ります。

directory パラメーターの値は Lisp 式でなければなりません。それは このサーバーのためのディレクトリーのパスを得るため に eval と expand-file-name で処理されます。その式はサーバー が開かれたときだけ eval され、その結果得られた文字列が、サーバー が閉じられるまで使われます (もし、式や eval を知らなくでも心配ご 無用; 単なる文字列で動作します)。このパラメーターは任意ではなく、必ず設 定しなければなりません。"~/Mail" やそれのサブディレクトリーを使う ことは推奨しません。なぜかと言うと、Gnus の他の複数の部分がそれをディフォ ルトでいろんなものに使うので、nnmaildir でもそれを使うと混乱する かもしれないからです。"~/.nnmaildir" が一般的な値です。

target-prefix
これは Lisp 式でなければなりません。それ は eval と expand-file-name で処理されます。その式 が eval されるのはサーバーが開かれたときだけで、その結果得られた 文字列がサーバーが閉じられるまで使われます。

nnmaildir サーバーにグループを作ると、その名前の頭 に target-prefix が付加された maildir と、その maildir を指し示す シンボリックリンクが素のグループ名の名前で作成されます。したがって、 directory が "~/.nnmaildir" で、 target-prefix が "../maildirs/" だった場合に foo と いうグループを作ると、nnmaildir は maildir とし て `~/.nnmaildir/../maildirs/foo' を、`../maildirs/foo' へのシ ンボリックリンクとして `~/.nnmaildir/foo' を作成します。

同じ directory に maildirs とシンボリックリンクの両方を作成するた めに、スラッシュを含まない文字列を target-prefix に設定することが できます。この場合は、directory で見つかる名前 が target-prefix で始まるどの maildir も、グループとは見なされま せん (が、それらを指し示すシンボリックリンクがグループになります)。

特別な場合として target-prefix が "" (それがディフォルトで す) だったら、グループを作るときに、対応するシンボリックリンクを持たな い maildir が directory において作成されます。そのようなグループ に対しては、force 引数を与えない と gnus-group-delete-group が使えないことに気をつけてください。

directory-files
これは directory-files と同じインターフェースを持っている関 数 (または directory-files そのもの) でなければなりません。これ は maildir 用のサーバーの directory を走査するために使われます。 このパラメーターは任意です。ディフォルトは、 nnheader-directory-files-is-safe が nil だった ら nnheader-directory-files-safe で、それ以外の場合 は directory-files で す (nnheader-directory-files-is-safe はサーバーが開いたときに一回 だけ検査されますが、ディレクトリーが走査されるときに毎回チェックさせたい のならば、それを行なう関数をあなたが自前で用意する必要があります)。

get-new-mail
非-nil にしておくと、いつもの通りにグループの maildir 自体におい て新着メールを走査した後で、このサーバーはさらに mail-sources か ら、nnmail-split-methods か nnmail-split-fancy の設定に従っ て、従来の Gnus の方法でメールを取り込みます。ディフォルト値 は nil です。

mail-sources と nnmaildir グループの両方で同じ maildir を 使っては いけません。その結果は運良く有益になるかもしれませんが、 そんな意図では設計されていませんし、将来は違う結果をもたらす可能性があり ます。あなたの分割規則が新しいグループを作るようになっている場合は、 create-directory サーバーパラメーターを設定することを忘れないでく ださい。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.4.13.6 グループパラメーター

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=6%2E4%2E13%2E6+%A5%B0%A5%EB%A1%BC%A5%D7%A5%D1%A5%E9%A5%E1%A1%BC%A5%BF%A1%BC"
"gnus/グループパラメーター"へのコメント(無し)

nnmaildir は複数のグループパラメーターを使います。これらのすべて を無視しても安全です。ディフォルトの nnmaildir の動作は、他のメー ルバックエンドのディフォルト (記事が一週間後に消去される、など) と同じで す。期限切れ消去のパラメーターを除いて、この機能はすべ て nnmaildir だけにあるものです。したがって、別のバックエンドです でに行なっている動作を単に踏襲させようというのであれば、これを無視するこ とができます。

これらのパラメーターのうちのどれでも、その値がベクトルである場合は、オリ ジナルの値に代わって、第一の要素が Lisp 式として評価された結果が使われま す。値がベクトルでない場合は、その値そのものが Lisp 式として評価されます。 (それが、これらのパラメーターが他とは違う名前、すなわち他のバックエンド でサポートされているものとは違うけれども似た意味を持っている同様のパラメー ターを使っている理由です。) (数値、文字列、nil、およ び t についても eval の関与を無視することができます。他の 値について、そうすることがふさわしい場合には、追加のクオートを使い、かつ ベクトルで値を包むことを忘れないでください。)

expire-age
記事が消去されるまでの寿命の秒数を指定する整数、あるいは記事が期限切れ消 去されてはならないことを指定する never というシンボルです。このパ ラメーターが設定されていないと、いつもの nnmail-expiry-wait 変数 または nnmail-expiry-wait-function 変数を最後のよりどころにしま す (expiry-wait グループパラメーターが設定されていると、その値 が nnmail-expiry-wait より優先して使われ、 nnmail-expiry-wait-function は無効にされます)。3日の値が必要なら ば、[(* 3 24 60 60)] のようなものを使ってください。 nnmaildir は式を評価して、その結果を使います。記事の寿命は記事ファ イルの変更時刻を基点に計測されます。通常これは記事が配送された時刻と同じ ですが、記事の編集はそれを若くします。(期限切れ消去以外の) 記事の移動も また、記事を若くしてしまうでしょう。

expire-group
これが以下のような完全な Gnus のグループ名の文字列で、

  
"backend+server.address.string:group.name"

かつこのパラメーターが設定されているグループの名前と同じではなかったら、 期限切れ消去が行なわれる際に、記事は消去される代わりに、これで指定された グループに移動させられます。これが nnmaildir グループに設定 されていると、移動先のグループにおいて、記事は元のグループにあったときと ちょうど同じ古さになります。 したがって、移動先のグループにおけ る expire-age には注意してください。これがパラメーターが設定され ているのと同じグループの名前に設定されると、記事はまったく期限切れ消去さ れません。ベクトルの式を使うと、最初の要素が一回、それぞれの記事について 評価されます。したがって記事をどこに置くかを決めるために、その式 は nnmaildir-article-file-name などに照会することができます。 たとえこのパラメーターが設定されていなくても、 nnmaildir は expiry-target グループパラメーター や nnmail-expiry-target 変数を顧みません。

read-only
これが t に設定されていると、nnmaildir はその記事をこ の maildir では読み出し専用として扱います。この意味は、記事 は `new/' から `cur/' に改名されない、記事は `cur/' では なく `new/' でのみ見つかる、記事は消去されない、記事は編集できない、 ということです。`new/' は他の maildir の `new/' ディレクトリー へのシンボリックリンクであると想定されます (そのディレクトリーには、例え ばみんなが興味があるメーリングリストを含んでいる、システムで共通のメール ボックスがあります)。`new/' 以外の maildir にあるすべてのものは、読 み出し専用として扱われ ません。したがって、みんなで共有するメール ボックスに対しては、あなた自身の maildir を設置する (または 共有のメール ボックスに書き込み権限を持つ) 必要が依然としてあります。そうすれば、あな たの maildir は記事の余分なコピーをまったく含まなくて済むでしょう。

directory-files
directory-files と同じインターフェースの関数です。記事を見つける ために、このグループに対応する maildir のディレクトリーを走査するために 使われます。ディフォルトはそのサーバーの directory-files パラメー ターで設定されている関数です。

distrust-Lines:
非-nil にしておくと、nnmaildir は Lines: ヘッダー フィールドを使う代わりにいつも記事の行数を数えます。nil だった場 合は、あればそのヘッダーフィールドが使われます。

always-marks
['(read expire)] のような印シンボルのリストです。Gnus が記事の印 を nnmaildir に尋ねるときはいつでも、ファイルシステムに格納されて いる印が何であるかとは無関係に、nnmaildir はすべての記事がこれら の印を持っていると答えます。これは機能を検証するためのもので、おそらく結 局は削除されるでしょう。それは Gnus 本体で行なわれるか、あるいは有益でな ければ放棄されるべきです。

never-marks
['(tick expire)] のような印シンボルのリストです。Gnus が記事の印 を nnmaildir に尋ねるときはいつでも、ファイルシステムに格納されて いる印が何であるかとは無関係に、nnmaildir はこれらの印を持ってい る記事は無いと答えます。never-marks は always-marks よりも 優先されます。これは機能を検証するためのもので、おそらく結局は削除される でしょう。それは Gnus 本体で行なわれるか、あるいは有益でなければ放棄され るべきです。

nov-cache-size
NOV メモリーキャッシュのサイズを指定する整数です。スピードアッ プのために、nnmaildir はそれぞれのグループの限定された数の記事に 対して、メモリー上に NOV データを保持します。(これはたぶん有用 ではなく、将来はおそらく削除されるでしょう)。このパラメーターの値は、サー バーが開かれた後で最初にグループが見られたとき、すなわち一般には最初 に Gnus を起動したときだけ注目されます。サーバーが閉じられて再び開かれる までは、NOV キャッシュのサイズは変更されません。ディフォルトは 概略バッファーに表示される記事の数の見積り (tick 印がある記事の数 か read が無い記事の数に、少々の余分を加えたもの) です。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.4.13.7 記事の識別

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=6%2E4%2E13%2E7+%B5%AD%BB%F6%A4%CE%BC%B1%CA%CC"
"gnus/記事の識別"へのコメント(無し)
記事はそれぞれの maildir の `cur/' ディレクトリーに格納されます。各々 の記事には uniq:info のような名前が付けられます。ここ で uniq はコロンを含みません。nnmaildir は :info の 部分を保持しますが無視します。(他の maildir リーダーは一般に印を格納する ためにこの部分を使います。) uniq の部分は記事をユニークに識別し、 maildir の `.nnmaildir/' サブディレクトリーの色々な場所に、対応する 記事の情報を格納するために使われます。記事の完全なパス名は、概略バッファー で記事を要求した後で nnmaildir-article-file-name 変数から得られま す。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.4.13.8 NOV データ

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=6%2E4%2E13%2E8+NOV+%A5%C7%A1%BC%A5%BF"
"gnus/NOVデータ"へのコメント(無し)
uniq によって識別される記事は、その NOV データ (概略バッ ファーの行を生成するために使われる) を `.nnmaildir/nov/uniq' に格納 します。nnmaildir-generate-nov-databases 関数はありません。(その 必要はあまりありません。記事の NOV データは記事 か nnmail-extra-headers が変化したときに自動的に更新されま す。) 対応する NOV ファイルを消すことによって、単一の記事だけ の NOV データの生成を nnmaildir に強制することはできま す。しかし ご用心。これは nnmaildir にこの記事に新しい記事 番号を割り振らせるので、seen 印、エージェント、およびキャッシュに とって面倒なことになります。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.4.13.9 記事の印

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=6%2E4%2E13%2E9+%B5%AD%BB%F6%A4%CE%B0%F5"
"gnus/記事の印"へのコメント(無し)
`.nnmaildir/marks/flag/uniq' ファイルがある場合に、uniq によっ て識別される記事は、flag 印を持つものと考えられます。 Gnus が nnmaildir にグループの印を尋ねると、nnmaildir はそ のようなファイルを探して、見つけた印のセットを報告します。 Gnus が nnmaildir に印のセットを格納することを要求すると、 nnmaildir は必要に応じて対応するファイルを生成し、または消去しま す。(実際は、それぞれの印のために新しいファイルを作るのではなく、iノード を節約するために単に `.nnmaildir/markfile' へのハードリンクを張りま す。)

`.nnmaildir/marks/' に新しいディレクトリーを作ることによって、新し い印を創造することができます。印を保持しつつ maildir を tar でまとめてサー バーからそれを削除し、後で tar をほどくと、印は保持されています。印ファ イルを作成または消去することによって、あなた自身が印を追加または削除する ことができます。Gnus が動作していて nnmaildir サーバーが開いてい るときにこれを行なう場合は、最初にすべての nnmaildir グループの概 略バッファーから退出してグループバッファーで s をタイプし、その後 グループバッファーで g か M-g をタイプするのが最良です。そう しないと Gnus は変更を捉えてくれずに、それらを元に戻してしまうかもしれま せん。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.4.13.10 メールフォルダー

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Mail+Folders"
"gnus/メールフォルダー"へのコメント(無し)

nnfolder はそれぞれのメールグループを別々のファイルに格納するバッ クエンドです。それぞれのファイルは標準の Un*x mbox 様式です。 nnfolder は記事番号と到着時刻を見失わないようにするための追加のヘッ ダーを加えます。

仮想サーバーの設定:

nnfolder-directory
すべての nnfolder メールボックスはこのディレクトリーの下に置かれ ます。ディフォルトは message-directory の値 (そのディフォルト は `~/Mail') です。

nnfolder-active-file
アクティブファイルの名前。ディフォルトは `~/Mail/active' です。

nnfolder-newgroups-file
グループ記述ファイルの名前。See 節 11.7.9.2 ニュースグループファイルの様式. ディフォルト は `~/Mail/newsgroups"' です。

nnfolder-get-new-mail
nil でなければ、nnfolder は入ってくるメールを読み込みます。 ディフォルトは t です。

nnfolder-save-buffer-hook
フォルダーを保存する前に実行されるフックです。nnfolder バッファー に対してさえも、Emacs は通常とおりファイル名を変更してバックアップを行な うことに注意してください。この機能を無効にしたいのであれば、 `~/.gnus.el' ファイルで次のようなことをすれば良いでしょう:

  
(defun turn-off-backup ()
  (set (make-local-variable 'backup-inhibited) t))

(add-hook 'nnfolder-save-buffer-hook 'turn-off-backup)

nnfolder-delete-mail-hook
これから消去されるメッセージに範囲を狭められて実行されるフックです。この 関数は別の場所にメッセージをコピーしたり、消去する前に何らかの情報を取り 出すために使うことができます。

nnfolder-nov-is-evil
もし非-nil なら、このバックエンドはどんな NOV ファイル をも無視します。ディフォルトは nil です。

nnfolder-nov-file-suffix
NOV ファイルの拡張子です。ディフォルトは `.nov' です。

nnfolder-nov-directory
NOV ファイルが格納されるディレクトリーです。nil だった ら nnfolder-directory が使われます。

nnfolder で読みたいたくさんの nnfolder に似たファイルを持っ ているのなら、そのようなすべてのファイルが nnfolder-directory に あることを nnfolder に気付かせるために、M-x nnfolder-generate-active-file 命令を使ってください。もっとも、これは長 いファイル名を使っているときだけ動作しますが。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.4.13.11 メールバックエンドの比較

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Comparing+Mail+Back+Ends"
"gnus/メールバックエンドの比較"へのコメント(無し)

まず用語としての「バックエンド」(back end) は、それによってなにものかが 取得される、低次のアクセス手段、あるいはそう言いたければ輸送手段です。そ れが意図するのはどこからかメールを取ってくることなので、Gnus がすぐに手 が届く距離の範囲内でメールを受け取るための、適当なバックエンドを選択する 必要があります。

同じ概念が Usenet 自身にも存在します。近ごろでは記事へのアクセスは一般的 に NNTP で行なわれますが、凄涼たる暗黒の昔には、世界中の誰もが、 記事を置いてあるマシン (今日では NNTP サーバーと呼ぶもの) でリー ダーを動作させることによって Usenet に接続したものでした。また、アクセス は記事のディレクトリーのスプールの領域に直接に踏み込むリーダーによって行 なわれました。たまたまそういうサーバーにいるのなら (あるいは NFS を介し て、とにかくそれのスプールのディレクトリーを見ることができるのなら)、今 でも nntp か nnspool バックエンドのどちらかを選ぶことがで きます。

(訳注:「凄涼たる暗黒の昔には」はポーの詩「大鴉」の冒頭部分“Once upon a midnight dreary”。)

メールバックエンドを選択することの行き着く先は、元の形式を処理し、かつ将 来便利に使える形式でメールを残すことを、同時に実現するのに適した方法を選 び出すことです。それぞれいくつかの良い点と悪い点があります:

nnmbox
歴史的に UNIX システムは、とても一般的で行き届いた定義のたった一つの形式 を持っています。すべてのメッセージは単一の「スプールファイル」に到着し、 それらは正規表現 `^From_' に合致する行で区切られています。 (`_' という記号はスペースを意味し、この例ではこれが RFC で規定され ている `From:' ヘッダーではないことをはっきりさせるために使っていま す。) Emacs それに Gnus も歴史的に Unix 環境から始まっているので、元 の mailbox 形式をあまりいじくり回さずに済めば、それが最も単純です。した がってこのバックエンドを選んだ場合に、本当のスプールからメールを取得し て Gnus にとって都合が好いディレクトリーにメールを移動するために Gnus が 主に行なうのは、処理の過程で何も (目立つような) 変更をせずに、単にそれを 複製することです。それは Gnus が処理を行なうことができる環境にメールを移 動するための「最も気が利かない」方法です。これは移動させることを速くしま すが、Gnus がどこに何があるかを調べるときは、解析が遅くなります。

nnbabyl
むかしむかしあるところに DEC-10 と DEC-20 がありました。それらは TOPS と いうオペレーティングシステムや似たようなものを実行していて、メールを読む ための普通の (もしかしたら唯一の?) 環境は Babyl というものでした。そのシ ステムに届いたメールでどんな形式が使われていたかはわかりませんが、 Babyl にはメールを変換するための、それ用の内部形式がありました。その変換 とは、Babyl 特有のヘッダーと状態ビットを、ファイルにあるそれぞれのメッセー ジの先頭に挿入するための仕組みによって、スプールファイル風の実体を作るこ とでした。Rmail は Emacs の最初のメールリーダーで、Richard Stallman によっ て書かれました。Stallman はその TOPS/Babyl の環境の出身だったので、すで に存在していたメールファイルの一族を理解するように Rmail を書きました。 Gnus は (この件に関しては VM も) この形式をサポートし続けています。それ は、そのメーラー特有のヘッダー/ステータス・ビットというものが、かなり良 質だと認められているからです。Rmail 自身ももちろんまだ存在していて、今で も Emacs の中で維持されています。Emacs 23 から、Babyl に代わって標準 の mbox 様式が使われるようになりました。

上記の両方の形式は、メールをファイルシステムにおける単一のファイルに置い たままにするので、メールを見るたびにファイル全体を解析しなければなりませ ん。

nnml
nnml は、あたかも nnspool でアクセスされる Usenet システム で実際に操作しているかのような感じのするバックエンドです。(実際のところ、 nnml はすごく以前に nnspool から枝分かれしたものだと思いま す。) メールは元のスプールファイルから取り出された後で、個々のファイル に 1:1 で切り分けられます。Usenet 様式のアクティブファイ ル (INN や CNews に基づいたニュースシステム の `/var/lib/news/active' ファイル (例えば) や、`NNTP LIST' 命 令で返されるものに類似したもの) を維持し、今ではかなりの年数にわたっ て NNTP サーバーのために定義されている overview ファイル も、グループへ入るときの効率を良くするために作成します。たくさんのファイ ルを作成し、nnml アクティブファイルを更新し、さらにメッセージ毎 に overview への追加を行なうので、メール分割では遅くなりますが、アクセス するときには、アクティブファイルと overview によって提供される索引機能に 支援されて、とてつもなく速くなります。

nnml は inode を非常にたくさん消費します。すなわち、新しい ファイルを置くことができる場所をファイルシステム上に定めるための資源を、 たくさん占有します。ぎっしりつまった共有ファイルシステムで大量 の inode を占有することを、システム管理者は快く思いません。もっとも、そ のファイルシステムが自分自身のもので、容量が希少ではない個人のマシンにい るのならば、nnml には非常に大きな利点があるのですが。

FAT16 の Windows の世界にいる場合にも、たくさんの小さなファイルで多くの 場所を取られてしまう点で問題があります。

nnmh
Rand MH メール閲覧システムは UNIX システムにかなり長い間存在しています。 それはメッセージのスプールファイルを個々のファイルに分割することによって 動作しますが、索引機能は少ししか、あるいはまったくありませ ん---nnmh は、意味的には「アクティブファイルまたは overview の無 い nnml」と等価です。これはおそらく最悪の選択でしょう。なぜならば、 個々のファイルを作ることの遅さが、何がグループで新しいかを知るときに解析 するために行なうアクセスの遅さに結び付くからです。

nnfolder
基本的に nnfolder が実現することは、グループ毎 の nnmbox (上で説明されている最初の方法) です。すなわ ち nnmbox 自体は すべて のメールを一つのファイルに入れます。 でも nnfolder はメールグループのそれぞれが Unix mail box ファイル を持つように、ほんの少し最適化をします。それぞれのグループは別々に解析さ れるので nnmobx よりも速く、しかもなお、メールを移動させるのに最 小限の労力しか要求しない、単純な Unix mail box 形式を提供します。加えて 「アクティブ」ファイルを維持し、Gnus がそれぞれの別のグループにどのくら いのメッセージがあるかを調べることをとても速くします。

もしたくさんの量のメッセージを受け取ることが予想されるグループがあるなら、 nnfolder は最善の選択ではありませんが、ほどほどの量のメールしか受 け取らないなら、おそらく nnfolder はすべての中で最も都合の良いバッ クエンドでしょう。

nnmaildir
期限切れ消去その他もろもろを設定するのに、nnmaildir は他のメール バックエンドとは少々異なった、互換性の無いグループパラメーターを使います。

nnmaildir は大方 nnml と似たものですが、いくらか顕著な違い があります。それぞれのメッセージは別々のファイルに格納されますが、ファイ ル名は Gnus の記事番号と関係がありません。ま た nnmaildir は nnml の overview に相当するファイルを記事 ごとに一つ格納するので、nnml の約二倍の量の iノードを使います。 (df -i を使って iノードの割り当てがどれほどたくさんあるかを調べて ください。) そのために遅くなったり多くの場所を取ってしまうようならば、他 の非ブロック構造のファイルシステムへの転換を検討してください。

maildir は受信配送のためのロックを必要としないので、あなたがグループとし て使っている maildir は、配送されてきたメールを直接受け取るため の maildir にすることもできます。これは、メールが配送されてくる過程で異 なるメールボックスに仕分されるようになっているのならば、Gnus のメール分 割を省略できることを意味します。mail-sources におけ る directory の項には (訳注: maildir を使わなくても) 似た効果があ りますが、配送されてくるメールをスプールするためのメールボックスの一揃 い (mbox 形式ではそのためにメッセージの本文が壊れる) と、他の (何であれ あなたの好みの形式の) グループとして使われる組が必要です。一 方 maildir は、new/ サブディレクトリーに置かれる組み込みスプール を持ちます。メール分割による代わりに new/ から cur/ に移動 されたメールは、ダブっているかどうかをチェックするような処理を今のところ は受けないことに注意してください。

nnmaildir はグループの記事の印を、それに対応する maildir に格納し ます。Gnus の外からそれらを簡単に操作できるようにするために、そのように 作られているのです。maildir を tar でまとめてから別のどこかで展開しても、 印はそのままです。

nnmaildir は速度を上げるためにかなりの量のメモリを使います。 (nnml の場合はファイルに格納し、nnmh では何度もメッセージ ファイルを解析して得るものごとを、それはメモリ上に保持します。) これがあ なたにとって問題ならば、nov-cache-size グループパラメーターを何か 小さな値 (0 はおそらくだめですが 1 だったらたぶん働きます) に設定するこ とによって、少ないメモリで済むようにすることができます。このキャッシュ機 構は、おそらく将来は削除されるでしょう。

起動は他のバックエンドよりも nnmaildir の方が遅いでしょう。ファイ ルシステムに依存していないすべての部分では速いでしょう。

nnmaildir は nnoo を使わないので、nnmaildir から派 生したバックエンドを書くのに nnoo は使えません。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.5 Browsing the Web

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Browsing+the+Web"
"gnus/BrowsingtheWeb"へのコメント(無し)

ウェブに基づいた議論の場はどんどん広まっています。多くの分野で、ウェブの 掲示板は最も重要な場になり、メーリングリストやニュースグループの重要性を 翳らせています。理由は簡単です---新しい利用者が使い易いからです。ただ場 所をクリックするだけで、議論の場があります。メーリングリストでは、面倒な 購読手続きをしなければならず、ほとんどの人はニュースグループというものが が何であるかすら知りません。

この筋書きから浮かび上がる問題は、ウェブブラウザーはニュースリーダーとし てはあまり良くないということです。どんな記事を読んだかを記録しません。興 味のある表題にスコアを付けることができません。オフラインで読むことができ ません。何度もクリックすることを要求し、最後にはあなたを怒らせます。

ならば---ウェブブラウザーが掲示板を読むのに適していないのなら、代わり に Gnus を使いませんか?

Gnus はこれらのソースへのインターフェースを提供するバックエンド群を少し 備えつつあります。

6.5.1 メールの保存   
6.5.2 ウェブ検索   
6.5.3 RSS    RDF Site Summary を読む
6.5.4 W3 のカスタマイズ    Gnus から Emacs/W3 を操作する

すべてのウェブソースは、動作させるために Emacs/W3 と url ライブラリー、 またはそれらの代替が必要です。

これらのウェブソースの一番の問題は、長期間は動作しない可能性が高いことで す。HTML のデータから情報を拾い集めるのはせいぜい推測で、その 構造が変化したときには、Gnus バックエンドは動作しません。でも、ある程度 新しいバージョンのバックエンドを使っていれば大丈夫のはずです。

これらのウェブの手段に共通することは、ウェブソースはしばしば落ちていたり、 使用可能でなかったり、はっきり言って楽しむには遅すぎる、ということです。 そういう場合に、Gnus Agent (see 節 6.9 Gnus の切り離し) に記事のダウンロード を任せて、ローカルディスクから好きなときに読むようにすることは、大いに意 義があります。これで World Wide Wait とはおさらばです。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.5.1 メールの保存

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Archiving+Mail"
"gnus/メールの保存"へのコメント(無し)

いくつかのバックエンド、特に nnml, nnfolder およ び nnmaildir は、今ではそれぞれのグループの記事の印を本当に保持す るようになりました (訳注: そうなったのはだいぶ前ですが)。これらのサーバー で、グループの印を保ちつつ保存したり元に戻すのはかなり簡単です。

(でも、グループレベルとグループパラメーターをも保持するには、今までとお り `.newsrc.eld' の神に、舞いと生贄を捧げなければなりませんが。)

nnml, nnfolder または nnmaildir サーバーにまるごと 保存するには、サーバーのディレクトリーを再帰的にコピーしてください。 Gnus を終了する必要は無いので、保存は cron やそれに類するものが行 なうことができます。データを復帰させるにはディレクトリー木 (tree) を元に 戻すことによって行ない、そのディレクトリーを指し示すように Gnus のサーバー の定義に追加しましょう。3.15 記事のバックログ, 3.11 非同期記事取得 およびその他のものはデータを上書きして邪魔を するかもしれないので、データを復帰させる前に Gnus を終了する必要があるか もしれません。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.5.2 ウェブ検索

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Web+Searches"
"gnus/ウェブ検索"へのコメント(無し)

ううむ、まあ、調べたい文字が書いてある記事を、その、Usenet で探すという ことは、ですね、もちろん素晴らしいことこの上ないのではありますが、しかし、 何と申しましょうか、ウェブブブラウザーといいますか、そういうものを使って ことを行なうのは、何ともその、はばかりながら、ぶざまと言いますか、そうす ると、コマーシャルを見ないわけにはいかないのでありまして、しかるに、 Gnus を使えばブラウザー無しで検索することができます。

nnweb バックエンドは、強力な検索エンジンへの簡単なインターフェー スを提供します。nnweb グループを作成し、検索パターンを入力してか ら、そのグループに入って他の普通のグループのように記事を読んでください。 グループバッファー (see 節 2.9 外部グループ) の G w 命令によって、 手軽にこれができます。

nnweb グループは、固定グループになろうとはしません---このグループ では記事番号はごく一時的なものとして扱われます。実際、nnweb グルー プに入るたびに (たとえ検索パターンを変更していなくても)、記事の順序が違っ ているかもしれません。また、重複抑制 (see 節 3.30 重複の抑制) を 使っても役に立たないでしょう。というのは、検索エンジ ン (例えば Google) を使って記事を読み込む前の段階では、nnweb はそ れらの Message-ID を知らないからです。あなたが読んだ記事を憶えて おくための唯一の方法は、Date ヘッダーを元にスコアを付けることだけ です---つまり、そのグループを最後に読んだ日付より前に投稿された記事を、 すべて既読にするということです。

もし検索エンジンの出力形式が実質的に変更されると、nnweb はそれを うまく解釈できなくて、処理に失敗するでしょう。ウェブの提供者たちがそんな ことをしても、彼らを責めることはできないでしょう---それは広告で金を稼ぐ のが彼らの レーゾン・デートル (存在理由) であり、社会にサービスを 提供することではないからです。nnweb はすべての記事から広告を洗い 流してしまうので、提供者たちがムカついていると思われるかもしれません。ま あ見ててください。

nnweb を使うには、url と W3 パッケージ、またはそれ らの代替 (`mm-url' 変数グループに対して customize-group を試 してみてください) をインストールしておかなくてはなりません。

以下は仮想サーバー変数です。

nnweb-type
どの検索エンジンを使うかを指定します。現在サポートされている種類は、 google, dejanews そして gmane です。 dejanews は google の別名になっていることに注意してくださ い。

nnweb-search
検索エンジンに与える検索文字列です。

nnweb-max-hits
一つの検索で表示する最大のヒット数の希望値で、ディフォルトは 999 です。

nnweb-type-definition
種類と定義の連想リストです。この連想リストは、さまざまな検索エンジンの種 類に対して、nnweb がどうすべきかを指定します。以下に示す要素を与 えなくてはなりません。

article
記事をデコードし、Gnus が理解できる何かを提供する関数です。

map
メッセージヘッダーと URL を、記事番号を元にして得るための連想リストを作 成する関数です。

search
検索エンジンに検索文字列を送るための関数です。

address
前述の関数が検索文字列を送るべきアドレスです。

id
Message-ID を元にして記事を取得するための、URL フォーマットの文字 列です。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.5.3 RSS

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=RSS"
"gnus/RSS"へのコメント(無し)

いくつかのウェブサイトは RDF site summary (RSS) を持っています。 RSS は、ニュース関連のサイト (BBC や CNN のような) の見出しを 要約するためのフォーマットです。しかし、基本的にリストのようなものなら何 でも、RSS feed として提供することができます: weblogs, changelogs あるいは wiki (例え ば http://cliki.net/recent-changes.rdf) の最新の変更などが対象にな ります。

RSS はとても規則的で良質なインターフェースを持っているので、 Gnus がグループを最新の状態に保っておくために必要な情報を得ることが可能 です。

注: utf-8 coding system をサポートする Emacs を使うのが良いでしょ う。RSS は非-ASCII テキストをエンコードするために、 ディフォルトで UTF-8 を使うからです。それはまた、非-ASCII グルー プ名にもディフォルトで使われます。

Feed を講読するには、グループバッファーから G R を使ってくださ い---feed の所在、タイトルおよび説明の入力を求められるでしょう。タイトル はどんな文字でもよく、それはグループ名とグループのデータ・ファイルの名前 に使われます。説明は省略できます。

簡単に nnrss を始める方法は、グループバッファーで B nnrss RET RET y のようなことを唱え、そしてグループを講読することです。

nnrss バックエンドは、それぞれの nnrss グループのためのデー タ・ファイルを nnrss-directory (下記参照) に保存します。 非-ASCII 文字を含んでいるファイル名 は、nnmail-pathname-coding-system 変数または他のもので指定され た coding system でエンコードされます。詳細はここ (see 節 2.17 英字以外の名前のグループへのアクセス) を見てください。

nnrss バックエンドは、それぞれが `text/plain' パート と `text/html' パートを含んでい る `multipart/alternative' 型の MIME 記事を作ります。

あなたの講読目録を OPML フォーマット (Outline Processor Markup Language) でロード/セーブするために、以下のコマンドを使うこともできます。

Function: nnrss-opml-import file
OPML ファイルの入力を促し、そのファイルにあるそれぞれ の feed を講読します。

Function: nnrss-opml-export
現在の RSS 講読目録を OPML フォーマットでバッファー に書き出します。

以下の nnrss 変数が変更可能です:

nnrss-directory
nnrss がファイルを書き込むディレクトリーで、ディフォルト は `~/News/rss/' です。

nnrss-file-coding-system
nnrss グループのデータ・ファイルを読み書きするときに使われ る coding system です。ディフォルト は mm-universal-coding-system の値 (そのディフォルトは Emacs で は emacs-mule、XEmacs では escape-quoted) です。

nnrss-ignore-article-fields
いくつかのフィードは、記事フィールドの例えばコメント数を、その存続期間を 通じて絶えず更新します。しかしそれはローカルに保存したものとの差異を生む ので、サーバーに新しい記事があるように解釈されてしまいます。いくつかの フィールドを無視してこれを防ぐためには、この変数に無視するべきフィールド のリストを設定してください。ディフォルトは '(slash:comments) です。

nnrss-use-local
nnrss-use-local を t に設定すると、 nnrss は nnrss-directory にあるローカルファイルか ら feed を読みます。nnrss-generate-download-script コマンドを使う ことによって、wget を使ったダウンロード・スクリプトを作ること ができます。

概略バッファーに説明を表示させたいならば、以下のコードが役に立つでしょう。

  
(add-to-list 'nnmail-extra-headers nnrss-description-field)
(setq gnus-summary-line-format "%U%R%z%I%(%[%4L: %-15,15f%]%) %s%uX\n")

(defun gnus-user-format-function-X (header)
  (let ((descr
         (assq nnrss-description-field (mail-header-extra header))))
    (if descr (concat "\n\t" (cdr descr)) "")))

以下のコードは、概略バッファーから直接 nnrss の url をオープンするのに便 利でしょう。

  
(require 'browse-url)

(defun browse-nnrss-url (arg)
  (interactive "p")
  (let ((url (assq nnrss-url-field
                   (mail-header-extra
                    (gnus-data-header
                     (assq (gnus-summary-article-number)
                           gnus-newsgroup-data))))))
    (if url
        (progn
          (browse-url (cdr url))
          (gnus-summary-mark-as-read-forward 1))
      (gnus-summary-scroll-up arg))))

(eval-after-load "gnus"
  #'(define-key gnus-summary-mode-map
      (kbd "") 'browse-nnrss-url))
(add-to-list 'nnmail-extra-headers nnrss-url-field)

あなたが HTML パートを見たくないため に `text/html' を mm-discouraged-alternatives 変 数 (see 節 `表示のカスタマイズ' in

The Emacs MIME Manual
) に加えていたとしても、特に nnrss グループ では `text/html' を表示する方が便利かもしれません。以下 は nnrss グループでだけは `text/html' パートを表示するために、 グループパラメーターとして mm-discouraged-alternatives を設定する 例です:

  
;; mm-discouraged-alternatives のディフォルト値を設定。
(eval-after-load "gnus-sum"
  '(add-to-list
    'gnus-newsgroup-variables
    '(mm-discouraged-alternatives
      . '("text/html" "image/.*"))))

;; nnrss グループでは `text/html' パートを表示。
(add-to-list
 'gnus-parameters
 '("\\`nnrss:" (mm-discouraged-alternatives nil)))


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.5.4 W3 のカスタマイズ

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Customizing+W3"
"gnus/W3のカスタマイズ"へのコメント(無し)

Gnus はウェブページを取得するために url ライブラリーを、ウェブページを表 示するために Emacs/W3 を (またはそれらの代替を) 使います。Emacs/W3 のこ とはそのマニュアルに記載されていますが、ここでは Gnus の利用者にとってよ り適切な、いくつかの事柄を述べることにします。

例えばよくある質問は、Emacs/W3 に browse-url の関数 (Netscape の ような外部プラウザーを呼びます) を使ってリンクを参照させるにはどうしたら よいか、というものです。以下は一つの方法です:

  
(eval-after-load "w3"
  '(progn
    (fset 'w3-fetch-orig (symbol-function 'w3-fetch))
    (defun w3-fetch (&optional url target)
      (interactive (list (w3-read-url-with-default)))
      (if (eq major-mode 'gnus-article-mode)
          (browse-url url)
        (w3-fetch-orig url target)))))

これをあなたの .emacs ファイルに書き込んでください。そうすれば、Gnus の 記事バッファーで W3 が描画した HTML リンクを叩くと、 browse-url を使ってそのリンクを参照してくれるでしょう。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.6 その他のグループ源

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Other+Sources"
"gnus/その他のグループ源"へのコメント(無し)

Gnus はただ単にニュースやメールを読む以上のことができます。以下に示す方 法によって、Gnus でディレクトリーやファイルを、あたかもニュースグループ であるかのように閲覧することができるようになります。

6.6.1 ディレクトリーグループ   
6.6.2 なんでもグループ    Dired? 誰が dired なんて使うの?
6.6.3 文書グループ   
6.6.4 メールからニュースへのゲートウェイ   
6.6.5 空っぽのバックエンド   


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.6.1 ディレクトリーグループ

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Directory+Groups"
"gnus/ディレクトリーグループ"へのコメント(無し)

たくさんの記事が個別のファイルとして入っているディレクトリーがあれば、そ れをニュースグループとして扱うことができます。もちろん、ファイルは数字の ファイル名をもっていなければなりません。

素晴らしい Emacs のパッケージの中でも最も素晴らしい ange-ftp (と その後継の efs) について触れるのに、ここは良い機会でしょう。私 が nndir を書いたときは、これ (ディレクトリーを読むバックエン ド) についてはあまり考えていませんでした。とんでもないことだね。

ange-ftp はこの情況を劇的に変化させました。例えばディレクトリー名 として ange-ftp の様式 で `/ftp.hpc.uh.edu:/pub/emacs/ding-list/' というファイル名をディレ クトリー名として入力したとすると、ange-ftp あるいは efs は 実に「シナ」の向こうのディレクトリーをニュースグループとして読めるように なるのです。おーい、分散ニュースだぞーっ!

(訳注:「シナ」(原典 `sina') は China のことか?)

nndir は NOV ファイル群が存在すればそれらを利用します。

nndir は「読み出し専用」のバックエンドです---この選択方法では、記 事の削除や期限切れ消去を行なうことはできません。nndir が使えるも のなら何でも、nnmh あるいは nnml でも使うことができるので、 もし読み出し専用ではない nndir が必要だと思ったら、これらのどちら かの方法に切り替えることもできます。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.6.2 なんでもグループ

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Anything+Groups"
"gnus/なんでもグループ"へのコメント(無し)

nneething は nndir バックエンド (単一のスプール風ディレク トリーを読むバックエンド) のほんの少し先にあるもので、それはどんなディレ クトリーでもニュースグループに見せかけてしまいます。不思議ですが真実です。

nneething にディレクトリーを与えると、そのディレクトリーを走査し て各ファイルに記事番号を割り当てます。そのようなグループに入ったら、 nneething は Gnus が使える「ヘッダー」を作らなくてはなりません。 つまるところ Gnus はニュースリーダーなんです。忘れているかもしれないので 念のため。nneething はこれを二段階で処理します。最初に、対象とな るそれぞれのファイルを覗いてまわります。もしそのファイルが記事のように見 えたなら (すなわち最初の数行がヘッダーのように見えたら) それをヘッダーと して使います。もしそれがヘッダーの無いただの適当なファイル (例えば C の ソースファイル) だったら、nneething はヘッダーを虚空からでっち上 げます。これはファイルの所有者、名前および日付を使い、それらの要素を元に できることを何でもやります。

これはあなたにとってはすべて自動的に起こることで、あなたはニュースグルー プにとても良く似た何かを見せられることになるでしょう。本当に寸分違わない、 ニュースグループのようなものを。記事を選択すると、それはいつものように記 事バッファーに表示されるでしょう。

ディレクトリーを表わしている行を選択すると、Gnus はいきなりあなたをこ の nneething グループのための新しい概略バッファーに連れて行くでしょ う。以下同様に、あなたがそうしたければ、この方法で全ディスクを駆け巡るこ とができます。ですが、Gnus は本当は dired ではないし、そのように意図され たものでもないことは覚えておいてください。

ここでの動作には二つの全体的なモードがあります--- 一時モードと固定モード です。一時的な操作を行なっているときは (すなわちグループバッファー で G D)、Gnus はどのファイルを読んだか、どのファイルが新しいか、な どの情報を憶えておきません。普通に G m で固定 nneething グ ループを作れば、Gnus は記事番号とファイル名の対応表を憶えておくので、こ のグループを他のグループと同様に扱うことができるようになります。固 定 nneething グループを活かすと、それが未読記事をいくつ含んでいる かを知らせてもらえる、等々の利便があります。

いくつかの変数があります:

nneething-map-file-directory
すべての固定 nneething グループの対応表が、このディレクトリーに格 納されます。このディフォルトは `~/.nneething/' です。

nneething-exclude-files
この正規表現に合致するファイルはすべて無視されます。自動保存ファイルなど を除外するのに便利に使えます。そしてそれがまさにディフォルトで行なわれる 動作です。

nneething-include-files
どのファイルをグループに含めるかを示す正規表現です。この変数 が nil でなければ、この正規表現に合致するファイルだけが含まれます。

nneething-map-file
対応表ファイルの名前です。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.6.3 文書グループ

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Document+Groups"
"gnus/文書グループ"へのコメント(無し)

nndoc は単一のファイルをニュースグループとして読むことをできるよ うにする、ちょっと気の利いたやつです。複数のファイルの種別がサポートされ ています:

babyl
Babyl 様式。

mbox
標準 Unix mbox ファイル。

mmdf
MMDF 形式のメールボックス。

news
一つのファイルにまとめられた複数のニュース記事。

rnews
rnews のバッチ転送形式。

nsmail
Netscape のメールボックス。

mime-parts
MIME のマルチパートのメッセージ。

standard-digest
標準 (RFC1153) のまとめ送り形式。

mime-digest
MIME のまとめ送りメッセージ。

lanl-gov-announce
ロスアラモス国立研究所 (LANL) Gov Announce からの発表メッセージ。

git
git で commit したことを伝えるメッセージ。

rfc822-forward
RFC822 で転送されたメッセージ。

outlook
Outlook のメールボックス。

oe-dbx
Outlook Express の dbx メールボックス。

exim-bounce
Exim MTA から跳ね返されたメッセージ。

forward
非公式の規則で転送されたメッセージ。

rfc934
RFC934 形式で転送されたメッセージ。

mailman
mailman のまとめ送り。

clari-briefs
Clarinet のニュース項目を要約したまとめ送り。

slack-digest
非標準まとめ送り形式---だいたいのものを扱えるが、下手。

mail-in-mail
最後の手段。

特別な「ファイル種別」である guess を使うこともできます。これを使 うと、見ているファイルの種別が何かを nndoc が推測しようとします。 また、digest というファイル種別は、そのファイルがどのまとめ送り形 式かを nndoc に推測させます。

nndoc はファイルを書き換えようとしたり、余分なヘッダーを挿入しよ うとしたりはしません---単に、ファイルをそのグループを作る元として使える ようにする、というようなことです。それだけのことです。

保存された古い記事を持っていて、それを新しくてかっこいい Gnus のメールバッ クエンドに追加したいなら、おそらく nndoc が助けになるはずです。例 えば新しい nnml グループに振り分けたいメールが、今は古 い `RMAIL' ファイルにメールがあるとしましょう。そういう場合は、その ファイルを nndoc を使って開き (グループバッファーで G f 命 令 (see 節 2.9 外部グループ) を使いましょう)、バッファー内の全記事にプロ セス印を (例えば M P b で) 付けてから、それらが nnml グルー プ群に振り分けられるように (B r 命令を使って) 再スプールしてくださ い。すべてがうまくいけば、`RMAIL' ファイル内のすべてのメールは、た くさんの nnml ディレクトリーの中にも格納されます。そうしたら、あ の厄介な `RMAIL' を削除してしまっても良いでしょう。あなたにガッツが あれば!

仮想サーバー変数:

nndoc-article-type
これは mbox, babyl, digest, news, rnews, mmdf, forward, rfc934, rfc822-forward, mime-parts, standard-digest, slack-digest, clari-briefs, nsmail, outlook, oe-dbx, mailman および mail-in-mail また は guess のいずれかでなくてはなりません。

nndoc-post-type
この変数は、そのグループをニュースグループとみなすかメールグループとみな すかを Gnus に伝えます。二つの有効な値は mail (ディフォルト) およ び news です。

6.6.3.1 文書サーバーの内部   


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.6.3.1 文書サーバーの内部

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Document+Server+Internals"
"gnus/文書サーバーの内部"へのコメント(無し)

nndoc で認識される新しい文書の種別を追加することは難しくありませ ん。その文書がどのように見えるかの定義を仕上げ、その文書種別を認識するた めの述語関数を書いて、nndoc を手なずけるだけで良いのです。

まず、これが文書の種別の定義の例です:

  
(mmdf
 (article-begin .  "^\^A\^A\^A\^A\n")
 (body-end .  "^\^A\^A\^A\^A\n"))

この定義は種別を示すためのユニークな名前 (name) と、それに続く仮想 的な変数名およびその設定値の単純な連なりからなります。以下が使うことがで きる変数です---変数の数に圧倒されないでください。ほとんどの文書の種別は、 ごくわずかな設定で定義することができます:

first-article
これが設定されていると、nndoc はこの正規表現に合致する何かが見つ かるまで、すべてのテキストを読み飛ばします。それより前のすべてのテキスト は完全に無視されます。

article-begin
この設定は、すべての文書の種別の定義に必ず存在しなければなりません。それ ぞれの記事の始まりがどのように見えるかを指定する正規表現です。単純な正規 表現では対処できないもっと複雑なことをしたい場合は、これの代わり に article-begin-function を使うことができます。

article-begin-function
これを設定する場合は、それぞれの記事の開始位置にポイントを移動させる関数 を指定してください。これは article-begin より優先されます。

head-begin
これを設定する場合は、記事のヘッダーの始まりに合致する正規表現を指定して ください。単純な正規表現では対処できないもっと複雑なことをしたい場合は、 これの代わりに head-begin-function を使うことができます。

head-begin-function
これを設定する場合は、記事のヘッダーの開始位置にポイントを移動させる関数 を指定してください。これは head-begin より優先されます。

head-end
これを設定する場合は、記事のヘッダーの最後に合致する正規表現を指定してく ださい。ディフォルトは `^$'、つまり空行です。

body-begin
これを設定する場合は、記事のボディーの始まりに合致する正規表現を指定して ください。ディフォルトは `^\n' です。単純な正規表現では対処できない もっと複雑なことをしたい場合は、これの代わり に body-begin-function を使うことができます。

body-begin-function
これを設定する場合は、記事のボディーの開始位置にポイントを移動させる関数 を指定してください。これは body-begin より優先されます。

body-end
これを設定する場合は、記事のボディーの最後に合致する正規表現を指定してく ださい。単純な正規表現では対処できないもっと複雑なことをしたい場合は、こ れの代わりに body-end-function を使うことができます。

body-end-function
これを設定する場合は、記事のボディーの最後の位置にポイントを移動させる関 数を指定してください。これは body-end より優先されます。

file-begin
これを設定する場合は、ファイルの始まりに合致する正規表現を指定してくださ い。それより前のすべてのテキストは完全に無視されます。

file-end
これを設定する場合は、ファイルの最後に合致する正規表現を指定してください。 それより後ろのすべてのテキストは完全に無視されます。

このように nndoc はこれらの変数を使って、文書ファイルをそれぞれヘッ ダーとボディーを持った記事の連なりとして切り分けることができます。しかし、 すべての文書の種別がこのようなニュース風になっているわけではないので、さ らにヘッダーやボディーを Gnus の趣味に合うように変形させる変数が、いくら か必要になります。

prepare-body-function
これに関数を設定しておくと、記事が要求されたときに呼び出されます。これは ボディーの開始位置のポイントを引数として呼び出され、文書にいくつかのエン コードされた内容物のパートがある場合に有用です。

article-transform-function
これに関数を設定しておくと、記事が要求されたときに呼び出されます。これは 記事のヘッダーとボディーの両方に、より広範囲な変形を行なうために使われる ものです。

generate-head-function
これに関数を設定しておくと、Gnus が理解できるヘッダーを生成するために呼 び出されます。これは記事番号をパラメーターとして呼び出され、その記事のた めの良質なヘッダーを生成することを求められます。すべての記事のヘッダーが 要求されるときに呼び出されます。

generate-article-function
これに関数を設定しておくと、Gnus が理解できる完全な記事を生成するために 呼び出されます。これはすべての記事のヘッダーが要求されるときに、記事番号 をパラメーターとして呼び出されます。

dissection-function
これに関数を設定しておくと、それだけを使って文書ファイルを記事に切り分け るために呼び出されます。これは first-article, article-begin, article-begin-function, head-begin, head-begin-function, head-end, body-begin, body-begin-function, body-end, body-end-function, file-begin および file-end より優先されます。

私が出会った中で最も複雑な例を見てください。標準まとめ送り形式のためのも のです:

  
(standard-digest
 (first-article . ,(concat "^" (make-string 70 ?-) "\n\n+"))
 (article-begin . ,(concat "\n\n" (make-string 30 ?-) "\n\n+"))
 (prepare-body-function . nndoc-unquote-dashes)
 (body-end-function . nndoc-digest-body-end)
 (head-end . "^ ?$")
 (body-begin . "^ ?\n")
 (file-end . "^End of .*digest.*[0-9].*\n\\*\\*\\|^End of.*Digest *$")
 (subtype digest guess))

70 文字のダッシュ (`-') の行より前はすべて無視されるというのが分かります ね。また `^End of' で始まる行より後ろもすべて無視されます。各記事 は 30 文字のダッシュの行で始まり、ヘッダーとボディーの区切りの行は一個の スペースを含むことがあり、そしてボディーはそれが渡される前 に nndoc-unquote-dashes を通されます。

あなた独自の文書のための定義を nndoc で使えるようにするには、 nndoc-add-type 関数を使ってください。これは二つのパラメーターをと ります--- 一つ目は定義そのもので、二つ目の (省略可能な) パラメーターは、 この定義を文書の種別を定義する連想リストのどこに置くかを指定します。この 連想リストは順番に走査され、与えられた種別 type に対し て nndoc-type-type-p が呼び出されます。したがって、例え ば mmdf という種別であるかどうかを調べるために は nndoc-mmdf-type-p が呼び出され、他の種別の場合も同様です。これ らの種別述語関数は、文書がその種別でない場合は nil を返し、その種 別である場合は t を返し、その種別かもしれないときは数値を返さなく てはなりません。高い数値は高い可能性を意味し、低い数値は低い可能性を意味 します。`0' は正しい値の中でもっとも低い数値です。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.6.4 メールからニュースへのゲートウェイ

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Mail%2DTo%2DNews+Gateways"
"gnus/メールからニュースへのゲートウェイ"へのコメント(無し)

あなたのローカルの nntp サーバーが何らかの理由で投稿を許可してい なくても、数ある mail-to-news ゲートウェイを使って投稿することができます。 nngateway バックエンドはこのインターフェースを提供します。

このバックエンドからは何も読み出せないことに注意してください---これは投 稿するためだけに使われます。

以下はサーバー変数です。

nngateway-address
これが mail-to-news ゲートウェイのアドレスです。

nngateway-header-transformation
ニュースヘッダーは、mail-to-news ゲートウェイが受け付けられるように、何 か奇妙なやり方で変形しておかなければならないことがしばしばです。この変数 はどんな変形処理が呼び出されるべきかを指示するもので、ディフォルトで は nngateway-simple-header-transformation になります。その関数は 変形しようとするヘッダーの領域だけに狭められたバッファーで、ゲートウェイ のアドレスを一つの引数として呼び出されます。

ディフォルトの関数は、単に Newsgroups ヘッダーとゲートウェイのア ドレスに基づいた新しい To ヘッダーを挿入します。例えば、以下のよ うな Newsgroups ヘッダーを持つ記事には、

  
Newsgroups: alt.religion.emacs

次のような To ヘッダーが挿入されます。

  
To: alt-religion-emacs@GATEWAY

以下の関数が用意されています:

nngateway-simple-header-transformation
newsgroup@nngateway-address のような To ヘッダーを 作ります。

nngateway-mail2news-header-transformation
nngateway-address のような To ヘッダーを作ります。

例です:

  
(setq gnus-post-method
      '(nngateway
        "[email protected]"
        (nngateway-header-transformation
         nngateway-mail2news-header-transformation)))

したがってこれを使うには、単にこんな風にすれば良いでしょう:

  
(setq gnus-post-method '(nngateway "GATEWAY.ADDRESS"))


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.6.5 空っぽのバックエンド

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=The+Empty+Backend"
"gnus/空っぽのバックエンド"へのコメント(無し)

実際は必要が無いのにどこかにバックエンドを設定しなければならない場合に、 nnnil は代用として使うことができるバックエンドです。典型的な例は、 第一の選択方法を必要としないが第二の (secondary) 選択方法だけを使いたい 場合です:

  
(setq gnus-select-method '(nnnil ""))
(setq gnus-secondary-select-methods
      '((nnimap "foo")
        (nnml "")))


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.7 合併グループ

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Combined+Groups"
"gnus/合併グループ"へのコメント(無し)

Gnus は、すべてのグループの種類を混合して、大きなグループに合併させるこ とができます。

6.7.1 仮想グループ   


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.7.1 仮想グループ

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Virtual+Groups"
"gnus/仮想グループ"へのコメント(無し)

nnvirtual グループは、実は複数のグループを寄せ集めたものに過ぎませ ん。

例えば、小さなグループをたくさん読むのが嫌になってきたら、それらを一つの 大きなグループに入れて、嫌になるくらい巨大で手に負えないグループを読むこ とができます。これはコンピューティングの醍醐味だね!

選択方法として nnvirtual を指定してください。アドレスは、それを構 成するグループに合致する正規表現です。

仮想グループで付けられたすべての印は、その構成要素のグループの記事にくっ つけられます。つまり、仮想グループで記事に可視記事の印を付けると、その記 事はもともとの構成要素のグループでも可視記事になります。(そして逆も成り 立ちます---構成要素のグループで付けた印は、仮想グループでも表示されま す。) 空の仮想グループを作るには、グループバッファーで G V (gnus-group-make-empty-virtual) を実行し、M-e (gnus-group-edit-group-method) で選択方法の正規表現を編集してくだ さい。

これが、Andrea Dworkin に関するすべてのニュースグループを、一つの巨大で シアワセなニュースグループにまとめる nnvirtual 選択方法の例です:

  
(nnvirtual "^alt\\.fan\\.andrea-dworkin$\\|^rec\\.dworkin.*")

構成要素のグループは基本グループでも外部グループでも構いません。すべて問 題無く動くはずですが、もしあなたのコンピューターが爆発でもしてしまったら、 それはたぶん私が悪いんでしょうね。

利用者が (訳注: 記事を投稿する人たちが) Distribution ヘッダーを使って配 布範囲を制限している場合に、同じグループを複数のサーバーから寄せ集めるこ とは、本当にうまい考えかもしれません。`soc.motss' を日本のサーバー とノルウェーのサーバーの両方から読みたければ、グループの正規表現として以 下のものを使うことができるでしょう:

  
"^nntp\\+server\\.jp:soc\\.motss$\\|^nntp\\+server\\.no:soc\\.motss$"

(でもちょっと注意。G m でグループを作成するときは、バックスラッシュ を二重に付けてはいけません。そして文字列の最初と最後の引用記 号 (`"..."') も取り払ってください。)

これはまあ、すらすらと動作するはずです---両方のグループのすべての記事は 一つのグループに入り、重複も無いはずです。スレッド表示 (とその他) も通常 通り動作するでしょうけれど、記事の並ぶ順序には問題があるかもしれません。 日付による並べ替えが、ここでは一つの選択肢になるかもしれませ ん (see 節 2.3 グループの選択)。

なお、ここで一つだけ制限があります---仮想グループに含まれるグループはす べて生きている (すなわち購読または非購読の) 状態でなくてはなりません。削 除された (killed) グループあるいはゾンビのグループは nnvirtual グ ループを構成するグループになることはできません。

nnvirtual-always-rescan 変数が nil でなけれ ば (それ、つまり非-nil がディフォルト)、nnvirtual は仮想グ ループに入ったときに常に未読記事を走査します。この変数が nil になっ ていて、仮想グループを作った後に構成要素のグループで記事を読んだ場合は、 その構成要素のグループで読まれた記事は、仮想グループに現れてしまうでしょ う。共通な構成要素のグループを持つ二つの仮想グループがある場合にも、この 影響があります。そういう場合には、この変数を t にするべきです。さ もなければ、仮想グループに入る度に、毎回その仮想グループの上 で M-g を叩いても良いでしょう---これにはほぼ同様の効果があります。

nnvirtual はメールとニュースの両方のグループを構成要素のグループ にすることができます。nnvirtual グループの記事に返答するときは、 nnvirtual は記事の出所の構成要素のグループのバックエンドに、それ がニュースのバックエンドであるかメールのバックエンドであるかを尋ねなけれ ばなりません。しかし ^ をしたときには、普通は構成要素のバックエン ドがこれを知るための確実な方法が無いので、その場合 nnvirtual は、 Gnus に記事はニュースではないバックエンドからやって来たと告げます。(単に それが安全な側なので。)

これらの場合にメッセージバッファーで C-c C-n を行なうと、応答しよ うとしている記事から Newsgroups 行を抜き出して挿入します。

nnvirtual グループは、記事と印以外は構成要素のグループから継承し ません---例えばグループパラメーターもそうなのですが、それらは継承されま せん。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.8 電子メールによる日程管理

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Email+Based+Diary"
"gnus/電子メールによる日程管理"へのコメント(無し)

この章では nndiary という特別なメールバックエンドと、その仲間 の gnus-diary ライブラリーについて説明します。それが「特別」なの は、Gnus でメールを読むための標準の選択肢の一つであるつもりは無いからで す。それ (標準の選択肢) については 6.4.13 メールバックエンドを選ぶ を参照 してください。代わりに、特別な方法であなたのメールの いくつか を扱 う、すなわちこれはリマインダー (予定を思い出させるもの) として使われます。

典型的な筋書きは、こうです。

Gnus Diary バックエンドは、(常に取り消されることが無い) 定期的な予定を、 几帳面な人たちと同じように扱う能力を持っていて、本当のメールバックエンド のように動作し、いろんなやり方で設定することができます。このすべてが、以 下の各章で説明されています。

6.8.1 NNDiary バックエンド    基本的な設定と使い方
6.8.2 Gnus Diary ライブラリー    nndiary の上位階層にある実用的なツールキット
6.8.3 送信するべきか、しないべきか   


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.8.1 NNDiary バックエンド

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=The+NNDiary+Back+End"
"gnus/NNDiaryバックエンド"へのコメント(無し)

nndiary は nnml (see 節 6.4.13.3 メールスプール) にとてもよく似ている バックエンドです。現にそれは nnml と nndraft を合わせたも のに見えるでしょう。nnml をご存知ならば、あなたはすで に nndiary がメッセージを格納する仕組み (一通あたり一つのファイル、 一グループあたり一つのディレクトリー) に精通しています。

何はさておき、nndiary をちゃんと動作させるには、一つの要件があり ます: Gnus のグループの日付の機能を 使わなければなりません。それ がどういうふうに行なわれるかは 2.18.3 グループの日付 を見てください。

6.8.1.1 日程メッセージ    メッセージを nndiary で使えるようにするには
6.8.1.2 NNDiary を動かす   
6.8.1.3 NNDiary のカスタマイズ    ベルとホイッスル


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.8.1.1 日程メッセージ

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Diary+Messages"
"gnus/日程メッセージ"へのコメント(無し)

七つの特別なヘッダーが必須であること以外、nndiary のメッセージは まったく普通のものです。それらのヘッダーは X-Diary- の 様式で表され、 の部分は Minute, Hour, Dom, Month, Year, Time-Zone およ び Dow のうちの一つです。Dom は「日 (Day of Month)」を、 Dow は「曜日 (Day ofWeek)」を意味します。これらのヘッダー は crontab の設定のように働いて、予定日を定義します。

1999年から 2010年までの毎週月曜日と毎月の一日の 12:00, 20:00, 21:00, 22:00, 23:00 および 24:00 を設定するために、メッセージに加える日程ヘッダー の具体例です (その時何をしたら良いかは、自分で考えてください):

  
X-Diary-Minute: 0
X-Diary-Hour: 12, 20-24
X-Diary-Dom: 1
X-Diary-Month: *
X-Diary-Year: 1999-2010
X-Diary-Dow: 1
X-Diary-Time-Zone: *


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.8.1.2 NNDiary を動かす

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Running+NNDiary"
"gnus/NNDiaryを動かす"へのコメント(無し)

nndiary には二つの動作モードがあります。一つはディフォルトの 「伝統型 (traditional)」、もう一つは「自律型 (autonomous)」です。伝統型 のモードでは、nndiary はそれ自身が新着メールを取得することはあり ません。日程メッセージとして扱うために、あなたはメールを基本のメールバッ クエンドから nndiary グループに、移動 (B m) またはコ ピー (B c) しなければなりません。自律型のモードでは、 nndiary はそれ自身のメールを取ってきて、基本のメールバックエンド とは独立してそれを扱います。

本質的に Gnus は、同時に複数の「マスター」メールバックエンドを許容するよ うには設計されていなことに注意すべきです。しかし nndiary では、こ れは意味をなします。あなたは本当に、日程メッセージを日程グループに直接送っ て、それらを受け取りたいのです。そこで nndiary は、まさに「二番目 の第一メールバックエンド」をサポートします (私が知っている限り、それはこ の機能を提供する唯一のバックエンドです)。しかしながら制約があって (いつ の日にか解消することを願いますが)、自律型のモードでは再スプールができま せん。

自律型のモードで nndiary を使うためには、いくつかのことをやっても らわなければなりません:

いったんこれを実施したら、日程メールの取り込みと分割の処理に影響する、以 下の二つのオプションをカスタマイズする必要があるでしょう:

Variable: nndiary-mail-sources
標準の mail-sources 変数の、日程用に特化した代替品です。同じ構 文 (syntax) を使い、ディフォルトは (file :path "~/.nndiary") で す。

Variable: nndiary-split-methods
標準の nnmail-split-methods 変数の、日程用に特化した代替品です。 同じ構文 (syntax) を使います。

最終的には gnus-secondary-select-methods に、恒久的 な nndiary 仮想サーバー ((nndiary "diary") が行なうべきで あるようなもの) を追加しても良いでしょう。

うまくいけば、Gnus を再起動すると、ほとんどすべ て (`nndiary.el' の TODO の項を参照) が期待通りに動作するでしょう。 自律型のモードでは、g や M-g をグループバッファーでタイプす れば新しい日程メールをも取り込んで、日程用に特化した規則に従ってそれらを 分割するし、F は新しい日程グループを見つけてくれる、など。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.8.1.3 NNDiary のカスタマイズ

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Customizing+NNDiary"
"gnus/NNDiaryのカスタマイズ"へのコメント(無し)

さあ nndiary が立ち上がって動作しています。それをカスタマイズする ときが来ました。カスタマイズするためのグループは nndiary です (へ えー)。どのオプションをカスタマイズし倒したいかを見つけるために、それに 目を通してください。あなたが変更したいのは、おそらく以下のたった二つの変 数でしょう:

Variable: nndiary-reminders
予定を思い出させてもらいたい時刻のリスト (例えば三週間前、それから二日前、 それから一時間前、そしてそのとき) です。「思い出させてもらう」の意味は、 新着メールを取り込んだときに、日程メッセージが真新しく未読になって、ポッ プアップすることであることを思い出してください。

Variable: nndiary-week-starts-on-monday
読んで字の如し。さもなくば日曜日が仮定されます (それがディフォルトです)。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.8.2 Gnus Diary ライブラリー

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=The+Gnus+Diary+Library"
"gnus/GnusDiaryライブラリー"へのコメント(無し)

nndiary を手作業で使うこと (ヘッダーを手で書くことなど) は、いさ さかうんざりします。幸い nndiary の上位階層に書かれ た gnus-diary というライブラリーがあって、たくさんの便利なことを やってくれます。

それを使うためには、以下の行を `~/.gnus.el' ファイルに加えてくださ い:

  
(require 'gnus-diary)

さらに、どんな gnus-user-format-function-[d|D] (see 節 3.1.1 概略バッファーの行) も、使ってはいけません。gnus-diary はそれらの両方 を提供します (あなたがそれらを使っていたら、すみません)。

6.8.2.1 日程の概略行仕様   
6.8.2.2 日程記事の並べ替え   
6.8.2.3 日程ヘッダーの生成   
6.8.2.4 日程グループのパラメーター   


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.8.2.1 日程の概略行仕様

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Diary+Summary+Line+Format"
"gnus/日程の概略行仕様"へのコメント(無し)

標準の概略行仕様 (通常 `From Joe: Subject' のようなもの) で日程メッ セージを表示するのは、まったく役に立ちません。たいていはあなたがメッセー ジを書いた人で、おおかた予定の日付を見たいと思っているでしょう。

gnus-diary は、概略行仕様で使う二つの追加の利用者定義の書法仕様を 提供します。D は次の予定が生じるときのための整形された時刻表 示 (例えば“Sat, Sep 22 01, 12:00”) を表すのに対して、d は次の予 定が生じるまでのおおよその残り時間 (例えば“in 6 months, 1 week”) を表 します。

ジョーの誕生日が、概略行にどう表示されるかの例です (定期的な予定を指定す ると消されないことを除いて、メッセージが期限切れ消去可能であることに気を 付けてください):

  
   E  Sat, Sep 22 01, 12:00: Joe's birthday (in 6 months, 1 week)

上記のようなものを得るために、普段だったら、あなたは以下の行を日程グルー プのパラメーターに加えようとするでしょう:

  
(gnus-summary-line-format "%U%R%z %uD: %(%s%) (%ud)\n")

しかし gnus-diary はそれを自動で行ないます (see 節 6.8.2.4 日程グループのパラメーター)。それでもあなたは、以下のユーザー・オプション群で提供される 概略行仕様を、カスタマイズすることができます:

Variable: gnus-diary-summary-line-format
日程グループのために使われる概略行仕様を定義します (see 節 3.1.1 概略バッファーの行)。gnus-diary はそれを、日程グループのパラメーターを 自動で更新するために使います。

Variable: gnus-diary-time-format
日程の概略バッファーに日付を表示するための書法仕様を定義します。これは利 用者定義の書法仕様 D で使われます。詳細は変数の説明文を見てくださ い。

Variable: gnus-diary-delay-format-function
日程の概略バッファーに遅延 (残り時間) を表示するための整形関数を定義しま す。これは利用者定義の書法仕様 d で使われます。現在は英語とフラン ス語のための組み込み関数があり、自分で定義することもできます。詳細は変数 の説明文を見てください。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.8.2.2 日程記事の並べ替え

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Diary+Articles+Sorting"
"gnus/日程記事の並べ替え"へのコメント(無し)

gnus-diary は並べ替え (see 節 3.10 並べ替え) のため に gnus-summary-sort-by-schedule、 gnus-thread-sort-by-schedule およ び gnus-article-sort-by-schedule という新しい関数を提供します。こ れらの関数によって、最も近い予定から最も遠い方まで、日程の概略バッファー を整理することができます。

gnus-diary は自動的に概略バッファーの「並べ替え (sort)」メニュー に gnus-summary-sort-by-schedule を組み込み、他の二つを第一次 の (ゆえにディフォルトの) 並べ替え関数として、グループパラメー ター (see 節 6.8.2.4 日程グループのパラメーター) に登録します。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.8.2.3 日程ヘッダーの生成

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Diary+Headers+Generation"
"gnus/日程ヘッダーの生成"へのコメント(無し)

gnus-diary は、X-Diary-* ヘッダーの取り扱いを補佐するため に、gnus-diary-check-message という関数を提供します。この関数は、 現在のメッセージがすべての必要な日程ヘッダーを確実に含むようにして、必要 ならば値を入力するか修正することを要求します。

記事を日程グループに移動またはコピーすることによって自動的にそれが発動さ れるようにするために、この関数は nndiary バックエンドのフックとし て組み入れられています。それはさらに、通常のメールを日程用のものに変換す る操作を簡単にするために、 message-mode と article-edit-mode におい て C-c C-f d キーとして設定もされています。

接頭引数を伴ってこの関数を呼ぶと、それらがあるか、正しいかどうかとは無関 係に、日程ヘッダーの入力を強制します。そうやって、例えばすでに正しく設定 されたメッセージの日程を、とても簡単に変更することができます。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.8.2.4 日程グループのパラメーター

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Diary+Group+Parameters"
"gnus/日程グループのパラメーター"へのコメント(無し)

新しい日程グループを作るか、またはそれを開くと、gnus-diary は自動 的にグループパラメーターを検査し、必要なら概略行仕様を日程用に特化した値 に設定し、日程用の並べ替え関数を組み込み、さらにそのグループの投稿様 式 (posting-style) に種々の X-Diary-* ヘッダーを加えます。そして、 日程メッセージを送るのは、もっと簡単です。メッセージを用意するために、日 程グループで C-u a か C-u m を使うことによって、これらのヘッ ダーが自動的に挿入されるので (まだ適切な値で満たされていませんが)。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.8.3 送信するべきか、しないべきか

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Sending+or+Not+Sending"
"gnus/送信するべきか、しないべきか"へのコメント(無し)

さて、以上の説明をすべて読んでくれたものとして、以下は nndiary で メールを送信することに関する、二つの最後の注意事項です:


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.9 Gnus の切り離し

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Gnus+Unplugged"
"gnus/Gnusの切り離し"へのコメント(無し)

いにしえの時代 (およそ 1988年2月頃)、人々はニュースリーダーをネットワー クに常時接続した大きなマシンで走らせていました。ニュースの配送はニュース サーバーによって取り扱われ、すべてのニュースリーダーがすべきことはニュー スを読むことであったのです。信じられないかもしれませんが。

今日では多くの人々は自宅でニュースやメールを読み、ネットワークに接続する ためにモデムの類を使います。電話代の請求書が莫大なものに上らないように、 すべてのニュースとメールをすすり込んで電話を切り、数時間かけて読んでから 送りたい返信をすべて送信する、という手段を持つことは良いことでしょう。あ とはこの手順を繰り返すのです。(訳注: この章の前身は 1997年頃に書かれまし た。)

もちろん、これを行なうためにニュースサーバーを使うこともできます。私 は inn を slurp, pop, sendmail と一緒にここ 数年使ってきましたが、しかしこれは退屈な仕事です。もしあるマシン上でニュー スを読む人があなたしかいなければ、ニュースサーバーの機能をニュースリーダー に任せるようにすることは理にかなっています。

Gnus を「オフライン」のニュースリーダーとして仕立てるのは極めて簡単です。 実際、エージェントは今やディフォルトで有効になっている (see 節 gnus-agent) ので、あなたは何も設定する必要が無いのです。

もちろん、これをそんなふうに使うには、いくつか新しい命令を覚えなくてはな りません。

6.9.1 エージェントの基礎   
6.9.2 エージェント分類    何をダウンロードするかを Gnus エージェントに教える方法
6.9.3 エージェント命令   
6.9.4 エージェントの視覚効果   
6.9.5 キャッシュとしてのエージェント   
6.9.6 エージェント期限切れ消去   
6.9.7 エージェントを作り直す   
6.9.8 エージェントとフラグ   
6.9.9 エージェントを IMAP で使う方法    エージェントを IMAP で使う方法
6.9.10 差出用メッセージ   
6.9.11 エージェント変数   
6.9.12 設定例    オフライン人間のための `~/.gnus.el' の例
6.9.13 一括エージェント処理    cron ジョブでニュースを取得する方法
6.9.14 エージェントの問題点   


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.9.1 エージェントの基礎

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Agent+Basics"
"gnus/エージェントの基礎"へのコメント(無し)

まず、いくつかの用語を片付けておきましょう。

ネットワークとの接続を切っているとき (かつエージェントにそのことを知らせ てあるとき)、Gnus エージェントは unplugged です、と言います。ネッ トワークとの接続が復活したら (かつ Gnus がそのことを知っていれば)、エー ジェントは plugged です。

「ローカル」マシンとは、あなたがそこで作業しているもので、継続的にネット ワークに接続されているわけではありません。

「ダウンロード」とは、あなたのローカルマシンに、何かをネットワークから取っ てくることを意味します。「アップロード」はその逆をすることです。

ご存知のように Gnus はあなたがドジを踏むすべての機会を提供します。それを 柔軟性と言う人もいます。さらに Gnus は大いにカスタマイズ可能で、それは利 用者が、Gnus がどのように動作するかについて発言権を持っていることを意味 します。他のニュースリーダーは有無を言わずあなたにドジを踏ませるかもしれ ませんが、Gnus ではあなたに選択権があります!

Gnus は実際には plugged または unplugged のどちらの状態にもありません。 もっと正確に言えば、サーバーごとにそれぞれの状態を持ちます。これは、いく つかのサーバーが unplugged でも、他のサーバーは plugged になることができ るということです。さらに、エージェントがいくつかのサーバーをまとめて無視 する (それらを常に plugged になっているように見せかける) ようにもできま す。

さて、エージェントを unplugged にしたのに Gnus がネットに接続しているの を疑問に思ったら、行なうべき次のステップはサーバーがすべてエージェント化 されているかどうかを確かめることです。エージェント化されていないサーバー があったら、あなたは犯人を見つけたのです。

もう一つは「オフライン」という状態です。サーバーはときどき接続できなくな ります。Gnus がこのことに気付くと、そのサーバーをオフラインの状態に切り 換えても良いかどうかを尋ねます。Yes と答えたならば (オンラインに戻して良 いかと Gnus が尋ねた場合以外は)、サーバーはいくらか unplugged だったとき のように振る舞います。

エージェントを使った典型的な Gnus の対話操作を見てみましょう:

エージェントを初めて使うときは (またはそのくらいの時期に)、以下のいくつ かの作業をしなければなりません。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.9.2 エージェント分類

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Agent+Categories"
"gnus/エージェント分類"へのコメント(無し)

ニュースを配送する機構をニュースリーダーに統合する主要な理由の一つは、ど の記事をダウンロードするかについて、もっと強力に制御できるようにすること です。莫大な量の記事をダウンロードすることにあまり意味はなく、それらを読 んでもあまり面白くないことが分かるだけです。何をダウンロードするかの選択 ではもう少し保守的になって、その記事がやっぱり面白そうだとわかったら、主 動でダウンロードするための印を付ける方がすぐれています。

何をダウンロードするかを制御するためのより有効な方法の一つは、分 類 (category) を作成して、その分類にいくつか (または全部) のグルー プを割り当てることです。どんな分類にも属さないグループは「ディフォルト」 の分類に属します。Gnus は分類の作成と管理のための独自のバッファーを持っ ています。

もしそうしたければ、グループパラメーター (see 節 2.10 グループパラメーター) とト ピックパラメーター (see 節 2.16.5 トピックパラメーター) を、エージェントを制御する 代替手段に使うことができます。実際に違うのは、グループとトピックパラメー ターが何でもかんでも (kitchen sink) 含むのに対して、分類はエージェントに 特化している (したがってあまり学ばなくても良い) ということだけです。

エージェントパラメーターは複数の違う場所で設定することができるので、どの ソースが信用できるかを決めるための規則を設けました。この規則は、パラメー ターのソースが次の順序で調べられることを定めます: グループパラメーター、 トピックパラメーター、エージェント分類、そして最後はカスタマイズできる変 数群です。したがって、広い範囲で動作を起こさせるためにこれらのソースをす べて混合することができます。どこに設定を置いたのかを忘れてしまったからと いって、私を責めないでくださいよ。

6.9.2.1 分類の文法   
6.9.2.2 分類バッファー   
6.9.2.3 分類変数   


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.9.2.1 分類の文法

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Category+Syntax"
"gnus/分類の文法"へのコメント(無し)

分類は、名前、その分類に属するグループのリスト、およびカスタマイズ可能な 変数よりも優先される多くの任意なパラメーターから成ります。エージェントパ ラメーターの完全なリストを以下に示します。

agent-groups
この分類にあるグループのリスト。

agent-predicate
(通常) どの記事をダウンロードするのが適当かという大まかな輪郭を与える述 語。そして

agent-score
(通常) どの記事をダウンロードするかを決めるときのよりきめの細かいスコア 規則。(このダウンロードスコア (download score) は通常のスコアとは 必ずしも関係が無いことに注意してください。)

agent-enable-expiration
このグループの古い記事をエージェントが期限切れ消去すべきかどうかを示す ブール変数。大抵のグループはディスク空間を浪費しないために期限切れ消去さ れるべきです。いや、実際には gnus.* 階層は期限切れ消去されるべきではな いグループだけを含んでいると言っても、たぶん差し支えありません。

agent-days-until-old
既読の記事を期限切れ消去しても差し支えないことを判断する前に、エージェン トが待っているべき日数を示す整数。

agent-low-score
gnus-agent-low-score よりも優先される整数。

agent-high-score
gnus-agent-high-score よりも優先される整数。

agent-short-article
gnus-agent-short-article よりも優先される整数。

agent-long-article
gnus-agent-long-article よりも優先される整数。

agent-enable-undownloaded-faces
ダウンロードされていない記事 を gnus-summary-*-undownloaded-face のフェース群を使って概略バッ ファーに表示すべきかどうかを示すシンボル。nil 以外ならどんなシン ボルでも、ダウンロードされていない記事用のフェースを使うようになります。

いったん分類が作られたら、分類の名前を変えることはできません。

それぞれの分類は、その分類の排他的な (他の分類には無い) メンバーであるグ ループのリストを維持します。排他規則は自動的に執行され、新しい分類にグルー プを追加すると、それは古い分類から自動的に取り除かれます。

述語の一番単純な形式は true や false のような単独の述語か らなります。これらの二つはそれぞれ、すべての可能な記事をダウンロードする か、まったく何もしないか、です。これらの二つの特別な述語の場合は、追加の スコア規則は不要です。

high や low という述語は下で説明されているように、 gnus-agent-high-score と gnus-agent-low-score との記事のス コアとの関係により記事をダウンロードします。

何をもってダウンロードすることが適格だと見なされるかについて、さらに細か い制御を得るために、述語は論理演算子が間に散りばめられた述語の組み合わせ からなることができます。

おそらくいくつかの例が必要でしょう。

以下は簡単な述語です。(これはディフォルトの述語です。実際に他のどの分類 にも含まれないすべてのグループに対して使用されます。)

  
short

とっても簡単でしょ? この述語は、記事が短い (「短い」ことを意味する何らか の価値がある) 場合に限り真になります。

これはもっと複雑な述語です:

  
(or high
    (and
     (not low)
     (not long)))

この意味は、高いスコアを持っているか、あるいはスコアが低くなくてかつ長く ない、という記事をダウンロードする、ということです。様子はわかりましたね。

使ってもよい論理演算子は or, and および not です。 (もし使いたければ、より“C”風の演算子 `|', &, ! を代 りに使うことができます。)

以下の述語があらかじめ定義されていますが、これらのどれもあなたのやりたい ことに適さなければ、自分で独自のものを書くこともできます。

それぞれのこれらの述語を評価するとき、名前が付けられた定数は、適切なパラ メーターを与えて gnus-agent-find-parameter を呼ぶことによって決定 される値に束縛されます。例え ば gnus-agent-short-article は (gnus-agent-find-parameter group 'agent-short-article) に束縛されます。これは、あなたの分類で述語を指定 してから、その述語を個々のグループについて調整できることを意味します。

short
記事が gnus-agent-short-article の行数より短かければ真です。ディ フォルトは 100 です。

long
記事が gnus-agent-long-article の行数より長ければ真です。ディフォ ルトは 200 です。

low
記事のダウンロードスコアが gnus-agent-low-score の値より小さけれ ば真です。ディフォルトは 0 です。

high
記事のダウンロードスコアが gnus-agent-high-score の値より大きけれ ば真です。ディフォルトは 0 です。

spam
Gnus エージェントがその記事を spam だと推測した場合に真です。この検出法 は今後変更されるかもしれませんが。現時点では、これはチェックサムを計算し、 記事が一致するかどうかを調べているだけです。

true
常に真です。

false
常に偽です。

独自の述語関数を作成したければ、このことを知っておかなければなりませ ん: 関数は引数無しで呼び出されますが、 gnus-headers と gnus-score という動的な変数が有意な値に束 縛されるということを。

例えば、一定の日数以上前に投稿された記事 (例え ば gnus-agent-expire-days の日数以上前に投稿されたもの) をダウン ロードしないと決断することもできます。その場合、以下のような関数を書いて、

  
(defun my-article-old-p ()
  "Say whether an article is old."
  (< (time-to-days (date-to-time (mail-header-date gnus-headers)))
     (- (time-to-days (current-time)) gnus-agent-expire-days)))

そして述語はこのように定義すれば良いでしょう:

  
(not my-article-old-p)

もしくは `~/.gnus.el' か何かで、あらかじめ定義されてい る gnus-category-predicate-list の値に、自分の述語を追加すること もできます。

  
(require 'gnus-agent)
(setq gnus-category-predicate-alist
      (append gnus-category-predicate-alist
              '((old . my-article-old-p))))

この場合は、次のように述語を指定するだけです:

  
(not old)

上のようなものを使うときは、世の中には正しく設定されていないシステム/メー ラーがあり、記事の日付はいつ投稿されたかを常に確実に示すわけではないこと を知っていてください。困ったことに、それを少しも気にかけない人もいるんで す。

上記の述語はその分類に属する すべて のグループに適用されます。し かし、分類中の個々のグループのための特定の述語を設定したかったり、単に不 精を決め込んで新しい分類を設定したくないのならば、グループの個々の述語を 次のようにグループパラメーターに入れることができます:

  
(agent-predicate . short)

これは agent 分類のディフォルトと等価なグループ/トピックパラメーターです。 このように単一の語で述語を指定するときは、agent-predicate の設定 値はドット対で表記しなければならないことに注意してください。

上のものと等価な長い方の例はこうなるでしょう:

  
(agent-predicate or high (and (not low) (not long)))

述語の値がドット対で表記されていなくて、その値はリストだと仮定されるので、 分類の設定で要求される外側の括弧が、ここでは入れられません。

さて、ダウンロードスコアの文法は通常のスコアファイルの文法と同じですが、 例外があります。記事そのものを実際に調べる必要がある要素は厳禁です。つま り、以下のヘッダーだけがスコア付けできるということです: Subject, From, Date, Message-ID, References, Chars, Lines および Xref。

述語の場合のように、ダウンロードスコア規則 の設定は、それをグルー プに関して使う限りは、そこのすべてのグループに適用できるものならば分類の 定義、グループに特有ならばグループパラメーター、のどちらかにできます。

これら両方の場所で、ダウンロードスコア規則 は以下の三つの形式の一 つを取ることができます:

  1. スコア規則

    上で書かれているように、スコア付けキーワードの一部分しか使えないことを除 けば、これは普通の Gnus スコアファイルの構文と同じです。

    例:

  2. エージェントスコアファイル

    これらのスコアファイルは、上で述べられている使用可能なスコア付けキーワー ド だけ を含んでいなければなりません。

    例:

  3. 普通 のスコアファイルの使用

    あるグループのためにあなたが望んだ「ダウンロード」の基準が、「読む」基準 と同じならば、一つのグループのために二つのスコア規則を維持管理したいとは 思わないでしょう。そういう場合は、何をダウンロードするかを決める際に、エー ジェントに 普通 のスコアファイルを参照させることができます。

    分類の定義やグループパラメーターでこれらの指示を行なうと、エージェントは あるグループに適用することができるすべてのスコアファイルを読み込んで、使 うことが許されているスコア付けキーワードの副セットではない項目 を 選別して取り除きます。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.9.2.2 分類バッファー

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Category+Buffer"
"gnus/分類バッファー"へのコメント(無し)

通常すべての分類は分類バッファーから管理します。これに (グループバッファー で J c 命令を使って) 初めて入ると、ディフォルトの分類だけが表示さ れます。

このバッファーでは以下の命令を使うことができます:

q
グループバッファーに戻ります (gnus-category-exit)。

e
選択された分類のパラメーターを一括して設定するために、カスタマイズバッファー を使います (gnus-category-customize-category)。

k
現在の分類を消去します (gnus-category-kill)。

c
現在の分類を複製します (gnus-category-copy)。

a
新しい分類を追加します (gnus-category-add)。

p
現在の分類の述語を編集します (gnus-category-edit-predicate)。

g
現在の分類に属するグループのリストを編集しま す (gnus-category-edit-groups)。

s
現在の分類のダウンロードスコア規則を編集しま す (gnus-category-edit-score)。

l
すべての分類を表示します (gnus-category-list)。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.9.2.3 分類変数

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Category+Variables"
"gnus/分類変数"へのコメント(無し)

gnus-category-mode-hook
分類バッファーで実行するフックです。

gnus-category-line-format
分類バッファーの行様式です (see 節 9.4 書法仕様変数)。有効な要素は:

`c'
分類の名前です。

`g'
その分類に属するグループの数です。

gnus-category-mode-line-format
分類モード行の様式です (see 節 9.4.2 モード行書法仕様)。

gnus-agent-short-article
この値より少ない行数の記事は短いと見なします。ディフォルトは 100 です。

gnus-agent-long-article
この値より多い行数の記事は長いと見なします。ディフォルトは 200 です。

gnus-agent-low-score
この値より小さいスコアを持つ記事は低スコアだと見なします。ディフォルト は 0 です。

gnus-agent-high-score
この値より大きいスコアを持つ記事は高スコアだと見なします。ディフォルト は 0 です。

gnus-agent-expire-days
期限切れ消去する前に、既読記事をエージェントのローカルディスクに留めてお かなければならない日数 (「期限切れ消去」という名前は同じですが、サーバー で期限切れ消去することではありません。単に記事のローカルな複製を消すこと を意味します)。さらに理解すべき大事なことは、記事が読まれた時ではなくロー カルディスクに記事が書かれた時から計数が始まるということです。ディフォル トは 7日です。

gnus-agent-enable-expiration
グループの記事が、ディフォルトで期限切れ消去されるか、無期限に保持される かを決定します。ディフォルトは ENABLE で、あなたが望むならば期限 切れ消去をさせないようにしなければならないことを意味します。一方、これ を DISABLE に設定することができます。その場合、選択されたグループ での期限切れ消去を有効にしなければなりません。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.9.3 エージェント命令

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Agent+Commands"
"gnus/エージェント命令"へのコメント(無し)

すべての Gnus エージェント命令は J サブマップにあります。 J j (gnus-agent-toggle-plugged) 命令はすべてのモードで動作 し、Gnus エージェントの plugged/unplugged 状態を切り替えます。

6.9.3.1 グループエージェント命令   
6.9.3.2 概略エージェント命令   
6.9.3.3 サーバーエージェント命令   


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.9.3.1 グループエージェント命令

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Group+Agent+Commands"
"gnus/グループエージェント命令"へのコメント(無し)

J u
現在のグループの適格な (訳注: あなたが指定した条件に合致する) 記事をすべ て取得します (gnus-agent-fetch-groups)。

J c
エージェント分類バッファーに入ります (gnus-enter-category-buffer)。

J s
全グループの適格な (訳注: あなたが指定した条件に合致する) 記事をすべて取 得します (gnus-agent-fetch-session)。

J S
順番待ち (queue) グループにある送信可能なメッセージをすべて送信しま す (gnus-group-send-queue)。See 節 5.7 下書き.

J a
現在のグループをエージェント分類に追加しま す (gnus-agent-add-group)。この命令はプロセス/接頭引数の習慣を理 解します (see 節 9.1 プロセス/接頭引数)。

J r
現在のグループを、もし存在していれば、その分類から消去しま す (gnus-agent-remove-group)。この命令はプロセス/接頭引数の習慣を 理解します。(see 節 9.1 プロセス/接頭引数)。

J Y
リモートサーバーが unplugged のときに変更されたフラグがあれば同期させま す。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.9.3.2 概略エージェント命令

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Summary+Agent+Commands"
"gnus/概略エージェント命令"へのコメント(無し)

J #
記事にダウンロード印を付けます (gnus-agent-mark-article)。

J M-#
記事からダウンロード印を消去します (gnus-agent-unmark-article)。

@
記事をダウンロードするかどうかを切り替えま す (gnus-agent-toggle-mark)。ディフォルトではダウンロードの印 は `%' です。

J c
キャッシュされていない、ダウンロードされていない、またはダウンロードでき ないすべての記事を既読にします (gnus-agent-catchup)。

J S
このグループのすべての望ましい (訳注: あなたが指定した条件に合致する) 記 事 (see 節 6.9.2 エージェント分類) をダウンロードしま す。(gnus-agent-fetch-group)。

J s
このグループのすべてのプロセス印が付いた記事をダウンロードしま す。(gnus-agent-summary-fetch-series)。

J u
現在のグループのダウンロード可能な記事を、すべてダウンロードしま す (gnus-agent-summary-fetch-group)。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.9.3.3 サーバーエージェント命令

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Server+Agent+Commands"
"gnus/サーバーエージェント命令"へのコメント(無し)

J a
現在のサーバーを Gnus エージェントで扱われるサーバーのリストに追加しま す (gnus-agent-add-server)。

J r
現在のサーバーを Gnus エージェントで扱われるサーバーのリストから削除しま す (gnus-agent-remove-server)。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.9.4 エージェントの視覚効果

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Agent+Visuals"
"gnus/エージェントの視覚効果"へのコメント(無し)

Unplugged のときに概略を開くと、現在エージェントに格納されているヘッダー よりも多くの記事があることを Gnus がそのグループの active (訳注: 何番か ら何番までの記事があるかを示す管理情報) の範囲から知っている場合には、表 題が `[Undownloaded article #####]' のようになっているいくつかの記 事を見るかもしれません。それらは見当たらないヘッダーのための穴埋 め (placeholders) です。印を設定することは別として、それらの穴埋めの一つ でできることは多くはありません。最終的に Gnus がグループのヘッダーを取っ て来る機会を得たときに、それらの穴埋めは実際のヘッダーで自動的に置き換え られるでしょう。気になるならば、それらの穴埋めを読み飛ばすために、概略バッ ファーの動作を操作することができます (gnus-auto-goto-ignores 参照)。

すべての人にとって明白かもしれませんが、オフラインのときに利用できるのは、 plugged だった期間にエージェントに取り込まれたヘッダーと記事だけです。言 い換えると「plugged だった期間に取り込むことを忘れると、オフラインのセッ ションを満足できるものにするには足りない」ということです。この理由のため に、エージェントは概略バッファーに二つの視覚効果を加えます。これらの効果 は、オフラインのときにどの記事が利用できるかをいつも知らせるために、それ ぞれの記事のダウンロードの状態を表示します。

第一の視覚効果は `%O' 仕様です。gnus-summary-line-format を カスタマイズしてこの指示子を含めると、記事のダウンロードの状態を示すため に単一の文字を表示する場所が加わります。エージェントかキャッシュのどちら かに取り込まれた記事は、gnus-downloaded-mark (ディフォルト は `+') を表示します。それら以外のすべての記事 は gnus-undownloaded-mark (ディフォルトは `-') を表示します。 エージェント化されていないグループを開くと、空白 (` ') が表示されま す。

第二の視覚効果はダウンロードされていないことを示すフェースです。多く の Gnus の利用者に好感と嫌悪をもたらすであろう、記事のスコアを三段 階 (low, normal, high) で表示するフェースがあります。問題は、フェースの 選択が条件検査とフェース名のリスト (gnus-summary-highlight 参 照) によって制御されることです。それぞれの条件は、それがリストの中に現れ る順に検査されるので、後の条件よりも前の条件が優先されます。これが意味す るすべては、ダウンロードされていない記事に可視記事 (ticked) の印を付けて も、その記事は可視記事のフェースではなくて、ダウンロードされていない記事 のフェースで表示し続けられるということです。

(記事を読むたびに同じ記事をダウンロードしないようにするため、または接続 時間を最小にするために) エージェントをキャッシュとして使う場合は、ダウン ロードされていない記事のフェースはおそらく良い考えのように思えるでしょう。 ダウンロードされた記事に対してすべての仕事 (印を付ける、読む、削除す る) を行なえば、いつも通常のフェースが現れるからです。しかし、 NOV をキャッシュすることによってオンライン性能を改善するために エージェントを使っている利用者にとっては (Gnus 5.10.2 以降のほとんどの利 用者にとっては)、ダウンロードされていない記事のフェースが見えるかもしれ ないことは、まったくひどいものでしょう。これは、それらのどの記事もエージェ ントに取り込まれていないので、ダウンロードされていない記事のフェースのた めに、すべての普通のフェースが目立たなくなってしまうだろうという問題です。

ダウンロードされていない記事のフェースを使いたい場合は、 agent-enable-undownloaded-faces グループパラメーター を t に設定して、ダウンロードされていない記事のフェースを有効にし なければなりません。このパラメーターは他のすべてのエージェントパラメーター と同様に、エージェント分類 (see 節 6.9.2 エージェント分類)、グループトピッ ク (see 節 2.16.5 トピックパラメーター)、あるいは個々のグルー プ (see 節 2.10 グループパラメーター) に対して設定することができます。

エージェントを使うすべての利用者に共通した一つの問題は、それがディスクの 容量をいかに速く使い尽くすことができるかということです。あなたが多くのグ ループでエージェントを使っている場合、事実上ディスク容量を回復することは さらにもっと困難です。一つの解決手段は gnus-group-line-format で 用意されている `%F' 形式です。この形式は、エージェントとキャッシュ の両方で取得した記事によって占められる実際のディスク容量を表示します。ど のグループが最も多い容量を使うかを知ることによって、利用者は記事を「エー ジェント期限切れ消去」する場合に、どこに努力を集中するべきかがわかります。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.9.5 キャッシュとしてのエージェント

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Agent+as+Cache"
"gnus/キャッシュとしてのエージェント"へのコメント(無し)

Gnus が plugged であるときに、すでにヘッダーや記事がエージェントに格納さ れているのならば、それらを再びダウンロードするのは効率的ではありません。 そのため Gnus は通常ヘッダーを一回だけダウンロードしてエージェントに格納 します。それらのヘッダーは後に概略バッファーを生成するときに、 plugged か unplugged にかかわらずに使われます。ディフォルトでは記事 は (それはたくさんのディスク容量を浪費するかもしれないので) エージェント にキャッシュされませんが、すでにエージェントにダウンロードした記事がある ならば、Gnus はサーバーから再び記事をダウンロードせずに、手元に格納され たコピーを使います。

あなたがそう望むのであれば、plugged な期間は常にヘッダーと記事をダウンロー ドするように、エージェント (gnus-agent-cache 参照 6.9.11 エージェント変数) を設定することができます。Gnus はほとんど確かにもっと遅くな りますが、サーバーとの同期は保たれます。nntp か nnimap バックエンドを使っ ている場合は、たぶんこの最後の点は意味をなさないでしょう。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.9.6 エージェント期限切れ消去

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Agent+Expiry"
"gnus/エージェント期限切れ消去"へのコメント(無し)

エージェントバックエンド nnagent は期限切れ消去を扱いません。えー と、少なくとも他のバックエンドのようにそれを扱いません。その代わりに、 gnus-agent-expire-days の日数よりも古い既読記事をすべて消去する、 特別な gnus-agent-expire と gnus-agent-expire-group 命令が あります。これらはあなたがディスク容量を使い切りそうだと思ったときに、い つでも実行することができます。どちらも特に速くも効率的でもなく、それらの 一つをいったん始めてしまったら (C-g やその他で) 中断することもあま り良いことではありません。

他の関数がエージェントをグループに同期させるため に gnus-agent-expire を実行するかもしれないことに注意してください。

agent-enable-expiration というエージェントのパラメーターを、選択 したグループでの期限切れ消去を抑制するために使うことができます。

gnus-agent-expire-all が nil でなければ、エージェントの期 限切れ消去コマンド群はすべての記事---未読、既読、可視、保留記事を消去し ます。もし nil (これがディフォルト) であれば、既読記事のみが消去 の対象となり、未読、可視、さらに保留記事は無期限に保持されます。

期限切れ消去されるはずなのに残っている記事を見つけたならば、もしかすると いくつかの Gnus エージェントファイルが壊れています。起こりうる問題を修復 するために、 gnus-agent-regenerate と gnus-agent-regenerate-group とい う特別なコマンドがあります。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.9.7 エージェントを作り直す

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Agent+Regeneration"
"gnus/エージェントを作り直す"へのコメント(無し)

nnagent によって使われるローカルのデータ構造は、ある例外的な条件 によっておかしくなってしまうかもしれません。これが起こる と nnagent の機能性が下がるかもしれないし、失敗しさえするかもしれ ません。この問題の解決策は、内部の矛盾をすべて削除することによって、ロー カルのデータ構造を修復することです。

例えば、記事をエージェントにダウンロードしている間にサーバーへの接続が切 れてしまう場合、ローカルのデータ構造は接続が切れる前に記事が首尾良くダウ ンロードされたかどうかを知りません。gnus-agent-regenerate また は gnus-agent-regenerate-group を実行すると、そのような記事を二回 ダウンロードしなくても済むようにデータ構造を更新します。

gnus-agent-regenerate コマンドは、すべてのエージェント化されたグ ループで gnus-agent-regenerate-group を実行します。どのバッファー 上でも gnus-agent-regenerate を実行することができますが、最初にす べての概略バッファーを閉じることを強く勧めます。

gnus-agent-regenerate-group コマンドは、ローカル の NOV (ヘッダー) データベースを修復するために、個々の記事のロー カルなコピーを使います。その後それは、どの記事がローカルに格納されるかを 記録しておくための内部データ構造を更新します。引数を与えると、エージェン トの中の記事に未読の印を付けます。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.9.8 エージェントとフラグ

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Agent+and+flags"
"gnus/エージェントとフラグ"へのコメント(無し)

エージェントは Gnus のどんなバックエンドでも、例えばサーバーにフラグ (既 読(read)、可視(ticked) など) を格納する nnimap のようなものでも動作しま す。しかし悲しいかな、エージェントはどのバックンドがそれらのフラグ を `.newsrc' ではなく、そのバックエンドのサーバーで維持するかを、実 際には知りません。そのためエージェントは、unplugged または接続されていな い間に行なったすべてのフラグへの変更を、常に自身のファイルに記録します。

再び接続すると、Gnus は変更されたすべてのフラグを検査して、それらをサー バーと同期させるかどうかを尋ねます。この挙動 は gnus-agent-synchronize-flags でカスタマイズすることができます。

gnus-agent-synchronize-flags が nil だったら、エージェント は自動的にフラグを同期させることはしません。それがディフォルト の ask だったら、エージェントはあなたが再接続したときにあなたが何 らかの変更を行なっていたかどうかを調べて、もしそうだったら、それらを同期 させたいかどうかを尋ねます。それら以外の値だった場合は、すべてのフラグは 自動的に同期させられます。

再接続したときに自動でフラグを同期させたくないなら、手動でそれを行なうこ ともできます。これにはグループバッファーの J Y キーに割り当てられ た gnus-agent-synchronize-flags コマンドを使ってください。

技術的注釈: すべてのローカルなフラグをサーバーに「押し込む」同期のアルゴ リズムは動作しませんが、利用者によって変更されたフラグだけを変更して、サー バー側で見えるフラグを一つずつ更新することは可能です。したがって、あなた が記事の一つのフラグをセットして、そのグループを抜け出てから再度そのグルー プを選択してそのフラグを消せば、あなたが「同期」の操作を行なったときに、 そのフラグはセットされてサーバーからは削除されます。順番待ち (queue) に 入れられたフラグに関する動作は、エージェントディレクトリーにあるサーバー 毎の flags ファイルの中で見つかるでしょう。それらはあなたがフラグ を同期させたときに空になります。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.9.9 エージェントを IMAP で使う方法

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Agent+and+IMAP"
"gnus/エージェントをIMAPで使う方法"へのコメント(無し)

エージェントは nnimap を含む Gnus のどんなバックエンドでも動作します。し かし NNTP と IMAP にはいくつかの概念の違いがあるので、 この章ではサーバーとの接続が絶たれたモードでの IMAP のクライア ントとして、Gnus エージェントをより円滑に使えるようにするための、いくつ かの情報を提供します。

サーバーとの接続が絶たれているときの IMAP クライアントにあなた が期待するであろういくつかの機能は、現在のエージェントには盛り込まれてい ません。それらは以下の通りです:


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.9.10 差出用メッセージ

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Outgoing+Messages"
"gnus/差出用メッセージ"へのコメント(無し)

Gnus が unplugged のとき、ディフォルトではすべての差出用メッセージ (メー ルとニュースの両方) は下書きグループ“queue”(see 節 5.7 下書き) に格納され ます。投稿した後でも、そこでそのメッセージを見たり編集するのは意のままで す。

送出するメールが queue される (順番待ちになる) 状況を制御することは可能 です (gnus-agent-queue-mail, 6.9.11 エージェント変数 参照)。 Gnus が unplugged のとき、外に送り出すニュースは常に queue されるだけで す。

下書きグループから、そこで使える特別な命令を使ってメッセージを送信するこ ともできるし、グループバッファー内で J S を使って、下書きグループ 内のすべての送信可能なメッセージを送信することもできます。ニュースの投稿 は Gnus が plugged のときだけできますが、メールはいつでも送信することが できます。

Unplugged のときにメールの送信ができなくて、かつ unplugged のときにうっ かり J S を叩いてしまうことが心配ならば、Gnus にあなたの行動を確認 させることができます (gnus-agent-prompt-send-queue, 6.9.11 エージェント変数 参照)。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.9.11 エージェント変数

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Agent+Variables"
"gnus/エージェント変数"へのコメント(無し)

gnus-agent
エージェントが有効になっているかどうか。ディフォルトは t です。最 初に有効にされると、いくつかのバックエンドを自動的にエージェント化するた めに、エージェントは gnus-agent-auto-agentize-methods を使います。 サーバーバッファーでエージェントのコマンドを使うことによって、どのバック エンドをエージェント化するかを変更することができます。

サーバーバッファーに入るには、グループバッファー で ^ (gnus-group-enter-server-mode) を使ってください。

gnus-agent-directory
Gnus エージェントがファイルを格納する場所です。ディフォルト は `~/News/agent/' です。

gnus-agent-handle-level
この変数の値より高いレベル (see 節 2.6 グループレベル) のグループは、エージェ ントからは無視されます。ディフォルトは gnus-level-subscribed で、 これはディフォルトでは、購読しているグループのみがエージェントの処理の対 象となるということです。

gnus-agent-plugged-hook
ネットワークに接続されたときに実行されるフックです。

gnus-agent-unplugged-hook
ネットワークから切断されたときに実行されるフックです。

gnus-agent-fetched-hook
記事を取り込み終わったときに実行されるフックです。

gnus-agent-cache
Plugged のときに、ローカルに格納されている NOV と記事を使うか どうかを制御する変数で、例えばエージェントをキャッシュとして使うには必須 です。ディフォルトでは非-nil で、エージェントをキャッシュとして使 います。

gnus-agent-go-online
gnus-agent-go-online が nil だったら、エージェントはオフラ イン状態のサーバーをオンライン状態にしません。ask だったら、それ がディフォルトですが、エージェントは再接続するときにオフライン状態のサー バーをオンライン状態にしたいかどうかを尋ねます。それ以外の値だったら、オ フライン状態のサーバーは自動的にオンライン状態になります。

gnus-agent-mark-unread-after-downloaded
gnus-agent-mark-unread-after-downloaded が 非-nil だったら、 ダウンロードした後で記事に未読の印を付けます。これは通常、新しくダウンロー ドされた記事を明確に未読にするための安全な行為です。ディフォルト は t です。

gnus-agent-synchronize-flags
gnus-agent-synchronize-flags が nil だったら、エージェント は決して自動的にフラグを同期させません。それが ask だったら (それ がディフォルトです)、エージェントはすべての変更を検査して、再び接続した ときにそれらを同期させるかどうかを尋ねます。nil で も ask でもなかったら、すべてのフラグが自動的に同期させられます。

gnus-agent-consider-all-articles
gnus-agent-consider-all-articles が非-nil だったら、エージェ ントはすべての記事について、それらをダウンロードする必要があるかどうかを エージェントの述語に決定させます。nil だった場合、それがディフォ ルトですが、エージェントは未読の記事をダウンロードするかどうかだけを述語 に決定させます。これを有効にするのならば、後でエージェントが期限切れ消去 する記事を何度も繰り返しダウンロードしないように、エージェントの期限切れ 消去の設定 (see 節 6.9.2.3 分類変数) を見直す必要があるでしょう。

gnus-agent-max-fetch-size
エージェントは、取得した記事を個々のファイルに入れるための解析を行なう前 に、それらを一時的なバッファーへ取り込みます。最大のバッファーサイズを超 過しないようにするために、記事がすべて取得されるまで、エージェントは取得 と解析を交互に行ないます。gnus-agent-max-fetch-size は、繰り返し がどれくらい頻繁に起きるかを制御するための、サイズの限界を規定します。大 きな値は性能を向上させます。小さな値は、万が一取得している間に接続が切れ た場合に、遅れ時間を最小にします (グループの状態を更新するため に gnus-agent-regenerate-group を実行する必要があるかもしれませ ん。でも、接続が切れる前に解析されたすべての記事は、unplugged の期間に利 用することができるでしょう。)。繰り返しに遭遇することは珍しいので、ディ フォルトは 10M です

gnus-server-unopen-status
エージェント変数ではないかもしれないけれどエージェントに密接に関連するこ の変数は、Gnus がサーバーに接続できないときに何をするかを指示します。エー ジェントが活性化されると、ディフォルトの nil では、サーバーとの接 続を絶つかエージェントを unplugged にするかを利用者に尋ねます。エージェ ントが不活性化されると、Gnus はいつも単にサーバーとの接続を絶ちます。こ の変数の他の選択肢には denied と offline があり、後者はエー ジェントを使う場合だけ有効です。

gnus-auto-goto-ignores
おおかたの人は、エージェント変数ではないけれども密接に関連するもう一つの 変数をここで探すでしょう。この変数は、ダウンロードされていない (ヘッダー だけがエージェントに格納された)、そして取り込まれていない (記事もヘッダー も格納されていない) 記事の周りでどう移動するかを概略バッファーに伝えます。

有効な値は nil (どの記事にも移動する)、 undownloaded (unplugged のときは取り込まれていない記事を無視する)、 always-undownloaded (取り込まれていない記事を常に無視する)、 unfetched (ヘッダーが取り込まれていない記事を無視する) です。

gnus-agent-queue-mail
gnus-agent-queue-mail を always にすると、Gnus はメールを いきなり送信してしまうのではなく、常に queue (順番待ち) に入れます。 t だったら Gnus は unplugged のときだけメールを queue に入れます。 nil だったら queue に入れません。ディフォルトは t です。

gnus-agent-prompt-send-queue
gnus-agent-prompt-send-queue が非-nil だったら、 unplugged であるのにもかかわらず J S を叩いた場合に、Gnus は本当に それを行なっても良いかどうかを確認します。ディフォルトは nil です。

gnus-agent-auto-agentize-methods
あなたが以前にエージェントを使ったことが無い (もっと技術的に は `~/News/agent/lib/servers' が無い場合)、Gnus はほんの少数のサー バーを自動的にエージェント化します。この変数はどのバックエンドを自動でエー ジェント化すべきかを制御します。一般に、エージェント化することが有用なの は遠隔バックエンドに対してだけです。自動的にエージェント化することは、サー バーに対して J a を実行するのと同じ効果があります (see 節 6.9.3.3 サーバーエージェント命令)。もしファイルが存在するならば、それらを追加したり削除す るためにサーバーを手動で操作しなければなりません。この変数は最初 に Gnus を起動したときだけ適用されます。ディフォルトは `nil' です。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.9.12 設定例

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Example+Setup"
"gnus/設定例"へのコメント(無し)

あなたがこのマニュアルを読みたくなくて、ごく標準的な設定を行なっているの ならば、`~/.gnus.el' ファイルとして何か以下のようなものを使って始め ても良いでしょう。

  
;; Gnus がどのようにニュースを取得するかを定義します。ここ
;; では ISP のサーバーから NNTP で取ってくることにします。
(setq gnus-select-method '(nntp "news.your-isp.com"))

;; Gnus がどのようにメールを読むかを定義します。
;; ISP の POP サーバーからメールを読むことにします。
(setq mail-sources '((pop :server "pop.your-isp.com")))

;; Gnus がメールをどのように格納するかを指定します。
;; nnml グループを使うことにします。
(setq gnus-secondary-select-methods '((nnml "")))

;; Gnus をオフラインニュースリーダーにします。
;; (gnus-agentize) ; 旧式の設定。
;; (setq gnus-agent t) ; 現在のディフォルト。

基本的にはこれだけで良いはずです。これを `~/.gnus.el' ファイルに入 れて、必要に応じて編集し、PPP (や何か) を起動して、M-x gnus とタイ プしてください。

あなたが Gnus を走らせたのが初めてであれば、自動的にわずかなディフォルト のニュースグループが読めるようになります。おそらくもっとたくさんのグルー プを購読したくなるでしょう。そのためには、A A 命令でグループの完全 なリストを NNTP サーバーに問い合わせなければなりません。これは 普通はとても時間がかかりますが、一度だけしか実行する必要はありません。

読み込みと解析にしばらく時間を費やした後で、グループの一覧が現れます。そ うしたら、読みたいグループを u 命令で購読できるようにしてください。 読みたいグループを全部購読できるようにしたら、l で killed (削除さ れた) グループをすべて画面から消去しましょう。(A k で killed グルー プはすべて戻ってきます。)

今やすぐにグループを読むこともできるし、J s 命令で記事をダウンロー ドすることもできます。あとはこのマニュアルの残りを読んで、他の億千万の項 目からカスタマイズしたいことを見つけ出してください。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.9.13 一括エージェント処理

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Batching+Agents"
"gnus/一括エージェント処理"へのコメント(無し)

Gnus エージェントに記事を取得させるのは (そしてあなたの書いた何かのメッ セージを投稿するのは)、いったんものごとを正しく設定してしまえば非常に簡 単です。以下のシェルスクリプトは必要なことをすべてやってくれるでしょう。

以下の呪文をコマンドラインで使うことによって、完全なバッチコマンドを走ら せることができます:

  
#!/bin/sh
emacs -batch -l ~/.emacs -l ~/.gnus.el -f gnus-agent-batch >/dev/null 2>&1


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

6.9.14 エージェントの問題点

URL="https://bookshelf.jp/cgi-bin/goto.cgi?file=gnus-ja&node=Agent+Caveats"
"gnus/エージェントの問題点"へのコメント(無し)

Gnus エージェントは、よくある他のオフラインニュースリーダーのようには動 作しません。これらは架空の人々からの良くある質問です:

Plugged のときに記事を読んだら、それはエージェントに入るのですか?

いいえ。この動作をお望みなら gnus-select-article-hook に 関数 gnus-agent-fetch-selected-article を加えてください。

Plugged のときに記事を読んで、エージェントに記事が存在している場合、
もう一回ダウンロードされるのですか?

いいえ、ただし gnus-agent-cache が nil でなかった ら、ですが。

要約すると、Gnus が unplugged のときはローカルに保存された記事を見るだけ です。Plugged のときは ISP と話し、かつローカルに持っている記事も使うで しょう。

[ << ] [ >> ]           [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

このページはMeadow (Emacs) の紹介ページです
このWebページの各文書は自由にリンク・複製・再配布・改変していただいて構いません．
ただし，複製・再配布・改変の場合は Meadow Memo のURLを記載しておいて下さい．
Medow memoへのリンクについて．


ページ別カウンタ
Since 2002/12/13