Copyright (C) 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005 Free Software Foundation, Inc.

     Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with the Front-Cover texts being ``A GNU Manual'', and with the Back-Cover Texts as in (a) below.  A copy of the license is included in the section entitled ``GNU Free Documentation License'' in the Emacs manual.

     この文書を、フリーソフトウェア財団発行の GNU フリー文書利用許諾契約書第 1.2 版またはそれ以降の版が定める条件の下で複製、配布、あるいは変更することを許可します。変更不可部分は指定しません。「A GNU Manual」は表表紙テキスト、以下の (a) は裏表紙テキストです。この利用許諾契約書の複写は「Emacs manual」の「GNU フリー文書利用許諾契約書」という章に含まれています。

     (a) The FSF's Back-Cover Text is: ``You have freedom to copy and modify this GNU Manual, like GNU software.  Copies published by the Free Software Foundation raise funds for GNU development.''

     (a) FSF の裏表紙テキスト:「あなたにはこの GNU Manual を GNU ソフトウェアのように複製したり変更する自由があります。複製はフリーソフトウェア財団によって出版されました。(フリーソフトウェア財団は) GNU の開発のために必要な資金を集めています。」

     This document is part of a collection distributed under the GNU Free Documentation License.  If you want to distribute this document separately from the collection, you can do so by adding a copy of the license to the document, as described in section 6 of the license.

     この文書は「GNU フリー文書利用許諾契約書」に基づいて配布された収集著作物の一部です。もしあなたがこの文書を収集著作物から分離して配布したいときは、契約書の第 6 項に記述されているように、文書に契約書の複写を付加することによって、行なうことができます。

The Gnus Newsreader
*******************

Gnus を使うことによって Emacs でニュースを (それにメールも) 読むことができます。ニュースは NNTP、ローカルスプール、mbox ファイルなどのあらゆる極悪な手段を駆使して手に入れることができます。運試しをしてみようと思うならば、すべてを同時に用いることもできます。

この説明書は No Gnus v0.3 に対応します。

Gnus の起動
********

システム管理者が適切な設定をしていたならば、Gnus を起動してニュースを読むのは非常に簡単です。そう、Emacs で M-x gnus と打つだけです。

別のフレーム (frame) で Gnus を起動したいときは、 M-x gnus-other-frame 命令を使うことができます。

開始時に何かがうまくいかないときは ~/.gnus.el ファイルの中で変数をいくつかいじくりまわさなければならないでしょう。このファイルは ~/.emacs と似ていますが、こちらは Gnus が起動するときに読み込まれます。

この説明書でよくわからない用語がでてきたときは、用語の項 (Terminology) を参照して下さい。

ニュースを見つける
=========

変数 gnus-select-method は Gnus がどこでニュースを探すべきかを示します。この変数ははじめの要素が 方法、二番目の要素が 場所 を表すリストである必要があります。この方法はあなたの基本方法 (native method) になります。この方法で取ってこないグループはすべて外部 (foreign) グループです。

たとえば、NNTP サーバー news.somewhere.edu から毎日 (薬のように) 一定の量のニュースを摂取したいのであれば、

     (setq gnus-select-method '(nntp "news.somewhere.edu"))

のようにすることができます。

ローカル・スプールのディレクトリーを読み込みたい場合は、

     (setq gnus-select-method '(nnspool ""))

のようにできます。

ローカルのスプールを使えるのであれば、かなりの確率でその方がずっと速いでしょうし、それを使うべきでしょう。でも、もしあなたのサーバーが Leafnode (それは簡単な個人用のニュースサーバーです) であるならばローカルスプールを使ってはいけません。この場合は (nntp "localhost") にしましょう。

もしこの変数が設定されていなければ、Gnus は NNTPSERVER 環境変数を読みにいきます。もしその変数が設定されていなければ、 Gnus は gnus-nntpserver-file (設定されていない場合は /etc/nntpserver) がこの件に関して何かを言っていないかを調べます。もしそれも失敗したなら、Gnus は Emacs が動作しているサーバーを NNTP サーバーとして使おうとします。随分な当て推量ですけどね。

gnus-nntp-server が設定されていると、この変数は gnus-select-method よりも優先されます。ですから gnus-nntp-server は nil に設定するべきで、それがディフォルトです。

Gnus に NNTP サーバーの名前を対話的に指定することもできます。 gnus に数値でない接頭引数を渡すと (例: C-u M-x gnus)、 Gnus は gnus-secondary-servers リスト (もし存在するならば) からサーバーを選ぶことができるようにします。ただ単に接続したいと思ったサーバーの名前を打つこともできます。(これは gnus-nntp-server を設定し、これは後の Emacs のセッションで M-x gnus とすると、Gnus は同じサーバーに接続しようとするということです。)

しかし、普段日常的には一つの NNTP サーバーを使い、違ったサーバーには興味のあるグループが少ししかない場合、グループバッファーで B 命令を使うことの方が良いでしょう。それは、選択可能なグループを表示し、その中からどれでも好きなものを購読することができます。これは .newsrc の保持をずっとやりやすくします。 See 外部グループ.

外部グループに対する少し違ったやり方は、変数 gnus-secondary-select-methods を設定する方法です。この変数に表されている選択方法は、多くの点で gnus-select-method サーバーの選択方法と同じように扱われます。起動中にアクティブファイルを探しにいき (もし要求されていれば)、これらのサーバー上にできた新しいニュースグループは元々のグループと同じように購読されます (もしくは、されません)。

たとえば、メールを読むために nnmbox バックエンド (back end) を使いたいときは、普通、この変数を、

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

と設定します。

注: NNTP バックエンドは印ファイル (see NNTP marks) に印を保存します。この機能は Gnus がインストールされている複数のホスト間で印を共有することを容易にしますが、新着記事の取得をちょっと遅くするかもしれません。詳細については NNTP marks を参照して下さい。

一番初め
====

起動用ファイルが存在しないときは (see Startup Files)、Gnus はどのグループがディフォルトで購読されているべきかを決定しようとします。

変数 gnus-default-subscribed-newsgroups が設定されていると、 Gnus はそのリストの中のグループを購読し、残りを削除します。システム管理者はこの変数を何か役に立つものに設定しておくことが望まれます。

そうでないときは、Gnus は少数の適当なグループを購読します (例: *.newusers)。(適当な はここでは、Lars さんが読むべきであると考えるもの というように定義されています)

また、たいていの共通の問題の解決の手助けになるよう、Gnus に関する文書のグループも購読することになるでしょう。

gnus-default-subscribed-newsgroups が t のときは、Gnus は新しいグループを扱うのに普通の関数を使い、特別なことは何もしません。

サーバーが落ちている
==========

ディフォルトのサーバーが落ちているときは、当然 Gnus の起動にいくつかの問題が発生します。しかし、ニュースグループの他にいくつかメールのグループがあるのならば、それにもかかわらず Gnus を起動する必要があるかもしれません。

信頼できるプログラムの一つである Gnus は、サーバーと接続できないときは基本選択方法なしで続けるかどうかを尋ねます。これは実際にはサーバーが存在しないとき (例えば、アドレスを間違えた場合) やサーバーが何らかの理由で一時的に調子がおかしくなっているときに起こります。もしそのまま続行することにして、外部グループが一つも無い場合、実はグループバッファーではほとんど何もできないということに気が付くでしょう。でも、ねぇ、それはあなたの問題です。ブブーッ!

サーバーが完全に落ちているのを知っているか、サーバーでわずらうことなくメールだけを読みたいときは、Gnus を起動するのに gnus-no-server 命令を使うことができます。急いでいるときにもぴったりでしょう。この命令は本来のサーバーには接続しません---その代わりに、レベル 1 と 2 にあるすべてのグループを活動状態にします (基本グループでないグループはその二つのレベルにしておくのが望ましいでしょう)。Group Levels も参照して下さい (訳注: gnus-no-server は gnus-group-use-permanent-levels 変数の値を 2 に設定することに注意して下さい)。

Gnus をスレーブにする
=============

あなたには二つ以上の Gnus をそれぞれ別の Emacs 上で同時に動かす必要が生じるかもしれません。違った .newsrc ファイルを使っているなら (例えば、二つの違ったサーバーから読み込むために、二つの違った Gnus を動作させている場合)、まったく問題はありません。それを行なえば良いだけです。

問題は、同じ .newsrc ファイルを使う二つの Gnus を動かそうとしたときに起こります。

この問題に対処するために Gnus タワーのシンクタンクにいる私たちは、新しい概念にたどりつきました。マスター と スレーブ です。(私たちはこの概念に特許を申請しました。そして、その言葉の著作権を得ました。お互いに関連してこれらの言葉を使いたいなら、一回使う毎に、私に $1 を送らなければなりません。もっちろん、コンピューターアプリケーションのマスター／スレーブ関係 の使用料はもっと高くなります。)

とにかく、M-x gnus (もしくは、普段やっている方法) で Gnus を普通に起動します。その後のスレーブ Gnus はそれぞれ M-x gnus-slave で起動します。スレーブは普通の .newsrc は保存しませんが、代わりに スレーブファイル にスレーブの起動中にどのようなグループが読まれたかという情報だけを保存します。マスター Gnus が起動するとき、それはそれらのスレーブファイルを読み込み (そして消し)、それらからすべての情報を取り込みます。(スレーブファイルは、最終的な変更が優先されるようにそれらが作られた順番で読まれます。)

もちろん、スレーブファイルからの情報は普通の (すなわち、マスターの) .newsrc ファイルよりも優先されます。

スレーブを起動するときにもしマスターの .newsrc* ファイル群がセーブされていなかったら、自動保存されたファイルを読むかどうかを尋ねられるかもしれません。``yes'' と答えると、マスターにセーブされていない変更はスレーブに反映されません。``no'' と答えると、マスターで読まれたいくつかの記事が、スレーブでは未読であると見なされるかもしれません。

新しいグループ
=======

新しいニュースグループをまったく見なくても満足ならば、 gnus-check-new-newsgroups を nil に設定することができます。これを設定した場合、起動にかかる時間が短くなります。この変数が nil に設定されていても、グループバッファーで U を押せばいつでも新しいグループを購読することができます (see Group Maintenance)。ディフォルトではこの変数は ask-server です。この変数が always に設定されていると、g 命令を実行したときでも Gnus はバックエンドに新しいグループを探すことを求めます (see Scanning New Messages)。

新しいグループを調べる
-----------

Gnus は、普通はグループが新しいかどうかを、購読しているグループと削除されているグループのリストとアクティブファイルを比較することにより判定しています。この方法は特に速いというわけではありません。 gnus-check-new-newsgroups が ask-server であると、Gnus はサーバーに、最後に接続してから新しいグループができているかどうかを尋ねます。この方法は速いし、安上がりです。これにより、削除されたグループのリストを保持しておくことからから完全に開放されます。ですから、 gnus-save-killed-list を nil にすることができるでしょう。そうすれば、起動、終了の両方、そして全体にわたって時間を節約できます。ディスク消費量も少なくなります。それなら、どうしてこれがディフォルトではないのでしょう? 残念ながら、すべてのサーバーがこの命令を理解するわけではないのです。

私は今あなたが何を考えているかを当てられます。どうすればサーバーが ask-server を理解するかがわかるのでしょう? え、違うのですか? あぁ、良かった。というのは、確実な答は存在しないのです。私に言えることは、この変数を ask-server に設定して、数日間新しいグループが現れるかどうかを調べて下さい、ということだけです。もしいくつかのグループが現れたなら、それで動作しています。一つも現れなければ、それは動作していません。私は、Gnus にサーバーが ask-server を理解するかどうかを推量させる関数を書くこともできますが、それは単に推量しているにすぎません。ですから、その関数を書くことはないでしょう。他の方法としては、サーバーに telnet をして、HELP と打ち、サーバーが理解するコマンドの中に NEWGROUPS があるかどうかを調べることもできます。もしあれば、おそらく動作するでしょう (しかし、適切に機能を提供することなく NEWGROUPS をリストに含めるサーバーもあります)。

この変数は、選択方法のリストであることもできます。そのときは、 Gnus は ask-server 命令をそれぞれの選択方法に対して実行し、普通の方法で購読します (もしくは、しません)。これの副作用は、起動にかなり時間がかかるので、待っている間に瞑想できることです。永久の幸福を達成するために、マントラ ``dingnusdingnusdingnus'' を使って下さい。

購読方法
----

新しいグループに遭遇したときに Gnus が何をするかは、変数 gnus-subscribe-newsgroup-method によって決定されます。

この変数は関数を含んでいる必要があります。この関数は新しいグループの名前を唯一の引数として呼ばれます。

いくつかの手軽なプレハブ関数は、以下のようになっています。

gnus-subscribe-zombies
     すべての新しいグループをゾンビ (zombie) にします。これがディフォルトになっています。後でゾンビを (A z によって) 概観したり、(S z によって) 適切にすべてを削除したり、(u によって) 購読したりできます。

gnus-subscribe-randomly
     任意の順番ですべての新しいグループを購読します。実際には、すべての新しいグループはグループバッファーの『一番上』に加えられます。

gnus-subscribe-alphabetically
     すべての新しいグループをアルファベット順に購読します。

gnus-subscribe-hierarchically
     すべての新しいグループを階層的に購読します。この関数と gnus-subscribe-alphabetically の違いは少ししかありません。 gnus-subscribe-alphabetically は新しいグループを厳密にアルファベット順にならべますが、この関数はグループをその階層の中に入れます。ですから、 rec の階層を comp の階層の前に持ってきたい場合、この関数はその配置をぐちゃぐちゃにはしません。もしくは、そのようなものです。

gnus-subscribe-interactively
     新しいグループを対話的に購読します。これは Gnus が すべて のグループに対して尋ねることを意味しています。購読するグループは階層的に購読されます。

gnus-subscribe-killed
     すべての新しいグループを削除します。

gnus-subscribe-topics
     グループを、それに合致する subscribe トピックパラメーターを持っているグループに入れます (see Topc Parameters)。例えば、以下のような subscribe パラメーター

          "nnslashdot"

     は、その正規表現に合致するすべてのグループはそのトピックの下で購読されるということです。

     グループに合致するトピックが無い場合、グループは最上位のトピックで購読されます。

上の変数と密接に関係する変数は、 gnus-subscribe-hierarchical-interactive です。この変数が nil でないと、Gnus は階層的な方法で新しいグループを購読するかどうかを尋ねます。Gnus はそれぞれの階層で、それを下に降りるかどうかを尋ねます。

よくある間違いは、数段落前の (gnus-subscribe-newsgroup-method) 変数を gnus-subscribe-herarchical-interactive に設定することです。これは誤りです。これは動作しません。これはおめでたい人のすることです。ですから、絶対にしないで下さい。

新しいグループを選別する
------------

どの新しいグループが購読 (もしくは、無視) されるべきかを管理する快適で手軽な方法は、.newsrc ファイルの先頭に options 行を挿入することです。次は、例です。

     options -n !alt.all !rec.all sci.all

この行は、明らかにまじめで理知的で科学的な人間 (あるいは彼女はどこにでもいる単につまらない人かもしれないけれど) が書いたものです。なぜなら、これは alt と rec で始まる名前を持つグループはすべて無視され、 sci で始まる名前を持つグループはすべて購読する、ということを表しているからです。Gnus はこれらのグループを購読するのに普通の購読方法を使いません。代わりに gnus-subscribe-options-newsgroup-method が使われます。この変数のディフォルト値は gnus-subscribe-alphabetically です。

.newsrc ファイルをいじりたくない場合は、 gnus-options-subscribe と gnus-options-not-subscribe の二つの変数だけを設定することもできます。この二つの変数は .newsrc ファイルの optinos -n 行とまったく同じことをします。どちらの変数も正規表現で、新しいグループは前者に合致すれば無条件に購読され、後者に合致すると無視されます。

さらにここでおせっかいをする変数は、 gnus-auto-subscribed-groups です。それは gnus-options-subscribe とまったく同じように動作するので、本当は余分なものです。しかし、私はこの二つがあった方が良いと思いました。もう一方の変数は利用者がいじくるのに使われるのに対して、この変数はいくつかの基本的な規則を設定するためのものです。ディフォルトではこの変数はメールバックエンド (nnml, nnbabyl, nnfolder, nnmbox, nnmh および nnmaildir) からできるすべての新しいグループを購読するようになっています。それが嫌であれば、この変数を nil に設定して下さい。

この正規表現に合致する新しいグループは gnus-subscribe-options-newsgroup-method を使って購読されます。

サーバーを換える
========

ときどき、ある NNTP サーバーから別のサーバーへ移動しなければならないことがあります。このようなことはめったにおきませんが、おそらくあなたが仕事を変えたり、使っているサーバーがとても不安定で、別のものに乗り換えたいというときに必要になるでしょう。

サーバーを変更するのはとても簡単ですよね? gnus-select-method を新しいサーバーを指し示すように変更すればいいだけですね?

違います!

記事の番号は違った NNTP サーバーでも (どうにかして) 同じにしてあるということはありません。そして、Gnus がどの記事を読んだかを記録する唯一の方法は、記事番号を記録することです。ですから gnus-select-method を変更したときは、.newsrc ファイルは役に立たなくなります。

Gnus は .newsrc ファイルをあるサーバー用から別のサーバー用に変換する関数を二、三用意しています。それらには一つ共通点があります---実行にながーーい時間がかかることです。おそらく、どうしても必要になったとき以外にこの関数を使おうとは思わないでしょう。

もし両方のサーバーに接続できるなら、Gnus はあなたが読んだ記事すべてに対してヘッダー (headers) を要求して、Message-ID を比較し、読んだ記事と記事の印を新しく記録します。M-x gnus-change-server コマンドはこれをすべての基本グループに対して行ないます。そのコマンドは移動先の方法 (the method) を入力することを要求します。

個々のグループを M-x gnus-group-move-group-to-server 命令で移動することもできます。これはあるサーバーから別のサーバーへ一つの (外部) グループを移動したいときに役に立ちます。

古いサーバーと新しいサーバーの両方に接続することができないとき、印と読んだ範囲はすべて意味が無くなります。そのようなときは M-x gnus-group-clear-data-on-native-groups コマンドを使って、基本グループに関するデータをすべて消去することができます。このコマンドは注意して使って下さい。

gnus-group-clear-data コマンドは現在のグループのすべてのデータをクリアします---マークと既読記事のリストを消し去ります。

サーバーを変更した後で、キャッシュ階層を移動させなければ なりません。というのは、キャッシュ記事は間違った記事番号になっており、それは Gnus がどの記事を読んだとみなすかに影響します。 gnus-group-clear-data-on-native-groups はそれを自動で行なってしまうかどうかを尋ねます。gnus-group-clear-data では M-x gnus-cache-move-cache が使えます (でも気を付けて、それはすべてのグループのキャッシュを移動してしまいますから)。

起動ファイル
======

最もありふれた Unix のニュースリーダーは、.newsrc と呼ばれる共用の起動ファイルを使います。このファイルは、講読しているグループと、それらのグループにおいてどの記事が読まれたかの、すべての情報を持っています。

GNUS ではものごとが少々複雑になっています。.newsrc ファイルを最新のものにするだけではなく、.newsrc ファイルには合わない情報を保存しておくために .newsrc.el と呼ばれるファイルを使います。(実際は .newsrc ファイルのすべての情報を複製して保持しています。) GNUS はこれらの中で一番最後に保存されたものを使います。これをすることにより、GNUS と他のニュースリーダーを切り替えて使うことができます。

これはちょっと間が抜けているので、Gnus はもっと良い方法を編み出しました。 .newsrc と .newsrc.el ファイルに加えて、 Gnus は .newsrc.eld と呼ばれるファイルも持っています。Gnus はこれらの中で一番新しいファイルを読みますが、.newsrc.el ファイルに書き込むことはありません。.newsrc.eld ファイルは絶対に消すべきではありません。---それは .newsrc ファイルにはないたくさんの情報を保持しています。

gnus-save-newsrc-file を nil にすることによって .newsrc ファイルに書き込むのを止めることができます。そうすれば、そのファイルを削除することができ、ディスク容量を節約することができ、 Gnus の終了が速くなります。しかし、そうすると他のニュースリーダーを使えなくなります。でも、ちょっと、誰かそうしたい人がいるでしょうか。同じように gnus-read-newsrc-file を nil にすることによって、 Gnus は .newsrc ファイルとすべての .newsrc-SERVER ファイルを無視するようになります。そのことは、あなたが時々違うニュースリーダーを使ったり、利用可能なグループの異なるサブセットをそれらのニュースリーダーで読みたい場合に、便利なことがあります。

gnus-save-killed-list (ディフォルト値は t) が nil であると、Gnus は削除されたグループを起動ファイルに保存しません。これは、(起動時と終了時の) 時間と、(ディスクの) 容量を節約します。こうすると Gnus がどのグループが新しいかの記録を持っていないことになるので、新しいグループの自動購読方法は意味が無くなります。この変数を nil にしたときは、gnus-check-new-newsgroups を常に nil か ask-server にしておくべきでしょう (see New Groups)。この変数は正規表現であることもできます。そのような場合は、ファイルを保存する直前にその正規表現に合致しないすべてのグループを消去します。これは、すべてのサーバーが ask-server を理解するわけではない、といったような、いくらかあいまいな状況のときに役に立つでしょう。

変数 gnus-startup-file は起動ファイルがどこにあるかを指定します。ディフォルト値は ~/.newsrc で、それがどのようなものであれ、末尾に .eld を付けたものが Gnus (El Dingo) の起動ファイルになります。このファイルのバージョン制御をしたいときは gnus-backup-startup-file をセットして下さい。それは version-control 変数と同じ値を取ります。

gnus-save-newsrc-hook は各種の newsrc ファイルのどれかを保存する前に実行されるのに対し、 gnus-save-quick-newsrc-hook は .newsrc.eld ファイルを保存する前に実行され、 gnus-save-standard-newsrc-hook は .newsrc ファイルを保存する前に実行されます。後の二つは普通はバージョン制御を on/off するのに使われます。ディフォルトでは、起動ファイルを保存するときにバージョン制御が行なわれます。バックアップファイルの作成を止めたいときは、次のようにして下さい。

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

     (add-hook 'gnus-save-quick-newsrc-hook 'turn-off-backup)
     (add-hook 'gnus-save-standard-newsrc-hook 'turn-off-backup)

Gnus が起動すると、gnus-site-init-file (ディフォルト値は .../site-lisp/gnus-init) と gnus-init-file (ディフォルト値は ~/.gnus) のファイルを読み込みます。これらは普通の Emacs Lisp ファイルで、~/.emacs や site-init ファイルを Gnus 関係のもので乱雑にしないようにするために使うことができます。 Gnus はこれらと同じ名前のファイルに、接尾語 .elc と .el が付いているものも調べます。言い換えれば、 gnus-init-file を ~/.gnus に設定すると、 Gnus は ~/.gnus.elc, ~/.gnus.el を探し、最後に ~/.gnus を (この順番に) 探します。-q または --no-init-file オプション (see Initial Options (The Emacs Editor)) が指定されて Emacs が起動された場合、 Gnus は gnus-init-file を読み込みません。

自動保存
====

何か Gnus のデータを変更すること (記事を読む、印を付ける、グループを削除または購読する) をしたとき、変更は特別な ドリブルバッファー (dribble buffer) に書き込まれます。このバッファーは Emacs が普通するように自動保存されます。.newsrc ファイルを保存する前に Emacs が落ちたときは、すべての変更をこのファイルから回復することができるでしょう。

起動時に Gnus がこのファイルの存在を発見すると、Gnus はそれを読み込むかどうかを利用者に尋ねます。本当の起動ファイルが保存されれば、自動保存ファイルは削除されます。

gnus-use-dribble-file が nil であると、Gnus はドリブルバッファーを作ったり、維持したりしません。ディフォルト値は t です。

Gnus はドリブルファイルを gnus-dribble-directory に置きます。ディフォルトではそのようになっていますが、この変数が nil であると、 Gnus は .newsrc ファイルの置かれているディレクトリー (これは普通は利用者のホームディレクトリーです) に入っていってドリブルファイルを作ります。ドリブルファイルは .newsrc と同じ許可属性を与えられます。

もし gnus-always-read-dribble-file が nil でなければ、 Gnus は利用者に尋ねること無く、ドリブルファイルを起動時に読み込みます。

アクティブファイル
=========

Gnus は起動したときや、実際に新しい記事が到着しているかを判定しようとするときに、アクティブファイルを読み込みます。これはとても大きなファイルで、そのサーバーの活動中のグループと記事のすべてのリストが入っています。

アクティブファイルを検査する前に、Gnus は正規表現 gnus-ignored-newsgroups に合うすべての行を削除します。これは主に偽の名前を持つグループを排除するために使われてきましたが、興味の無いグループの階層を無視するために使うこともできます。しかし、これはお勧めできません。本当のことを言うと、まったく賛成できません。代わりに、そのような用途に用いられる変数の概略を知るために、New Groups を参照して下さい。

アクティブファイルは比較的大きくなる傾向があるので、遅い回線を使っているときは、アクティブファイルを読み込まないように gnus-read-active-file を nil に設定することができます。この変数はディフォルトでは some です。

そのような時は、Gnus は実際に購読されているグループに関する情報だけを得てやっていこうとします。

気を付けてほしいのは、あなたが山ほどのたくさんのグループを購読しているときにこの変数を nil に設定すると、Gnus は速くなるどころか遅くなってしまうということです。現状では、ニュースを 2400bps 以上のモデムを通して読んでいるのでない限り、Gnus の速度はかなり遅くなるでしょう。

この変数は some という値も取ることができます。その時は、Gnus は購読しているグループに関する情報をだけを得ようとします。いくつかのサーバー (LIST ACTIVE group 命令を使うことのできる、最新鋭の INN サーバー) では、非常に早くなるでしょうが、他のサーバーでは速くはありません。どのようにせよ、遅い回線では some は nil よりも速く、それはもちろん t よりも速くなります。

いくつかのニュースサーバー (例えば古い Leafnode や古い INN) には LIST ACTIVE group 命令がありません。そういうサーバーには nil をこの変数の値に設定するのが、おそらくもっとも有効でしょう。

もしこの変数が nil であると、Gnus は完全にがんじがらめの方法でグループの情報を得ようとします。そして、これはあまり速くありません。もしそれが some で NNTP サーバーを使っているときは、Gnus はできるだけ速く命令を出し、一撃ですべての返答を読み込みます。この方が普通はより良い結果をもたらしますが、サーバーが LIST ACTIVE group 命令を理解しないなら、サーバーにとってはあまり良いとは言えません。

Gnus の起動にあまりに時間がかかると思ったなら、この変数にこれらの三つの違った値を試してみて、どれが一番良いかを探して下さい。

some か nil を使うのであれば、どちらにしろ速度を上げるためにすべての興味の無いグループを必ず削除するべきでしょう。

この変数は二次 (secondary) 選択方法のアクティブファイル取得にも影響することに気を付けて下さい。

起動変数
====

gnus-load-hook
     Gnus (のプログラム) が読み込まれるときに実行されるフックです。何度 Gnus を起動しても、Emacs が起動してから終了するまでに普通はこのフックは一回しか実行されないことに注意して下さい。

gnus-before-startup-hook
     Gnus の起動に成功した後に実行されるフックです。

gnus-startup-hook
     Gnus が起動された後に、一番最後に実行されるフックです。

gnus-started-hook
     Gnus の起動に成功した後に、一番最後に実行されるフックです。

gnus-setup-news-hook
     .newsrc ファイルを読み込んだ後で、グループバッファーを作成する前に実行されるフックです。

gnus-check-bogus-newsgroups
     もし nil でないと、Gnus は起動時にすべての偽グループを調べて削除します。偽グループ (bogus group) はあなたの .newsrc ファイルには存在するけれど、ニュースサーバーには実際には存在しない、というグループのことです。偽グループを調べるのにはかなり時間がかかるので、時間と資源を節約するために、この機能は使わないほうがいいでしょう。そして、代わりにグループバッファーで時々偽グループを調べるのが良いでしょう (see Group Maintenance)。

gnus-inhibit-startup-message
     もし nil でないと、起動時のメッセージは表示されません。そのようにすれば、仕事の代わりにニュースを読んでいるのを上司に気付かれにくくなるでしょう。この変数は ~/.gnus.el がロードされる前に使われるので、 .emacs に設定するべきである点を注意して下さい。

gnus-no-groups-message
     グループが一つも存在しないときに Gnus が表示するメッセージです。

gnus-play-startup-jingle
     もし nil でないと、起動時に Gnus の短い曲を演奏します。

gnus-startup-jingle
     上の変数が nil でないときに演奏される短い曲です。ディフォルト値は Tuxdemoon.Jingle4.au です。

グループバッファー
*********

グループバッファー (group buffer) は有効なグループを全部 (あるいは一部を) 一覧表示します。これは Gnus を起動したときに最初に表示されるバッファーで、Gnus が生きている限り決して消されることはありません。

グループバッファーの形式
============

グループ行の仕様
--------

グループバッファーのディフォルトの形式はきれいでつまんないけど、これは君の好きなように、サイコーにダサくすることもできます。

これがグループ行の例です。

          25: news.announce.newusers
      *    0: alt.fan.andrea-dworkin

とっても簡単でしょ?

news.announce.newusers には 25 の未読記事があるのがわかります。 alt.fan.andrea-dworkin には未読記事はないけれども、印を付けた記事がいくつかあります (行頭のちっちゃなアスタリスクが見える?)。

この形式は gnus-group-line-format 変数をいじることで、どんな風にでも変えられます。この変数は format の仕様風に動作します。つまり (あのクソ) C 言語を使う人たちのため、printf の仕様とほぼ同じです。 See Formatting Variables.

上記の行を生成するのは %M%S%5y:%B%(%g%)\n という値です。

コロンは、この行の中に必ず無くてはいけません。カーソルは何かの操作をした後は常にコロンのところに移動するからです。See Positioning Point. 他には何も必要ではありません---グループ名さえもです。表示されている文字はすべてただの画面の飾りであり、Gnus がそれを調べることはありません。Gnus は必要とするすべての実情報を、テキスト属性を使って憶えています。

(もし君が、すごくヘンな、素晴らしい、表計算風のレイアウトを作ったとしたら、みんな、君は会計の仕事が忙しくって、ニュースを読んで時間を無駄使いしたりなんかしてない、って信じてくれるよ。)

以下が使用できるフォーマット文字のリストです。

M
     そのグループに印のついた記事しか無いときは、アスタリスク文字。

S
     そのグループが購読されているかどうか。

L
     購読度のレベル。

N
     未読記事の数。

I
     保留記事の数。

T
     印付き記事の数。

R
     既読記事の数。

U
     まだ読まれたことが無い記事の数。

t
     推定全記事数 (これは実際は MAX-NUMBER - MIN-NUMBER + 1)。

     Gnus がこの推定を使うのは、NNTP プロトコルは能率の良い MAX-NUMBER と MIN-NUMBER へのアクセスを提供するものの、本当の未読記事の数を得るには必ずしも能率的ではないからです。ヒステリックなレーズン (訳注: 歴史的な理由のモジりか?) により、メールバックエンドにおいても、限定された同じインターフェースを使って、本当の未読記事の数を能率的に得ることはできるかもしれません。この制限を Gnus から取り払うことはバックエンドのインターフェースを変更することを意味し、それは楽な仕事ではありません。あなたがこの仕事をやりたいならば、どうぞ Gnus メーリングリストに連絡して下さい。

y
     未読でも、印付きでも、保留でもない記事の数。

i
     印付き記事と保留記事の数。

g
     グループ名のフルネーム。

G
     グループ名。

C
     グループのためのコメント (see Group Parameters)、またはグループパラメーターにコメントの要素が無い場合はグループ名。

D
     ニュースグループの説明。これらが現れる前に、グループの説明を読む必要があります。それには gnus-read-active-file を設定するか、グループバッファーで M-d コマンドを使って下さい。

o
     司会者付きの場合 m。

O
     司会者付きの場合 (m)。

s
     選択方法。

B
     そのグループの概略バッファーが開いているかどうか。

n
     どこからの選択か。(訳注: バックエンドのシンボル名)

z
     外部選択方法が使われている場合、<%s:%n> と同じ文字列。

P
     トピック (see Group Topics) のレベルに応じた字下げ。

c
     短い (省略した) グループ名。gnus-group-uncollapsed-levels 変数は、どのレベルまでグループ名を全部残すかを示します。ディフォルト値は 1 です---この意味は、gnu.emacs.gnus のようなグループ名を g.e.gnus に短縮するということです。

m
     そのグループに最近新着メールが届いている場合は % (gnus-new-mail-mark)。

p
     # (gnus-process-mark) で、そのグループにプロセス印が付いていることを示します。

d
     最後にいつこのグループを読んだかを示す文字列 (see Group Timestamp)。

F
     キャッシュとエージェントの両方によって取得された記事がディスクに占める容量。値はカラム幅を最小にするために、自動的にバイト (B)、キロバイト (K)、メガバイト (M)、またはギガバイト (G) に縮尺されます。固定幅カラム用には %7F の形式で足ります。

u
     利用者定義指定。フォーマット文字列中で、この次の文字はアルファベット文字でなければいけません。 Gnus は gnus-user-format-function-X 関数を呼び出します。ここで X は %u に続いている文字です。この関数は引数に一つのダミーパラメーターを渡されます。この関数は、他の各指定文字の情報と同様に、バッファーに挿入される文字列を返さなければなりません。

すべての「〜の数」の指定は、もしその情報が利用できない場合にはアスタリスク (*) で埋められます---例えば、起動されていない外部グループや、不正な基本グループの場合です。

グループモード行の仕様
-----------

モード行は gnus-group-mode-line-format (see Mode Line Formatting) を設定することで変更できます。こいつは指定文字をあんまりたくさん知っていません。

S
     基本ニュースサーバー。

M
     基本選択方法。

グループのハイライト
----------

グループバッファーのハイライトは gnus-group-highlight 変数によって制御されます。これは (FORM . FACE) のようなものを要素に持つ連想リストです。FORM が評価された結果が、nil 以外の何かになると、その行に対して FACE が使用されます。

以下がこの変数の値の例です。これは背景が暗い設定ではきれいに見えるかもしれません。

     (cond (window-system
            (setq custom-background-mode 'light)
            (defface my-group-face-1
              '((t (:foreground "Red" :bold t))) "First group face")
            (defface my-group-face-2
              '((t (:foreground "DarkSeaGreen4" :bold t))) "Second group face")
            (defface my-group-face-3
              '((t (:foreground "Green4" :bold t))) "Third group face")
            (defface my-group-face-4
              '((t (:foreground "SteelBlue" :bold t))) "Fourth group face")
            (defface my-group-face-5
              '((t (:foreground "Blue" :bold t))) "Fifth group face")))

     (setq gnus-group-highlight
           '(((> unread 200) . my-group-face-1)
             ((and (< level 3) (zerop unread)) . my-group-face-2)
             ((< level 3) . my-group-face-3)
             ((zerop unread) . my-group-face-4)
             (t . my-group-face-5)))

Faces and Fonts も参照して下さい。

この form が評価されるときに動的に束縛されている変数には以下のものがあります。

group
     グループ名。

unread
     そのグループの未読記事の数。

method
     選択方法。

mailp
     そのグループがメールのグループかどうか。

level
     そのグループのレベル。

score
     そのグループのスコア。

ticked
     そのグループ中の印の付いた記事の数。

total
     そのグループ中の全記事数。もっと正確に言うと、MAX-NUMBER マイナス MIN_NUMBER プラス 1.

topic
     トピックマイナーモードを使用している時、この変数は挿入されている現在のトピックに束縛されます。

この form が評価 (eval) されるときは、ポイントは問題のグループの行頭にあります。従って、通常の Gnus の関数のほとんどを使ってそのグループの情報を取ってくることができます。

gnus-group-update-hook はグループ行が変更されたときに呼び出されます。これは gnus-visual が nil のときは呼び出されません。このフックはディフォルトでは gnus-group-highlight-line を呼び出します。

グループ操作
======

すべての移動コマンドは数値接頭引数を理解するので、期待する通りの動作をします。たぶんね。

n
     次の未読記事のあるグループに移動します (gnus-group-next-unread-group)。

p
DEL
     一つ前の未読記事のあるグループに移動します (gnus-group-prev-unread-group)。

N
     次のグループに移動します (gnus-group-next-group)。

P
     一つ前のグループに移動します (gnus-group-prev-group)。

M-n
     一つ前の同じレベル (もしくはそれより小さいレベル) の未読グループに移動します (gnus-group-prev-unread-group-same-level)。

M-p
     次の同じレベル (もしくはそれより小さいレベル) の未読グループに移動します (gnus-group-next-unread-group-same-level)。

次の三つの命令はグループにジャンプするためのものです:

j
     グループにジャンプします (それが見えるようになっていなかったら見えるようにします) (gnus-group-jump-to-group)。kill されているグループも、生きているグループと同様にジャンプできます。

,
     最も小さいレベルの未読グループにジャンプします (gnus-group-best-unread-group)。

.
     最初の未読記事のあるグループにジャンプします (gnus-group-first-unread-group)。

gnus-group-goto-unread を nil にすると、すべての移動コマンドは、次の未読グループではなく次のグループに移動するようになります。そのコマンドが次の未読グループに移動すると言い張っていてもです。ディフォルト値は t です。

グループの選択
=======

SPACE
     現在のグループを選択し、概略バッファーに切り替えて最初の未読記事を表示します (gnus-group-read-group)。もしそのグループに未読記事が無い、もしくはこの命令に数値以外の接頭引数を与えると、Gnus はサーバーからこのグループのすべての古い記事を取得しようとします。N の数値接頭引数を与えると、Gnus の取得する記事数は N になります。N が正の数であれば Gnus は新しい方から N 個の記事を取得し、N が負の数であれば Gnus は古い方から abs(N) 個の記事を取得します。

     したがって、SPC では普通にグループに入り、C-u SPC では古い記事が現れます。C-u 4 2 SPC では 42 個の最新の記事を取得し、C-u - 4 2 SPC では 42 個の最も古い記事を取得します。

     グループにいる (概略バッファーにいる) ときは、M-g で新しい記事を取得できるし、C-u M-g では古い記事を表示することができます。

RET
     現在のグループを選択し、概略バッファーに切り替えます (gnus-group-select-group)。gnus-group-read-group と同じ引数を取ります---唯一の違いは、グループに入ったときに最初の未読記事を表示しない、ということです。

M-RET
     これは上記のコマンドと同じ動作をしますが、「ゴタゴタ」は最低限にしようとします (gnus-group-quick-select-group)。スコア・kill の処理は行なわれず、ハイライトも記事消去もしません。これは、あなたが本当に急いでいて、どっかのやたらでっかいグループに入らなければいけないときに役に立つかもしれません。また、接頭引数に 0 を与えれば (すなわち 0 M-RET)、 Gnus は概略バッファーを作ろうとさえしません。これは概略バッファーを作る前にスレッド表示を切り替えたいとき役に立ちます (see Summary Generation Commands)。

M-SPACE
     これは RET コマンドと同じ動作をするさらにもう一つのコマンドですが、このコマンドは記事消去と保留記事を隠す処理を行ないません (gnus-group-visible-select-group)。

C-M-RET
     最後にこのコマンドは、現在のグループを一度限り、その内容に一切の処理をすることのないように選択します (gnus-group-select-group-ephemerally)。スレッド表示さえも行なわれません。この方法で選択した後にこのグループに対して行なったことはすべて、その後に影響を与えることはありません。

gnus-large-newsgroup 変数は、何を大きなグループと考えるべきかを Gnus に与えます。nil だったら、どのグループも大きいと考えません。ディフォルト値は 200 です。グループに (未読と可視の) 記事がこの数以上あれば、Gnus はそのグループに入る前に利用者に確認を求めます。利用者はサーバーからいくつの記事を取得するかを指定できます。もし利用者が負の数 (-N) を指定すれば、古い方から N 個の記事を取得します。正の数であれば、新しく到着した方から N 個の記事を取得します。

gnus-large-ephemeral-newsgroup は gnus-large-newsgroup と同じですが、一時ニュースグループのためにだけ使われます。

もし gnus-auto-select-first が非-nil だったら、 SPACE コマンドでグループに入ったときに自動的に記事を選択します。どの記事が選択されるかは、変数 gnus-auto-select-subject で制御されます。この変数に設定できる有効な値は:

unread
     最初の未読記事の表題の行にポイントを移動させます。

first
     最初の記事の表題の行にポイントを移動させます。

unseen
     まだ読まれたことが無い最初の記事の表題の行にポイントを移動させます。

unseen-or-unread
     まだ読まれたことが無い最初の記事があれば、その記事の表題の行にポイントを移動させ、無かったら最初の未読記事の表題の行にポイントを移動させます。

best
     スコアが最も高い未読記事の表題の行にポイントを移動させます。

この変数は関数であることもできます。その場合、その関数は表題の行にポイントを移動させるために呼ばれます。

もしあるグループで自動記事選択をやめたいのであれば (例えばでっかい記事のあるバイナリグループでは、とか)、グループが選択されたときに呼び出される gnus-select-group-hook の中で変数 gnus-auto-select-first を nil に設定することができます。

購読制御コマンド
========

S t
u
     現在のグループを購読する/しないを切り替えます (gnus-group-unsubscribe-current-group)。

S s
U
     グループを購読するかどうかを確認し、購読します。すでに購読するようになっている場合には、購読を止めます (gnus-group-unsubscribe-group)。

S k
C-k
     現在のグループを kill します (gnus-group-kill-group)。

S y
C-y
     最後に kill したグループを yank します (gnus-group-yank-group)。

C-x C-t
     二つのグループの順序を置き換えます (gnus-group-transpose-groups)。これは本当は購読コマンドではありませんが、kill と yank を何度か続ける代わりにこのコマンドが使えます。

S w
C-w
     リージョン内のすべてのグループを kill します (gnus-group-kill-region)。

S z
     すべてのゾンビグループを kill します (gnus-group-kill-all-zombies)。

S C-k
     あるレベルのグループをすべて kill します (gnus-group-kill-level)。 kill した後、これらのグループを yank で戻すことはできないので、このコマンドはいくらか注意して使って下さい。このコマンドが本当に便利になるのは、 .newsrc に捨ててしまいたい未購読のグループがたくさんあるときだけです。レベル 7 で S C-k を行なうと、.newsrc ファイル中にメッセージ番号がない未購読グループをすべて kill します。

Group Levels も参照して下さい。

グループデータ
=======

c
     そのグループ内のすべての無印の記事を既読にします (gnus-group-catchup-current)。グループバッファーから既読にした場合は gnus-group-catchup-group-hook が呼び出されます。

C
     そのグループの全記事を、印付きの記事も含めて既読にします (gnus-group-catchup-current-all)。

M-c
     現在のグループのすべてのデータをクリアします---マークと既読記事のリストを消し去ります (gnus-group-clear-data)。

M-x gnus-group-clear-data-on-native-groups
     もし NNTP サーバーを別のものに切り替えたとすると、すべてのマークと既読情報はもう役には立ちません。このコマンドを使って基本グループのすべてのデータをクリアすることができます。注意して使ってね。

グループレベル
=======

すべてのグループは 購読度 (subscribedness) のレベルを持ちます。例えば、あるグループがレベル 2 だとすれば、それはレベル 5 のグループよりも「より購読している」ということです。Gnus に対して、あるレベルかそれより小さいレベルのグループのみ一覧表示するように頼むこともできるし (see Listing Groups)、あるレベルかそれより小さいレベルのグループの新着記事のみを確認することもできます (see Scanning New Messages)。

忘れないで: グループのレベルが大きいほど、重要度は低くなるということ。

S l
     現在のグループのレベルを設定します。数値の接頭引数が与えられると、そこから N 個のグループのレベルが設定されます。レベルを入力するためのプロンプトが出ます。

Gnus はレベル 1 から gnus-level-subscribed (この値を含む) (ディフォルト値は 5) までのグループを購読、gnus-level-subscribed (この値を含まない) から gnus-level-unsubscribed (この値を含む) (ディフォルト値は 7) までのグループを非購読、gnus-level-zombie をゾンビ (歩く屍) (ディフォルト値は 8)、gnus-level-killed を kill されている (完全に死んでる) (ディフォルト値は 9) と判断します。Gnus は購読と非購読のグループはまったく同様に扱いますが、ゾンビと kill グループは、どの記事を読んだか、存在するかなどの情報を一切持ちません。この死んでるグループと生きてるグループの区別は、別にそれがきれいだからとか賢いからというわけではなく、純粋に効率的な理由のためです。

メール用のグループは (もしあれば) 非常に小さいレベル (例えば 1 か 2) にしておくことをお勧めします。

次の Gnus のディフォルトの動作の説明は、ことによると、これらのレベルのすべてを理解する助けになるかもしれません。ディフォルトでは、Gnus は講読している空でないグループを表示しますが、L を叩くことによって空のグループや非講読のグループも表示させることができます。つまり、非講読のグループは隠されている、と言っても良いでしょう。

ゾンビと kill グループは、ディフォルトでは隠されている点で非講読のグループに似ています。しかし、Gnus がニュースサーバーに対してゾンビと kill グループに関する情報 (記事数、未読記事数) の問い合わせをしない点で、購読および非購読のグループとは違っています。ふつう、あなたは興味の無いグループを C-k で kill しますよね。もし、ほとんどのグループが kill されていると、Gnus は速くなります。

なぜ Gnus はゾンビと kill グループを区別するのでしょう?  ええと、サーバーに新しいグループができると、Gnus はディフォルトでそれをゾンビにします。これは、あなたがふつうは新しいグループに煩わされないことを意味しますが、あなたは A z で新しいグループのリストを得ることができます。あなたは好みのものを講読し、要らないものは kill すれば良いのです。 (A k で kill されたグループのリストを表示します。)

もしレベル変数で遊びたいのであれば、多少注意をしてまわる必要があります。いったんそれを設定したら、二度とそれに触らないで下さい。さらに言えば、自分で何をやっているかを正確に理解していない限り、一切触らないで下さい。

身近に関係する二つの変数は gnus-level-default-subscribed (ディフォルト値は 3) と gnus-level-default-unsubscribed (ディフォルト値は 6) です。これらは新しいグループが (非) 購読されたときのレベルです。もちろん、これら二つの変数の値は、意味のある正しい範囲でなくてはなりません。

gnus-keep-same-level が nil 以外であれば、移動コマンドのいくつかは同一 (あるいはそれより小さい) レベルのグループのみの移動になります。特に、あるグループの最後の記事から次のグループに移るとき、次の同一 (あるいはそれより小さい) レベルのグループに移動します。これは残りのグループを読むより先に、より重要なグループを読んでおきたいときには便利かもしれません。

もしこの値が best だったら、最も重要な (最もレベルの値が小さい) グループに移動します。

ディフォルトでは gnus-group-default-list-level と同じかそれより小さいレベルのグループが、グループバッファーに一覧表示されます。

gnus-group-list-inactive-groups が nil 以外であれば、未読のグループにアクティブでないグループも一緒に表示します。この変数はディフォルトでは t です。もしこれが nil であれば、アクティブでないグループは表示されません。

gnus-group-use-permanent-levels が nil 以外であれば、いったん g や l コマンドの接頭引数にレベルを与えると、その後のすべてのコマンドにおいてそのレベルが「作用する」レベルになります。

Gnus は通常、gnus-activate-level かそれより小さいレベルのグループのみを起動します (つまりサーバーに問い合わせをする)。購読していないグループを起動したくなければ、この変数を例えば 5 に設定するとよいかもしれません。ディフォルトは 6 です。

グループのスコア
========

普通は重要なグループは高レベルにしておくでしょうけれども、この方法では少々制限がきついですよね。ひょっとしたら、グループをどれくらい頻繁に読むかによってグループバッファーを並べ替えたいなあ、なんて思いませんか? 理にかなってるでしょ?

グループスコア (group score) はそのためのものです。Gnus に以下で説明されている機構で、それぞれのグループに対してスコアを指定することができます。そしてグループバッファーをこのスコアを基に並べ替えることができます。あるいは、スコア順で並べ替えてその後レベルで並べ替えることもできます。(レベルとスコアをひとまとめにして、グループの ランク (rank) と呼びます。レベルが 4 でスコアが 1 のグループは、レベルが 5 でスコアが 300 のグループよりも高いランクとなります。 (レベルの方が重要度が高く、スコアの方は重要度が低くなります。))

頻繁に読むグループに、めったに読まないグループよりも高いスコアを与えたいときは、gnus-summary-exit-hook フックに gnus-summary-bubble-group 関数を追加することができます。これでバブル並べ替えの実行結果が (並べ替えの後で) 得られるでしょう。概略モードを終了するたびにこの活動をさせたいのであれば、同じフックに gnus-group-sort-groups-by-rank または gnus-group-sort-groups-by-score を追加できますが、いくらか遅くなるでしょう。

グループへの印
=======

もしいくつかのグループに対して何らかの命令を実行したい場合で、それらがグループバッファーに連続してある場合には、通常通り命令に対して数値接頭引数を与えるだけです。そうすればほとんどのグループ命令は、これらのグループに対してあなたの命令に従います。

しかしそれらのグループが順番に並んでいない場合においても、いくつかのグループに対して命令を実行することができます。単に始めにプロセス印でグループに印を付けておき、そして命令を実行するだけです。

#
M m
     現在のグループに印を付ける (gnus-group-mark-group)。

M-#
M u
     現在のグループから印を削除する (gnus-group-unmark-group)。

M U
     すべてのグループから印を削除する (gnus-group-unmark-all-groups)。

M w
     ポイントとマークの間のすべてのグループに印を付ける (gnus-group-mark-region)。

M b
     バッファー内のすべてのグループに印を付ける (gnus-group-mark-buffer)。

M r
     ある正規表現に合致するすべてのグループに印を付ける (gnus-group-mark-regexp)。

Process/Prefix も参照して下さい。

プロセス印が付けられているすべてのグループに対して何かの命令を実行したいときは、M-& (gnus-group-universal-argument) 命令を使うことができます。プロンプトから実行したい命令を入力します。

外部グループ
======

以下では、一般的な外部グループの作成、変更を行なうグループモードの命令をいくつか、および特別な目的のグループを簡単に作成する命令を紹介します。これらの命令はすべて、新規に作成したグループをポイント位置に挿入します---gnus-subscribe-newsgroup-method は参照されません。

G m
     新しいグループを作成します (gnus-group-make-group)。Gnus はプロンプトを表示して、名前と方法と、場合によっては address の入力を求めてきます。より簡単に NNTP グループを購読する方法については、 Browse Foreign Server を参照して下さい。

G M
     一時ニュースグループを作成します (gnus-group-read-ephemeral-group)。 Gnus はプロンプトを表示して、名前、方法および address の入力を求めます。

G r
     現在のグループの名前を、何か別のものに変更します (gnus-group-rename-group)。これはある種のグループ---主にメールグループに対してのみ有効です。このコマンドはバックエンドによっては非常に遅いことも有り得ます。

G c
     グループパラメーターをカスタマイズする (gnus-group-customize)。

G e
     現在のグループの選択方法を修正するためのバッファーに移動します (gnus-group-edit-group-method)。

G p
     グループパラメーターを修正するためのバッファーに移動します (gnus-group-edit-group-parameters)。

G E
     グループ情報を修正するためのバッファーに移動します (gnus-group-edit-group)。

G d
     ディレクトリーグループを作成します (see Directory Groups)。ディレクトリー名をプロンプトで入力します (gnus-group-make-directory-group)。

G h

     Gnus ヘルプグループを作成します (gnus-group-make-help-group)。

G a
     Gnus アーカイブグループを作成します (gnus-group-make-archive-group)。ディフォルトでは最も最近の記事を指しているグループが作成されますが (gnus-group-recent-archive-directory)、接頭引数を与えるとすべての記事を含むグループが gnus-group-archive-directory を基に作成されます。

G k
     kiboze グループを作成します。プロンプトで名前と、kiboze グループに「含めたい」グループに合う正規表現と、ヘッダーに合う文字列の組を入力します (gnus-group-make-kiboze-group)。See Kibozed Groups.

G D
     任意のディレクトリーを nneething バックエンドニュースグループであるかのように読み込みます (gnus-group-enter-directory)。 See Anything Groups.

G f
     ファイルなどをもとにグループを作成します (gnus-group-make-doc-group)。このコマンドに接頭引数を与えた場合、ファイル名とファイルタイプをプロンプトで入力します。現在サポートされているファイルタイプは mbox, babyl, digest, news, rnews, mmdf, forward, rfc934, rfc822-forward, mime-parts, standard-digest, slack-digest, clari-briefs, nsmail, outlook, oe-dbx および mailman です。接頭引数なしでこのコマンドを実行すると、Gnus はファイルタイプを推測します。See Document Groups.

G u
     gnus-useful-groups にあるグループの一つを作ります (gnus-group-make-useful-group)。

G w
     ウェブ検索結果をもとに一時的なグループを作成します (gnus-group-make-web-group)。このコマンドに接頭引数を与えると、一時的ではなく固定したグループを作成します。プロンプトで検索エンジンの種類 (search engine type) と検索文字列を入力します。有効な検索エンジンの種類には google, dejanews, gmane があります。 See Web Searches.

     もし、google 検索エンジンを用いる場合には、 shaving group:alt.sysadmin.recovery のような合致する文字列を用いることによって、検索対象を特定のグループに限定することが可能です。

G R
     RSS feed に基づくグループを作ります (gnus-group-make-rss-group)。URL の入力を促されます。 See RSS.

G DEL
     この関数は現在のグループを削除します (gnus-group-delete-group)。接頭引数が与えられると、この関数はそのグループ内の全記事を本当に削除し、グループ自身をこの世から強制的に抹殺してしまいます。接頭引数は、あなたが何をやろうとしているか、本当に自信があるときにのみ使って下さい。まあ、このコマンドは (nntp グループのような) 読み出し専用グループには使えませんけれど。

G V
     新しい、新鮮な、空の nnvirtual グループを作成します (gnus-group-make-empty-virtual)。See Virtual Groups.

G v
     現在のグループを nnvirtual グループに追加します (gnus-group-add-to-virtual)。これはプロセス印/接頭引数の習慣に従います。

さまざまな選択方法に関するさらなる情報は Select Methods を参照して下さい。

もし gnus-activate-foreign-newsgroups が正の数であれば、Gnus は起動時に、この数かそれよりも小さいレベルの外部グループをすべてチェックします。これは特に違った NNTP サーバーからたくさんのグループを購読している場合には、しばらく時間がかかるかもしれません。 Group Levels も参照して下さい。gnus-activate-level も外部ニュースグループの活性化に影響を及ぼします。

グループパラメーター
==========

グループパラメーターは、ある特定のグループに固有な情報を保持します。以下はグループパラメーターリストの例です:

     ((to-address . "ding@gnus.org")
      (auto-expire . t))

それぞれの要素は『点対』(dotted pair)---つまり点 (dot) の前に鍵、点の後ろに値があるもの、で構成されます。すべてのパラメーターはこの形式を取りますが、例外 として局所変数の指定は点対ではなく通常のリストになります。

いくつかのパラメーターは対応するカスタマイズ可能な変数を持っています。それらは正規表現と値の連想リストです。

以下は利用可能なグループパラメーターです:

to-address
     フォローアップとニュースへの投稿をするときに使用されるアドレス。

          (to-address . "some@where.com")

     これは主に、閉じたメーリングリストを表わすメールグループにおいて便利なものです---すなわちメーリングリストに投稿する人はすべてそれを購読しているはず、というメーリングリストのことです。このパラメーターを使用すると、メールはそのメーリングリストにしか投稿されないことが保証されるので、参加者はあなたのフォローアップ記事を二通受け取ることはありません。

     to-address を指定すると、そのグループが外部グループであるかどうかに関わらず有効になります。例えば fa.4ad-l というグループがサーバー上にあったとしましょう。これは本当のニュースグループですが、サーバーはメールニュースゲートウェイを通して記事を受け付けます。つまりこのグループに対して直接投稿することは不可能で、代わりにそのメーリングリストにメールを送信しなければなりません。

     gnus-parameter-to-address-alist も参照して下さい。

to-list
     そのグループで a を押したときに使用されるアドレス。

          (to-list . "some@where.com")

     これはフォローアップをしたときは完全に無視されます---例外はそれがニュースグループを表わしているときは、f を押したときにメールグループのルールが適用されるということです。

     もし a コマンドをメールグループで実行したときに、to-list グループパラメーターも to-address もグループパラメーターも無ければ、 to-list グループパラメーターは、 gnus-add-to-list が t に設定されていればメッセージ送信時に自動的に付加されます。

     もしこのグループパラメーターが設定されていると、概略バッファーに入ったときに gnus-mailing-list-mode が有効になります。

     gnus-parameter-to-list-alist も参照して下さい。

subscribed
     もしこのパラメーターが t に設定されていると、Gnus はあなたがこのグループを to-address と to-list パラメーターのアドレスで購読しているメーリングリストであると解釈します。この情報を Gnus に与えることは、あなたがそれらのメーリングリストに投稿するときに正しい Mail-Followup-To ヘッダーを生成するための (ほんの) 第一歩です。二歩目は .gnus.el に以下を入れることです。

          (setq message-subscribed-address-functions
                '(gnus-find-subscribed-addresses))

     利用できる MFT 対応機能を完全に扱うには、ここ (see メーリングリスト (The Message Manual)) を見て下さい。

visible
     グループパラメーターのリスト中に (visible . t) という要素があれば、そのグループはグループバッファーにおいて、未読記事があるかどうかに関わらず、常に表示されます。

broken-reply-to
     (broken-reply-to . t) という要素があれば、そのグループでは Reply-To は無視され、 reply-to が gnus-boring-article-headers の部分であれば、ヘッダーが隠されるという意味です。これはある listserv によるメーリングリストを購読していて、それが Reply-To 欄を listserv 自身に返すように付けられている場合に有効でしょう。これはおかしな振る舞いです。だからこれが要るんです!

to-group
     (to-group . "some.group.name") という要素は、そのグループへの投稿はすべて some.group.name に送られる、という意味です。

newsgroup
     グループパラメーターリストに (newsgroup . t) があれば、Gnus はすべての応答をニュース記事に対する応答であるかのように扱います。これは実際にはニュースグループのミラーであるメールグループに対して有効です。

gcc-self
     グループパラメーターリストに (gcc-self . t) があれば、新しく作成するメッセージは現在のグループに Gcc されます。もし (gcc-self . none) があれば、Gcc: 欄は生成されず、 (gcc-self . "string") があればこの文字列はそのまま gcc 欄に挿入されます。このパラメーターは以下で説明するどんなディフォルトの Gcc の規則よりも優先されます (see Archived Messages)。

     警告: nntp (またはその種の) グループのパラメーターリストに (gcc-self . t) を加えることに効力はありません。nntp サーバーは記事を受け入れません。

auto-expire
     グループパラメーターに (auto-expire . t) のような要素があれば、すべての既読記事は期限切れ消去されるように印を付けられます。他の方法は、 see Expiring Mail.

     gnus-auto-expirable-newsgroups も参照して下さい。

total-expire
     グループパラメーターに (total-expire . t) のような要素があれば、既読記事は、期限切れ消去の印が付いていなくてもすべて期限切れ消去処理を施されます。注意して使用して下さい。未読記事、印付き記事、保留記事は期限切れ消去されません。

     gnus-total-expirable-newsgroups も参照して下さい。

expiry-wait
     グループパラメーターに (expiry-wait . 10) のような要素があれば、この値は記事を期限切れ消去するときに nnmail-expiry-wait と nnmail-expiry-wait-function の設定 (see Expiring Mail) よりも優先されます。この値は期限切れ消去の日数 (整数である必要はない) かもしくは never か immediate のシンボルを指定できます。

expiry-target
     期限切れ消去されるメッセージの果てる場所。このパラメーターは nnmail-expiry-target よりも優先されます。

score-file
     (score-file . "file") のような要素は、file を現在のグループに適用されるスコアファイルにします。適用されるスコア項目はすべてこのファイルに入ります。

adapt-file
     (adapt-file . "file") のような要素は、file を現在のグループの適応ファイルにします。すべての適応スコア項目はこのファイルに入ります。

admin-address
     メーリングリストから脱会するときは、脱会通知メールをそのメーリングリスト自身に送信してはいけません。代わりに管理用アドレスにメッセージを送信します。このパラメーターにはどこか都合の良いな管理用アドレスを書いておくことができます。

display
     (display . MODE) のような要素は、グループに入るときにどの記事を表示するかを指定します。有効な値は、

     all
          未読、既読記事の両方をすべて表示します。

     an integer
          そのグループの最後の INTEGER 個の記事を表示します。これは C-u INTEGER でそのグループに入るのと同じです。

     default
          ディフォルトの記事を表示します。これは通常は未読記事と可視記事です。

     配列
          述語を満足するように記事を表示します。

          いくつか例を挙げます:

          [unread]
               未読の記事だけを表示します。

          [not expire]
               期限切れ消去可能な記事以外のすべてを表示します。

          [and (not reply) (not expire)]
               期限切れ消去可能とすでに返信した記事以外のすべてを表示します。

          利用できる演算子は not, and および or です。述語は tick, unsend, undownload, unread, dormant, expire, reply, killed, bookmark, score, save, cache, forward, unseen および recent を含みます。

     display パラメーターは、概略バッファーを指定した一部の組だけに制限するように働きます。制限を外すのは / w コマンドでできます (see Limiting)。

comment
     (comment . "This is a comment") のような要素は、そのグループに対する任意のコメントです。グループ行に表示することができます (see Group Line Specification)。

charset
     (charset . iso-8859-1) のような要素は、iso-8859-1 をディフォルトの文字セットにします。すなわち、文字セットを指定しないすべての記事に、その文字セットが使われます。

     gnus-group-charset-alist も見て下さい。

ignored-charsets
     (ignored-charsets x-unknown iso-8859-1) のような要素は、 iso-8859-1 と x-unknown を無視します。すなわち、記事のデコードにディフォルトの文字セットが使われます。

     gnus-group-ignored-charsets-alist も見て下さい。

posting-style
     このグループの追加の投稿様式をここに保存することができます (see Posting Styles)。書式は gnus-posting-style 連想リストと同じですが、ここにはグループ名に合致する正規表現はありません (当然です)。このグループの様式の要素は gnus-posting-styles で見つかったものよりも優先されます。

     例えば、このグループのみ、かっこいい名前と署名にしたいなら、 gnus-posting-styles をいじらずに、このようなものをグループパラメーターに入れることができます:

          (posting-style
            (name "Funky Name")
            ("X-My-Header" "Funky Value")
            (signature "Funky Signature"))

post-method
     もしこれが設定されていると、メッセージを送信するための選択方法として gnus-post-method の代わりに使われます。

banner
     (banner . REGEX) のような項目は、記事のすべての場所で正規表現 REGEX に合致するものを削除します。REGEX の代わりにシンボル signature (最後の署名を削除) や連想リスト gnus-article-banner-alist の各要素を使うこともできます。

sieve
     このパラメーターは、入ってきたメールがこのグループに置くに値するかどうかを調べる Sieve (ふるい) テストを持ちます。このグループパラメーターを元に fileinto "group.name"; というテスト条件を本体に持つ、 Sieve の IF 制御構造体が作られます。

     例えば、もし INBOX.list.sieve グループが (sieve address "sender" "sieve-admin@extundo.com") というグループパラメーターを持っていたならば、グループパラメーターを Sieve スクリプトに変換する (see Sieve Commands) ときに、以下の Sieve コードが作られます:

          if address "sender" "sieve-admin@extundo.com" {
                  fileinto "INBOX.list.sieve";
          }

     複数の電子メールアドレスのためのテストを生成するには、(sieve address "sender" ("name@one.org" else@two.org")) のようなグループパラメーターを使って下さい。Sieve スクリプト (see Sieve Commands) を生成すると、以下のような Sieve コードが作られます:

          if address "sender" ["name@one.org", "else@two.org"] {
                  fileinto "INBOX.list.sieve";
          }

     Sieve パラメーターに関連する重要なコマンドと変数については、Sieve Commands を参照して下さい。

     Sieve 言語は RFC 3028 で述べられています (see Emacs Sieve)。

(agent parameters)
     エージェントを使うようにしてあると、個々のグループでエージェントの振る舞いを制御するどのパラメーターも設定することができます。エージェントパラメーターについては Category Syntax を参照して下さい。たいていの利用者は、設定に要する苦労を最小限にするために、エージェントカテゴリーかグループトピックのどちらかでエージェントパラメーターを設定することを選ぶでしょう。

(VARIABLE FORM)
     グループに入るときに、そのグループローカルの変数を設定するグループパラメーターを使用することができます。news.answers においてスレッド表示を行ないたくないときは、そのグループにグループパラメーターに (gnus-show-threads nil) と書けます。 gnus-show-threads は、その概略バッファーの中のローカル変数になり、 form の nil はそこで評価されます。

     この機能は、変数を概略バッファーでローカルに設定することに注意して下さい。でも、いくつかの変数は記事バッファーか (返信、フォロー、あるいは新規に作られたメッセージの) メッセージバッファーで評価されます。代わりに、問題の変数を gnus-newsgroup-variables に加えることが助けになるかもしれません。したがって、グループパラメーターを介して message-from-style を設定したいならば、~/.gnus ファイルのどこか他のところに、次の述語が必要になるかもしれません:

          (add-to-list 'gnus-newsgroup-variables 'message-from-style)

     この機能の用途の一つは、記事の表題欄からメーリングリストの標識タグをはぎ取ることです。もしニュースグループ

          nntp+news.gnus.org:gmane.text.docbook.apps

     が、すべての記事の表題に DOC-BOOK-APPS: というタグを持っているならば、そのグループのグループパラメーターに (gnus-list-identifiers "DOCBOOK-APPS:") を入れることによって、そのグループの概略バッファーに表示される記事の表題からタグをはぎ取ることができます。

     これはもし必要であれば、グループ毎のフック関数としても使用できます。もしあるグループに入ったときにビープ音を鳴らしたければ、そのグループのパラメーターに (dummy-variable (ding)) みたいなものを書いておくこともできます。dummy-variable という変数に (無意味な) (ding) の評価結果が設定されます。

     あるいは、VARIABLE はそのグループに対してローカルになるので、この様式は一時的にフックを変更するために使うことができます。例えば、以下のものがグループパラメーターに追加されると、

          (gnus-summary-prepared-hook
            '(lambda nil (local-set-key "d" (local-key-binding "n"))))

     そのグループに入ったときに d キーは記事に期限切れ消去の印を付けないようになります。

グループパラメーターの修正には G p か G c 命令を使って下さい (G p は Lisp ベースの、G c は Custom ふうのインターフェースを提供します)。トピックパラメーターについて読んでみることも面白いでしょう (see Topic Parameters)。

グループパラメーターは gnus-parameters 変数を介在して設定することもできます。でもいくつかのパラメーター、例えば visible は効力を発揮しません。例です。

     (setq gnus-parameters
           '(("mail\\..*"
              (gnus-show-threads nil)
              (gnus-use-scoring nil)
              (gnus-summary-line-format
               "%U%R%z%I%(%[%d:%ub%-23,23f%]%) %s\n")
              (gcc-self . t)
              (display . all))

             ("^nnimap:\\(foo.bar\\)$"
              (to-group . "\\1"))

             ("mail\\.me"
              (gnus-use-scoring  t))

             ("list\\..*"
              (total-expire . t)
              (broken-reply-to . t))))

文字列の値は、to-group の例が示すように、正規表現による置き換えを受けることがあります。

グループの一覧表示
=========

これらのコマンドは、利用できるグループをいろいろに切り分けて表示します。

l
A s
     未読記事を持つすべてのグループを表示します (gnus-group-list-groups)。数値接頭引数を使うと、このコマンドは引数の数かそれよりも小さいレベルのグループのみを表示します。ディフォルトでは、これはレベル 5 (つまり gnus-group-default-list-level) かそれより小さいレベル (すなわち購読しているグループのみ) を表示します。

L
A u
     未読記事のあるなしに関わらず、すべてのグループを表示します (gnus-group-list-all-groups)。数値接頭引数を使用すると、このコマンドは引数の数かそれよりも小さいレベルのグループのみを表示します。ディフォルトでは 7 かそれよりも小さいレベルのグループ (すなわち購読、非購読のグループのみ) が表示されます。

A l
     未読記事があるグループのうち、指定したレベルのものだけを表示します (gnus-group-list-level)。接頭引数を与えると、未読記事の無いグループも含めて表示します。

A k
     kill されたグループをすべて表示します (gnus-group-list-killed)。接頭引数を与えると、購読または非購読のどちらにもなっていないすべての利用可能なグループを表示します。これはサーバーからアクティブファイルを読むことになるでしょう。

A z
     すべてのゾンビグループを表示します (gnus-group-list-zombies)。

A m
     正規表現に合致する名前を持つグループで、未読記事のある購読グループをすべて表示します (gnus-group-list-matching)。

A M
     正規表現に合致するグループを表示します (gnus-group-list-all-matching)。

A A
     今接続しているサーバーのアクティブファイルにあるグループを、本当に全部表示します (gnus-group-list-active)。これはしばらく時間がかかることも有り得ます。たぶん A M を実行して、合致させたい部分を . としてすべての合致するリストを表示させた方が良いでしょう。また、このコマンドは (まだ) 存在しないグループも表示するかもしれません---これは kill されたグループであるかのように表示されます。出力は多少割り引いて受け取ってね。

A a
     正規表現に合致する名前を持つグループをすべて表示します (gnus-group-apropos)。

A d
     正規表現に合致する名前か説明文を持つグループをすべて表示します (gnus-group-description-apropos)。

A c
     キャッシュ記事を持つグループをすべて表示します (gnus-group-list-cached)。

A ?
     保留記事を持つグループをすべて表示します (gnus-group-list-dormant)。

A /
     現在の選択された範囲に限定したグループを表示します (gnus-group-list-limit)。

A f
     現在の選択されたグループを書き出します (gnus-group-list-flush)。

A p
     現在の選択されたグループを加えたグループを表示します (gnus-group-list-plus)。

gnus-permanently-visible-groups 正規表現に合致するグループは、未読記事があるかないかに関わらず常に表示されます。あるいはグループパラメーターにおいて visible 要素を追加することでも同様の効果を得ることができます。

印付きの記事のみを持つグループは通常グループバッファーに表示されます。もし gnus-list-groups-with-ticked-articles が nil であれば、そのグループは完全に空のグループであるかのように扱われます。ディフォルト値は t です。

グループの並べ替え
=========

C-c C-s (gnus-group-sort-groups) 命令は、グループバッファーを gnus-group-sort-function 変数で与えられる関数に従って並べ替えます。利用可能な並べ替え関数 (sorting function) には以下のものがあります:

gnus-group-sort-by-alphabet
     グループ名でアルファベット順に並べ替えます。これがディフォルトです。

gnus-group-sort-by-real-name
     グループを本当の (前に何も付いていない) グループ名でアルファベット順に並べ変えます。

gnus-group-sort-by-level
     グループレベルで並べ替えます。

gnus-group-sort-by-score
     グループのスコアで並べ替えます。See Group Score.

gnus-group-sort-by-rank
     グループのスコアで並べ替え、次にグループレベルで並べ替えます。レベルとスコアは、ひとまとめにして ランク と呼ばれます。See Group Score.

gnus-group-sort-by-unread
     未読記事の数で並べ替えます。

gnus-group-sort-by-method
     選択方法のアルファベット順で並べ替えます。

gnus-group-sort-by-server
     サーバー名のアルファベット順で並べ替えます。

gnus-group-sort-function は並べ替え関数のリストであっても構いません。この場合、もっとも重要な並べ替えの鍵を持つ関数は最後でなくてはなりません。

ある種の並べ替え用には、直接並べ替える命令もいくつかあります。

G S a
     グループバッファーをグループ名のアルファベット順で並べ替えます (gnus-group-sort-groups-by-alphabet)。

G S u
     グループバッファーを未読記事の数で並べ替えます (gnus-group-sort-groups-by-unread)。

G S l
     グループバッファーをグループレベルで並べ替えます (gnus-group-sort-groups-by-level)。

G S v
     グループバッファーをグループのスコアで並べ替えます (gnus-group-sort-groups-by-score)。See Group Score.

G S r
     グループバッファーをグループのランクで並べ替えます (gnus-group-sort-groups-by-rank)。See Group Score.

G S m
     グループバッファーをバックエンドの名前でアルファベット順に並べ替えます (gnus-group-sort-groups-by-method)。

G S n
     グループバッファーを本当の (前に何も付いていない) グループ名でアルファベット順に並べ替えます (gnus-group-sort-groups-by-real-name)。

以下のすべての命令はプロセス/接頭引数の習慣に従います (see Process/Prefix)。

シンボル接頭引数 (see Symbolic Prefixes) が与えられたときは、これらすべての命令は逆順で並び換えます。

また、グループの一部を並べ替えることもできます。

G P a
     グループをグループ名のアルファベット順で並べ替えます (gnus-group-sort-selected-groups-by-alphabet)。

G P u
     グループを未読記事の数で並べ替えます (gnus-group-sort-selected-groups-by-unread)。

G P l
     グループをグループレベルで並べ替えます (gnus-group-sort-selected-groups-by-level)。

G P v
     グループをグループのスコアで並べ替えます (gnus-group-sort-selected-groups-by-score)。 See Group Score.

G P r
     グループをグループのランクで並べ替えます (gnus-group-sort-selected-groups-by-rank)。See Group Score.

G P m
     グループをバックエンドの名前でアルファベット順に並べ替えます (gnus-group-sort-selected-groups-by-method)。

G P n
     グループを本当の (前に何も付いていない) グループ名でアルファベット順に並べ替えます (gnus-group-sort-selected-groups-by-real-name)。

G P s
     グループを gnus-group-sort-function に従って並べ替えます。

最後に、C-k と C-y を使って、手動でグループをあちこちに移動できることもお忘れなく。

グループの管理
=======

b
     不正なグループを見つけて、削除します (gnus-group-check-bogus-groups)。

F
     新しいグループを見つけて、それらを処理します (gnus-group-find-new-groups)。一回の C-u の後で押されると、サーバーに新しいグループを尋ねるために ask-server の方法を使います。二回の C-u の後で押されると、サーバーに新しいグループを尋ねるために最も完全であると思われる方法を用い、新しいグループをゾンビとして購読します。

C-c C-x
     現在のグループの期限切れ消去可能な記事に対して (もしあれば) すべて期限切れ消去の処理を行ないます (gnus-group-expire-articles)。これは、そのグループにしばらく存在していた期限切れ消去可能なすべての記事を消去するということです。(see Expiring Mail)。

C-c C-M-x
     すべてのグループのすべての期限切れ消去可能な記事に対して、期限切れ消去の処理を行ないます。(gnus-group-expire-all-groups)。

外部サーバーの閲覧
=========

B
     選択方法とサーバー名を聞かれます。Gnus はこのサーバーに接続し、そこにあるグループを閲覧しようとします (gnus-group-browse-foreign-server)。

利用可能なグループのリストを持った新しいバッファーが現れます。このバッファーは gnus-browse-mode を使用します。このバッファーは通常のグループバッファーにちょっと (というか、とっても) 似ています。

以下が閲覧モード (browse mode) で使用できるキー操作のリストです:

n
     次のグループに移動します (gnus-group-next-group)。

p
     一つ前のグループに移動します (gnus-group-prev-group)。

SPACE
     現在のグループに入り、最初の記事を表示します (gnus-browse-read-group)。

RET
     現在のグループに入ります (gnus-browse-select-group)。

u
     現在のグループを非購読にします。と言うよりは (訳注: このコマンドはトグルなので)、この場合は購読することになるのでしょうけれど (gnus-browse-unsubscribe-current-group)。

l
q
     閲覧モード (browse mode) を終了します (gnus-browse-exit)。

d
     現在のグループを購読にします (gnus-browse-describe-group)。

?
     閲覧モード (browse mode) を簡単に説明します (まあ、大して説明することもないんですけれどね) (gnus-browse-describe-briefly)。

Gnus の終了
========

そう、Gnus は最後 (サイコー) です (訳注: く、苦しい。原文は ``Yes, Gnus is ex(c)iting.'')。

z
     Gnus を中断します (gnus-group-suspend)。これは Gnus を実際には終了させず、グループバッファー以外のすべてのバッファーを消すだけです。僕はこれのうれしさがよくわかんないんだけど、誰か分かる人います?

q
     Gnus を終了します (gnus-group-exit)。

Q
     .newsrc ファイルを保存せずに Gnus を終了します (gnus-group-quit)。ドリブルファイルは保存されますけれど (see Auto Save)。

Gnus を中断するときは gnus-suspend-gnus-hook が呼び出されます。 Gnus を終了するときは gnus-exit-gnus-hook が呼び出され、さらに Gnus を終了するときの最後として gnus-after-exiting-gnus-hook が呼び出されます。

Note:

     ミス Lisa Cannifax は英語の授業中、後ろに座っている少年が彼女のプラスティックの椅子の背越しに、鉛筆で繰り返し線を描くのにつられて、足がしびれて重くなり、意識が朦朧としてきました。

Group Topics
============

もしあなたがたーくさんのグループを読んでいるのであれば、グループをトピック毎に階層分けできると便利でしょう。Emacs のグループをこっちへ、セックスのグループをあっちへ、で、残りを (え? グループが二つくらいしかないの?) 邪魔にならないようにその他のセクションに入れましょう。あるいは Emacs セックスのグループを Emacs グループ、セックスグループのどちらかの副トピックとすることさえもできます---あるいは両方に! すんごいでしょう!

これが例です:

     Gnus
       Emacs -- こいつはすげーぜ!
          3: comp.emacs
          2: alt.religion.emacs
         えっちな Emacs
          452: alt.sex.emacs
            0: comp.talk.emacs.recovery
       その他
          8: comp.binaries.fractals
         13: comp.sources.unix

この 素晴らしい 機能を使うには、gnus-topic マイナーモードを (何と!) 単にスイッチオンするだけ---グループバッファーで、t を押して下さい (これはトグルコマンドです)。

さあやってみよう。とにかく試してみて。君が戻ってくるまで、僕はここで待ってるからさ。ララ、タララン...、いい曲だね、これ...ラ、ラ、ラ...え? 戻ってきた? よし、じゃ次は l を押してみて。ほら。これですべてのグループが misc の下に表示されました。興奮してクラクラしてこない? アツくって、いまいましいくらいでしょ?

これをずっと有効にしたければ、グループモードのフックにこのマイナーモードを追加して下さい。以下の行を ~/.gnus.el ファイルに入れて、ね。

     (add-hook 'gnus-group-mode-hook 'gnus-topic-mode)

トピック命令
------

トピックマイナーモードが有効であるときは、T サブマップが新しく利用できるようになります。さらに標準キーの中でも、定義がちょっと変わるものが少しあります。

だいたいにおいて、次のようなトピックの操作が可能です。まず第一に、あなたはトピックを作ることを望むでしょう。第二に、あなたはグループをトピックに入れて、それらをあなたの好みの順序になるまで、あちこちに移動することを望むでしょう。第三に行なう操作は、それらの一切合切を表示したり隠すことでしょう。他のグループの概要を見やすくするために、あなたは副トピックやグループによっては、トピックが隠れるようにする必要があるかもしれませんね。

ここには、あなたの好むやり方でトピックを設定するために必要になりそうな、基本的なキーのリストがあります。

T n
     新しいトピック名の入力を促し、それを作成します (gnus-topic-create-topic)。

T TAB
TAB
     現在のトピックの ``字下げ'' を行ない、その前のトピックの副トピックにします (gnus-topic-indent)。接頭引数を与えると、反対にそのトピックの字下げを回復 (un-indent) します。

M-TAB
     現在のトピックの ``字下げ回復'' (un-indent) を行ない、それが現在の親の親の副トピックになるようにします (gnus-topic-unindent)。

以下の二つのキーは、グループとトピックをあちこち移動するために使われます。それらは、よく知られているカット＆ペーストのように動作します。 C-k はカット、C-y はペーストです。もちろん、Emacs ではカット＆ペーストではなくて kill & yank という用語を使いますが。

C-k
     グループあるいはトピックを kill します (gnus-topic-kill-group)。トピック内にあったグループもすべて、トピックと一緒に削除されます。

C-y
     直前の kill されたグループあるいはトピックを yank します (gnus-topic-yank-group)。すべてのトピックは、すべてのグループの前に yank されることに気を付けて下さい。

     ですから、あるトピックをトピックのリストの先頭に移動するには、単にそこで C-k を叩きます。これはカット＆ペーストのカットに相当します。そうしたらカーソルをバッファーの先頭 (``Gnus'' トピックの真下) に移動して、 C-y を叩いて下さい。これはカット＆ペーストのペーストに相当します。なあんだ、簡単じゃん。

     C-k と C-y はトピックと同様にグループにも使えます。すなわち、あなたはグループと同じようにトピックの移動もできるのです。

あなたの望みのままにトピックを使えるようにした後で、あなたはトピックを隠したり再び見えるようにしようと思うでしょう。そのために以下のキーを用意しています。

RET
SPACE
     グループを選択するか、あるいはトピックを折りたたみます (gnus-topic-select-group)。グループの上でこのコマンドを実行すると、通常通りそのグループに入ります。トピック行の上で行なうと、そのトピックは (すでに表示されているときは) 折りたたまれるか、(すでに折りたたまれているときは) 展開されます。つまりトピックに対してはこれはトグルコマンドです。さらに、数値の接頭引数を与えると、そのレベル (とそれよりも小さいレベル) のグループが表示されます。

さてお次は、他のコマンドのリストです。順序には特に意味はありません。

T m
     現在のグループを、どこか他のトピックに移動させます (gnus-topic-move-group)。このコマンドはプロセス印/接頭引数の習慣に従います (see Process/Prefix)。

T j
     トピックにジャンプします (gnus-topic-jump-to-topic)。

T c
     現在のグループを、どこか他のトピックにコピーします (gnus-topic-copy-group)。このコマンドはプロセス印/接頭引数の習慣に従います (see Process/Prefix)。

T h
     現在のトピックを隠します。接頭引数が与えらると、そのトピックを永久に隠します。

T s
     現在のトピックを表示します。接頭引数が与えられると、そのトピックを永久に表示します。

T D
     グループを現在のトピックから削除します (gnus-topic-remove-group)。この命令は主にいくつかのトピックに同じグループがあって、それをトピックの一つから取り除きたいときに役立ちます。あなたはグループをすべてのトピックから取り除くかもしれませんが、その場合は、Gnus はあなたが次回に Gnus を起動したときにそれをルートトピックに付け加えます。実際のところ、すべての新しいグループ (もちろん、それはどのトピックにも属していません) はルートトピックに現われます。

     この命令はプロセス印/接頭引数の習慣に従います (see Process/Prefix)。

T M
     正規表現に合致するすべてのグループを、あるトピックに移動させます (gnus-topic-move-matching)。

T C
     正規表現に合致するすべてのグループを、あるトピックにコピーします (gnus-topic-copy-matching)。

T H
     空のトピックの表示・非表示を切り替えます (gnus-topic-toggle-display-empty-topics)。

T #
     現在のトピックにあるグループすべてにプロセス印を付けます (gnus-topic-mark-topic)。接頭引数が与えられない場合、このコマンドは副トピックに対して再帰的に働きます。

T M-#
     現在のトピックにあるすべてのグループからプロセス印を消します (gnus-topic-unmark-topic)。接頭引数が与えられない場合、このコマンドは副トピックに対して再帰的に働きます。

C-c C-x
     (もしあれば) 現在のグループかトピックかのすべての期限切れ消去可能記事を期限切れ消去します (gnus-topic-expire-articles)。(see Expiring Mail)。

T r
     トピックの名前を変更します (gnus-topic-rename)。

T DEL
     空のトピックを削除します (gnus-topic-delete)。

A T
     Gnus が知っているトピック化されたグループをすべて表示します (gnus-topic-list-active)。

T M-n
     次のトピックに移動します (gnus-topic-goto-next-topic)。

T M-p
     前のトピックに移動します (gnus-topic-goto-previous-topic)。

G p
     トピックパラメーターを修正します (gnus-topic-edit-parameters)。 See Topic Parameters.

トピック変数
------

前の項では、どのトピックを表示するかを Gnus に言う方法を説明しました。この項では、それぞれのトピックの何を表示するかを Gnus に言う方法を説明します。

トピック行それ自体は、gnus-topic-line-format 変数の値に従って作成されます (see Formatting Variables)。有効な要素は、

i
     字下げ。

n
     トピック名。

v
     見えるかどうか。

l
     レベル。

g
     トピック中のグループの数。

a
     トピック中の未読記事の数。

A
     トピックとすべての副トピックの未読記事の数。

各副トピック (と副トピック内のグループ) は、トピックレベル数の gnus-topic-indent-level 倍の空白分の字下げが行なわれます。ディフォルト値は 2 です。

gnus-topic-mode-hook はトピックマイナーモードバッファーで呼び出されます。

gnus-topic-display-empty-topics はトピックの中に未読記事が無い場合でもそのトピックを表示するようにします。ディフォルト値は t です。

トピックの並べ替え
---------

以下に示す命令で、各トピック毎に別々にグループを並べ替えることができます:

T S a
     現在のトピックをグループ名のアルファベット順に並べ替えます (gnus-topic-sort-groups-by-alphabet)。

T S u
     現在のトピックを未読記事の数で並べ替えます (gnus-topic-sort-groups-by-unread)。

T S l
     現在のトピックをグループのレベルで並べ替えます (gnus-topic-sort-groups-by-level)。

T S v
     現在のトピックをグループのスコアで並べ替えます (gnus-topic-sort-groups-by-score)。See Group Score.

T S r
     現在のトピックをグループのランクで並べ替えます (gnus-topic-sort-groups-by-rank)。See Group Score.

T S m
     現在のトピックをバックエンドの名前でアルファベット順に並べ替えます (gnus-topic-sort-groups-by-method)。

T S e
     現在のトピックをサーバーの名前でアルファベット順に並べ替えます (gnus-topic-sort-groups-by-server)。

T S s
     現在のトピックを、変数 gnus-group-sort-function で与えられる関数に従って並べ替えます (gnus-topic-sort-groups)。

接頭引数が与えられると、これらすべてのコマンドは逆順の並べ替えを行ないます。グループの並べ替えについてのさらなる情報は Sorting Groups を参照して下さい。

トピックの位相構造
---------

それでは、グループバッファーの例を見ていきましょう。

     Gnus
       Emacs -- こいつはすげーぜ!
          3: comp.emacs
          2: alt.religion.emacs
         えっちな Emacs
          452: alt.sex.emacs
            0: comp.talk.emacs.recovery
       その他
          8: comp.binaries.fractals
         13: comp.sources.unix

つまり、ここでは一つのトップレベルのトピック (Gnus) があり、その下に二つのトピックがあり、そのうちの一方の副トピック中に一つ副トピックがあります (トップレベルトピックは常に一つしかありません)。この構造は、以下のように表現できます:

     (("Gnus" visible)
      (("Emacs -- こいつはすげーぜ!" visible)
       (("えっちな Emacs" visible)))
      (("その他" visible)))

これは実に、上記の表示を行なうための、変数 gnus-topic-topology の値そのものなのです。この変数は .newsrc.eld ファイルに保存され、手でいじくり回してはいけません---本当にやりたいときは別ですが。この変数は .newsrc.eld ファイルから読み込まれるので、その他のスタートアップファイルの設定にはまったく影響を与えません。

この構造は、どのトピックがどのトピックの副トピックであるかと、どのトピックが表示されているかを示しています。現在は二つの設定値---visible と invisible が許されています。

トピックパラメーター
----------

トピック内のすべてのグループはグループパラメーターを、その親 (と先祖) のトピックパラメーターから継承します。グループパラメーターとして正しいものはすべて、トピックパラメーターとしても正しいものです (see Group Parameters)。エージェントを使うようにしてあると、すべてのエージェントパラメーター (Category Syntax の Agent Parameters を参照 (訳注: 必要なら Index を使って)) は有効なトピックパラメーターでもあります。

さらに、以下のパラメーターはトピックパラメーターとしてのみ有効です:

subscribe
     トピックで新しいグループを購読している場合 (see Subscription Methods)、subscribe トピックパラメーターはどのグループがどのトピックに行くかを指定します。値はそのトピックに行くグループに合致する正規表現である必要があります。

subscribe-level
     トピックで新しいグループを購読している場合 (subscribe パラメーターを参照)、そのグループの購読度のレベルは gnus-level-default-subscribed の代わりに subscribe-level トピックパラメーターの値になります。

グループパラメーターは (もちろん) トピックパラメーターよりも優先され、副トピックのトピックパラメーターは親トピックのトピックパラメーターよりも優先されます。分かるよね。ごく普通の継承ルールです (ルール (Rules) はここでは名詞であって、動詞の「線を引く」ではありません。このルールには反対したくなるかもしれないけど、それはご自由に)。

     Gnus
       Emacs
          3: comp.emacs
          2: alt.religion.emacs
        452: alt.sex.emacs
         息抜き
          452: alt.sex.emacs
            0: comp.talk.emacs.recovery
       その他
          8: comp.binaries.fractals
         13: comp.sources.unix
        452: alt.sex.emacs

Emacs トピックはトピックパラメーター (score-file . "emacs.SCORE") を持っています。息抜き トピックはトピックパラメーター (score-file . "relief.SCORE") を持ち、その他 トピックはトピックパラメーター (score-file . "emacs.SCORE") を持っています。さらに、alt.religion.emacs はグループパラメーター (score-file . "religion.SCORE") を持っています。

さて、ここで 息抜き トピックの alt.sex.emacs グループに入ったとき、relief.SCORE が基本スコアファイルとなります。もし Emacs トピックの同じグループに入ると、emacs.SCORE が基本スコアファイルになるでしょう。 alt.religion.emacs グループに入れば、religion.SCORE が基本スコアファイルになるでしょう。

これってとっても簡単で自明のことのように見えるでしょ? まあ、その通りです。ですが問題がある場合もあります。特に total-expiry パラメーターに関してです。例えばあるメールグループを二つのトピックの中に、一方は total-expiry ありで、もう一方はそれなしで持っているとしましょう。ここで M-x gnus-expire-all-expirable-groups を実行すると、何が起こるでしょうか? Gnus は、あなたがどちらのトピックから記事を期限切れ消去したいのかを知る方法がないため、最悪の事態が発生するかもしれません。実際、私はこのとき何が起こるのかは「未定義 undefined」である、とここに宣言します。この手のことをやりたい場合には十分注意しなければなりません。

その他のグループ関連
==========

^
     サーバーバッファーモードに入ります (gnus-group-enter-server-mode)。 See Server Buffer.

a
     メッセージ (ディフォルトはニュース) の作成を開始します (gnus-group-post-news)。接頭引数が与えられると、現在位置のグループに投稿します。もし接頭引数が 1 だったら、どのグループに投稿するかを尋ねます。この関数の名前から連想されることとは裏腹に、接頭引数でメールグループが指定された場合は、ニュースの代わりにメールの様式が用意されます。 See Composing Messages.

m
     メールをどこかに送ります (gnus-group-mail)。接頭引数が与えられると、現在位置のグループの投稿様式 (posting style) を使います。もし接頭引数が 1 だったら、どのグループの投稿様式を使うかを尋ねます。 See Composing Messages.

i
     ニュースの作成を開始します (gnus-group-news)。接頭引数が与えられると、現在位置のグループに投稿します。もし接頭引数が 1 だったら、どのグループに投稿するかを尋ねます。See Composing Messages.

     この関数は、たとえメールグループで使われたとしても、実際にはニュースの様式を用意します。これは、メッセージを実際にはネットワーク経由で送らずに、メールグループに ``投稿'' するのに便利です; それらは当のグループに単に直接保存されます。対応するバックエンドが投稿のためのメソッド (request-post method) を持っていなければなりませんが。

以下はグループバッファーのための変数です:

gnus-group-mode-hook
     グループバッファーが作成された時に呼び出されます。

gnus-group-prepare-hook
     グループバッファーが生成されたあとに呼び出されます。これはバッファーを何か変な、自然ではない方法で修正したいときに使われるかもしれません。

gnus-group-prepared-hook
     グループバッファーが生成された後の一番最後に呼び出されます。例えばポイントをどこかに移動させたいときなどに使えます。

gnus-permanently-visible-groups
     この正規表現に合致するグループは、それが空であるかどうかに関わらず、常にグループバッファーに表示されます。

gnus-group-name-charset-method-alist
     グループ名用の選択方法と文字セットの連想リストです。これは英字ではないグループ名を表示するために使います。

     例:

          (setq gnus-group-name-charset-method-alist
              '(((nntp "news.com.cn") . cn-gb-2312)))

gnus-group-name-charset-group-alist
     グループ名用のグループ名の正規表現と文字セットの連想リストです。これは英字ではないグループ名を表示するために使います。ディフォルト値は、UTF-8 がサポートされている場合は ((".*" utf-8))、それ以外の場合は nil です。

     例:

          (setq gnus-group-name-charset-group-alist
              '(("\\.com\\.cn:" . cn-gb-2312)))

新着メッセージを探す
----------

g
     サーバーの新着記事をチェックします。数値の接頭引数を使用すると、この命令は引数 ARG かそれより小さいレベルのグループのみをチェックします (gnus-group-get-new-news)。数値以外の接頭引数を与えると、この命令はそのバックエンドからアクティブファイルを強制的に全部読み直します。

M-g
     現在のグループに新着記事があるかどうかをチェックします (gnus-group-get-new-news-this-group)。 gnus-goto-next-group-when-activating はこの命令が次のグループ位置へ移動するかどうかを決めます。ディフォルト値は t です。

C-c M-g
     無条件にすべてのグループを起動します (gnus-activate-all-groups)。

R
     Gnus を再起動します (gnus-group-restart)。これは .newsrc ファイルをセーブし、すべてのサーバーの接続を閉じ、すべての Gnus ランタイム変数をクリアした後、Gnus をもう一度最初から開始します。

gnus-get-new-news-hook は新着ニュースをチェックする直前に実行されます。

gnus-after-getting-new-news-hook 新着ニュースをチェックした後に実行されます。

グループ情報
------

H f
     現在のグループの FAQ を取得しようとします (gnus-group-fetch-faq)。 Gnus は FAQ を gnus-group-faq-directory から取得しようとします。これは通常リモートマシン上のディレクトリーです。この変数はディレクトリーのリストであっても構いません。この場合、このコマンドに接頭引数を与えることでいくつかのサイトの中から選ぶことができます。ファイルの取得には ange-ftp (または efs) が使用されます。

     もし最初のサイトからの取得が失敗した場合、 Gnus は gnus-group-faq-directory の値をすべて、一つ一つオープンしてみようとします。

H c
     現在のグループの憲章を web ブラウザで開こうとします (gnus-group-fetch-charter)。接頭引数が与えられるとグループ名を尋ねます。

     Gnus は gnus-group-charter-alist を使って憲章の所在を探します。所在がわからなかったら、Gnus はそのグループのコントロールメッセージを取得します。それには憲章を含んでいることがありますから。

H C
     そのグループのコントロールメッセージを ftp.isc.org の記録庫から取得します (gnus-group-fetch-control)。接頭引数が与えられるとグループ名を尋ねます。

     gnus-group-fetch-control-use-browse-url が非-nil だったら、 Gnus は browse-url を使ってコントロールメッセージを開きます。そうでない場合は ange-ftp を使って取得され、一時グループに表示されます。

     コントロールメッセージは圧縮されていることに注意して下さい。このコマンドを使うには auto-compression-mode を on にしておく必要があります (see Compressed Files (The Emacs Editor))。

H d
C-c C-d
     現在のグループの説明を表示します (gnus-group-describe-group)。接頭引数を与えると、説明文をサーバーから強制的に再読み込みします。

M-d
     すべてのグループの説明を表示します (gnus-group-describe-all-groups)。接頭引数を与えると、説明文ファイルをサーバーから強制的に再読み込みします。

H v
V
     現在の Gnus のバージョン番号を表示します (gnus-version)。

?
     とても短いヘルプメッセージを与えます (gnus-group-describe-briefly)。

C-c C-i
     Gnus の info ノードに移動します (gnus-info-find-node)。

グループの日付
-------

Gnus に、あなたが最後にいつグループを読んだかを記録させると便利かもしれません。この活動を始めさせるには、 gnus-group-set-timestamp を gnus-select-group-hook に追加して下さい。

     (add-hook 'gnus-select-group-hook 'gnus-group-set-timestamp)

これを行なった後、あなたがグループに入るたびにそれが記録されます。

この情報はさまざまな方法で表示できます---もっとも簡単なのは、グループ行フォーマットで %d 指定を使う方法です:

     (setq gnus-group-line-format
           "%M\%S\%p\%P\%5y: %(%-40,40g%) %d\n")

この結果として、各行は以下のように表示されます:

     *        0: mail.ding                                19961002T012943
              0: custom                                   19961002T012713

見て分かるとおり、日付はコンパクトな ISO 8601 形式で表示されます。これではちょっとあんまりなので、以下のような感じにすると日付だけを表示できます。

     (setq gnus-group-line-format
           "%M\%S\%p\%P\%5y: %(%-40,40g%) %6,6~(cut 2)d\n")

もっと凝った日付の形式をお望みなら、利用者定義によるフォーマットの仕様を使うことができます。以下のようなものはうまくいくでしょう:

     (setq gnus-group-line-format
           "%M\%S\%p\%P\%5y: %(%-40,40g%) %ud\n")
     (defun gnus-user-format-function-d (headers)
       (let ((time (gnus-group-timestamp gnus-tmp-group)))
         (if time
             (format-time-string "%b %d  %H:%M" time)
           "")))

ファイル命令
------

r
     初期化ファイルの再読み込みを行ないます (gnus-init-file、ディフォルトは ~/.gnus.el) (gnus-group-read-init-file)。

s
     .newsrc.eld ファイル (と、もしそうしたければ .newsrc ファイル) をセーブします (gnus-group-save-newsrc)。

Sieve コマンド
----------

Sieve はサーバー側で使われるメールフィルター言語です。Gnus では、各グループに適用される sieve の規則を指定する、sieve グループパラメーター (see Group Parameters) を使うことができます。guns はそれらすべてのグループパラメーターを、サーバーで使うことも可能な正しい Sieve スクリプトに翻訳する、二つのコマンドを提供します。

作成された Sieve スクリプトは gnus-sieve-file (ディフォルトは ~/.sieve) に置かれます。Gnus が作るコードは二つの区切り記号 gnus-sieve-region-start と gnus-sieve-region-end の間に置かれるので、これらの区切り記号の外に追加の Sieve コードを書いても、次回 Sieve スクリプトを再作成するときに消されてしまうことはありません。

変数 gnus-sieve-crosspost は Sieve スクリプトがどのように作られるかを制御します。もし非-nil (ディフォルト) だったら記事は規則に合致するすべてのグループに置かれます。そうでない場合、記事は最初の規則に合致するグループだけに置かれます。例えばグループパラメーター (sieve address "sender" "owner-ding@hpc.uh.edu") は、 gnus-sieve-crosspost が nil だったら以下の Sieve コードの断片を作ります。(gnus-sieve-crosspost が非-nil だった場合は、行が含む stop の呼び出しが削除されること以外は同じです。)

     if address "sender" "owner-ding@hpc.uh.edu" {
             fileinto "INBOX.ding";
             stop;
     }

See Emacs Sieve.

D g
     sieve グループパラメーターから Sieve スクリプトを再作成して、 gnus-sieve-file に書き込みます。以前の内容は保存されません。

D u
     sieve グループパラメーターを元に gnus-sieve-file の Gnus が管理している部分を再作成してファイルにセーブし、sieveshell プログラムを使ってサーバーにアップロードします。

概略バッファー
*******

概略バッファー (summary buffer) ではそれぞれの記事が一行で表示されます。その中を動き回り、記事を読み、投稿し、返答をすることができます。

概略バッファーに移る一番普通の方法は、グループバッファーでグループを選択することです (see Selecting a Group)。

好きなだけたくさんの概略バッファーを開いておくことができます。

概略バッファーの様式
==========

Gnus は変数 gnus-extract-address-components の値を From ヘッダーの名前とアドレスの部分を抽出するための関数として使います。すでに定義されている関数が二つ存在します: ディフォルトは gnus-extract-address-components で、とても簡単に割り切った解決法ですが非常に速く動作します。mail-extract-address-components は良く動作しますが遅いです。ディフォルトの関数は 5% の割合で間違った答を返します。もしこれに我慢ならないのであれば、代わりに他の関数を使って下さい:

     (setq gnus-extract-address-components
           'mail-extract-address-components)

gnus-summary-same-subject は今読んでいる記事が、その前の記事と同じ表題 (subject) であることを示す文字列です。この文字列は、それを要求する書法仕様で使われます。ディフォルトでは "" です。

概略バッファーの行
---------

変数 gnus-summary-line-format の値を変えることによって、概略バッファーの行の様式 (format) を変更することができます。いくつかの拡張 (see Formatting Variables) とともに、普通の format 文字列と同じように動作します。

行には常にコロンかポイント位置のマーカーが存在していなければなりません。操作した後に、カーソルはいつもコロンかポイント位置のマーカーの場所に移動します。(もちろん、この動作を変えることができないとしたら Gnus にはあるまじきことです。関数 gnus-goto-colon を、あなたが好きなカーソルの動きになるように、新たに書けば良いのです。) see Positioning Point.

ディフォルト値の文字列は %U%R%z%I%(%[%4L: %-23,23f%]%) %s\n です。

以下の様式指示文字と拡張様式指示を使うことができます:

N
     記事数。

S
     表題の文字列。gnus-list-identifiers の設定によってメーリングリストの標識が削除されます。See Article Hiding.

s
     スレッド (thread) の元記事であるときか直前の記事が違う表題のときはその表題で、それ以外は gnus-summary-same-subject。 (gnus-summary-same-subject のディフォルト値は ""。)

F
     完全な From 欄。

n
     名前 (From 欄より)。

f
     名前、To 欄の内容、または Newsgroups 欄の内容のどれかです (see To From Newsgroups)。

a
     名前 (From 欄より)。これと n との違いは、これは変数 gnus-extract-address-components で指定されている関数を使って名前を取得することです。この方が遅いですが、おそらくより完全に近いでしょう。

A
     名前 (From 欄より)。これは a と同じように動作します。

L
     記事の行数。

c
     記事の文字数。この名前指定子は (nnfolder のような) いくつかの選択方法をサポートしません。

k
     整形された記事の文字数; 例えば 1.2k や 0.4M。

I
     スレッドのレベルによる字下げ (see Customizing Threading)。

B
     複雑な trn 様式のスレッド木 (tree)。どのような応答が行なわれたかの記録を表示します。スレッドはこのように描かれるでしょう:

          >
          +->
          | +->
          | | \->
          | |   \->
          | \->
          +->
          \->

     以下のオプションで見栄えをカスタマイズすることができます。ディフォルトの ASCII 文字を線描画用の図案で置き換えることによって、スレッド表示を実に巧妙に見せることができることに気付いて下さい。

     gnus-sum-thread-tree-root
          スレッドの根 (root) に使われます。nil だったら、代わりに表題を使います。ディフォルトは >  です。

     gnus-sum-thread-tree-false-root
          スレッドのにせの根に使われます (see Loose Threads)。nil だったら、代わりに表題を使います。ディフォルトは >  です。

     gnus-sum-thread-tree-single-indent
          単一のメッセージのスレッドに使われます。nil だったら、代わりに表題を使います。ディフォルトは です。

     gnus-sum-thread-tree-vertical
          縦線の描画に使われます。ディフォルトは |  です。

     gnus-sum-thread-tree-indent
          行下げ (indenting) に使われます。ディフォルトは    です。

     gnus-sum-thread-tree-leaf-with-other
          兄弟がいる葉っぱに使われます。ディフォルトは +->  です。

     gnus-sum-thread-tree-single-leaf
          兄弟がいない葉っぱに使われます。ディフォルトは \->  です。

T
     記事が元記事であれば何も表示せず、そうでない場合はたくさんの空白です (それより後のものをすべて画面の外に追い出してしまいます)。

[
     開き括弧。普通は [ ですが、養子記事には < にすることができます (see Customizing Threading)。

]
     閉じ括弧。普通は [ ですが、養子記事には < にすることができます。

>
     それぞれのスレッドのレベルに対して一つの空白。

<
     (20 - スレッドレベル) 個の空白。

U
     未読。See Read Articles.

R
     この紛らわしい名前指定子は 第二の印 (the secondary mark) です。この印は記事がすでに返答済みのものか、キャッシュされたものか、あるいは保存されたものかを表します。See Other Marks.

i
     数値としてのスコア (see Scoring)。

z
     これは、zcore でディフォルトのレベルよりも上であれば + で、ディフォルトのレベルよりも下であれば - です。 gnus-summary-default-score との差が gnus-summary-zcore-fuzz よりも小さいと、この仕様は使われません。

V
     スレッド全体のスコア。

x
     Xref.

D
     Date.

d
     DD-MM 様式による Date。

o
     YYYYMMDDTHHMMSS 様式による Date。

M
     Message-ID.

r
     References.

t
     現在の副スレッドの記事の数。この仕様を使うと概略バッファーの生成が幾分遅くなります。

e
     記事に子記事があると、= (gnus-not-empty-thread-mark) が表示されます。

P
     行数。

O
     ダウンロードの印。

&user-date;
     経過時間の様式。いろいろな様式が gnus-user-date-format-alist で定義されています。

u
     利用者定義指定子。フォーマット文字列の中の次の文字は英字でなければなりません。これにより Gnus は関数 gnus-user-format-function-X を呼び出しますが、ここで X は %u の次の文字です。関数には現在の記事のヘッダーが引数として渡されます。関数は文字列を返さなければなりません。それは他の概略指定と同様に概略に挿入されます。

%( と %) の間にあるテキストは、そこにマウスがあるときに gnus-mouse-face でハイライトされます。そういう領域は一つだけです。

%U (状態), %R (返答済み), %z (zcore) の扱いには気を付ける必要があります。効率のために、Gnus はこれらの文字がどの桁に現れるかを計算し、『ハード・コード』します。これは、可変長の仕様の後では、これらは意味を持たないということです。まぁ、さすがに逮捕はされないでしょうが、概略バッファーは変になります。それでも十分悲しいでしょうけど。

賢い選択はこれらの指定をできるだけ左に持ってくることです。(でも、そういうことはすべてに当てはまるのではないでしょうか。閑話休題。)

この制限は将来の版では無くなるかもしれません。

To From Newsgroups
------------------

いくつかのグループ (特にアーカイブグループ) では From ヘッダーはあまり興味を引きません。そこのすべての記事はあなたによって書かれたものですから。代わりに、To や Newsgroups ヘッダーの情報を表示するためには、三つのことを決める必要があります: どの情報を集めるか, どこに表示するか, いつ表示するか。

 1. 追加のヘッダーの情報は gnus-extra-headers により制御されます。これはヘッダーのシンボルのリストです。例えば:

          (setq gnus-extra-headers
                '(To Newsgroups X-Newsreader))

     これによって Gnus はこれらの三つのヘッダーを取得しようとし、後の容易な取得のためにヘッダー構造に保存します。

 2. これらの追加のヘッダーの値は gnus-extra-function 関数を通じて取得することができます。これは X-Newsreader ヘッダーを使う書式行の仕様です:

          "%~(form (gnus-extra-header 'X-Newsreader))@"

 3. gnus-ignored-from-addresses 変数はいつ %f 概略行仕様が To, Newsreader や From ヘッダーを返せば良いかを決めます。この正規表現が From ヘッダーの内容と合致すると、 To や Newsreader ヘッダーの値が代わりに使用されます。

     それらの From フィールドが入れ替わっている記事と、普通の記事を区別するために、概略行の To または Newsgroups ヘッダーに、ある文字列が前置されます。その文字列はディフォルトで、To には ->  が、Newsgroups には =>  が使われますが、 gnus-summary-to-prefix と gnus-summary-newsgroup-prefix によって、それらの文字列をカスタマイズすることができます。

関連する変数は nnmail-extra-headers で、 overview (NOV) ファイルを作る際にいつ追加のヘッダーを含めるかを制御します。古い overview ファイルがある場合は、この変数を変更した後にサーバーバッファーに ^ で入って適切なメールサーバー (例えば nnml) で g を押し、再生成する必要があります。

さらに gnus-summary-line-format 変数の %n 仕様を %f 仕様に変更することによってデータを表示するように、Gnus に指示する必要があります。

要約すると、普通は以下のようなものを ~/.gnus.el に置くことになります:

     (setq gnus-extra-headers
           '(To Newsgroups))
     (setq nnmail-extra-headers gnus-extra-headers)
     (setq gnus-summary-line-format
           "%U%R%z%I%(%[%4L: %-23,23f%]%) %s\n")
     (setq gnus-ignored-from-addresses
           "Your Name Here")

(上記の値は Gnus のディフォルト値です。あなたの役に立つように変えて下さい。)

ニュース管理人、またはニュース管理人を説得してサポートの追加をしてもらおうと思っている利用者のみなさんへのご注意:

NOV ファイルの生成を制御できるメールグループでは、上記のことはたいていの場合役立ちます。しかし、管理人を説得して (特に INN の普通の実装において) 以下のものを overview.fmt ファイルの最後に追加してもうらうことができれば、メールグループでの追加ヘッダーのようにそれを使うことができます。

     Newsgroups:full

概略バッファーのモード行
------------

概略のモード行の様式も変更することができます (see Mode Line Formatting)。gnus-summary-mode-line-format を何でも好きなものに設定して下さい。ディフォルト値は Gnus: %%b [%A] %Z です。

以下はあなたが遊ぶことのできる要素たちです:

G
     グループ名。

p
     接頭語を取り除いた名前。

A
     現在の記事番号。

z
     現在の記事スコア。

V
     Gnus バージョン。

U
     そのグループでの未読記事の数。

e
     概略バッファーに表示されていない未読記事の数。

Z
     未読と未選択の記事の数とともに表される文字列で、未読かつ未選択の記事がある場合の <%U(+%e) more>、および未読記事のみの場合の <%U more> のどちらかです。

g
     短縮グループ名。例えば、rec.arts.anime は r.a.anime に短縮されます。

S
     現在の記事の表題。

u
     利用者定義の仕様 (see User-Defined Specs)。

s
     現在のスコアファイルの名前 (see Scoring)。

d
     保留記事の数 (see Unread Articles)。

t
     可視印付き記事の数 (see Unread Articles)。

r
     その概略バッファーで記事を読んだ結果、既読の印が付いた記事の数。

E
     スコアファイルによって抹消された記事の数。

概略のハイライト
--------

gnus-visual-mark-article-hook
     このフックは記事を選択した後に実行されます。これは何らかの方法で記事をハイライトするように意図されています。gnus-visual が nil だったら実行されません。

gnus-summary-update-hook
     このフックは概略行が変化したときに呼ばれます。 gnus-visual が nil だったら実行されません。

gnus-summary-selected-face
     これは概略バッファーでの現在の記事をハイライトするために使われるフェース (もしくは、ある人たちが フォント と呼ぶようなもの) です。

gnus-summary-highlight
     概略行はこの変数にしたがってハイライトされます。この変数は要素が (FORM . FACE) の形式のリストです。例えば、印付きの記事を斜体、高いスコアの記事を太字にしたければ、この変数を次のように設定することができます。

          (((eq mark gnus-ticked-mark) . italic)
           ((> score default) . bold))

     ご想像のとおり、FORM が nil でない値を返すと、FACE がその行に適用されます。

概略間の移動
======

すべての直接移動命令は数値接頭引数を受け付け、かなり期待どおりに動作するでしょう。

これらの命令はどれも記事を選択しません。

G M-n

M-n
     概略行の次の未読記事に移ります (gnus-summary-next-unread-subject)。

G M-p
M-p
     概略行の前の未読記事に移ります (gnus-summary-prev-unread-subject)。

G g
     記事番号を尋ね、その記事を表示せずに、その概略行に行きます (gnus-summary-goto-subject)。

Gnus が次のグループ移動することを確認するためにキー入力を求めた場合、 C-n キーと C-p キーを使うことによって、実際にグループバッファーに戻らなくても、次に読むグループを探すことができます。

概略の移動に関連した変数:

gnus-auto-select-next
     移動命令の一つ (n のような) を発したときに現在の記事の後に未読記事が無いと、Gnus は次のグループに移動することをうながします。この変数が t で次のグループが空っぽだったら、Gnus は概略モードを抜けてグループバッファーに戻ります。この変数が t でも nil でもなければ、Gnus はさらに次の未読記事があるグループを選択します。特別な場合として、この変数が quietly だったら、Gnus は確認をせずに次のグループを選択します。この変数が almost-quietly だった場合は、グループの一番最後の記事を読んでいたときに限って同じことが起こります。最後に、もしこの変数が slightly-quietly だったら、Z n 命令は確認をせずに次のグループに移ります。Group Levels も参照して下さい。

gnus-auto-select-same
     nil でないと、すべての移動命令は現在の記事と同じ表題の記事に移動しようとします。(同じ はここでは 大体同じ という意味かもしれません。詳細は gnus-summary-gather-subject-limit を見て下さい (see Customizing Threading)。) 同じ表題の記事が無いときは、最初の未読記事に移動します。

     この変数は、スレッド表示を行なっているときはあまり役に立たないでしょう。

gnus-summary-check-current
     これが nil ではない場合、すべての『未読』移動命令は、現在の記事が未読だったら次 (もしくは前) の記事に移動しません。代わりに、それらは現在の記事を選びます。

gnus-auto-center-summary
     nil でないと、Gnus は概略バッファーでのポイントを常に真中に保ちます。これをすると、とてもこぎれいになりますが、遅いネットワークに接続していたり、この Emacs らしくない流儀が好きになれないのであれば、この変数を nil にすることによって、普通の Emacs のスクロールにすることができます。これは概略バッファーの水平方向でポイントが真ん中になるようにする操作 (horizontal re-centering) も禁止してしまうので、非常に長いスレッドを読むときは不便かもしれません。

     この変数は数値でも構いません。その場合は、ウィンドウの先頭からその数の行だけ下がった位置に常にポイントがあるように制御されます。

記事の選択
=====

選択命令
----

以下の移動コマンドはどれも数値接頭引数を受け付けません。それらはすべて、記事を選択して表示します。

新しい記事を取り込んだり、グループを再表示したいときは Exiting the Summary Buffer を参照して下さい。

SPACE
     現在の記事、またはそれが既読だった場合は次の未読記事を選択します (gnus-summary-next-page)。

     すでに記事ウィンドウを開いているときに再び SPACE を押すと、その記事はスクロールされます。これによって、ニュースグループ全体を SPACE だけで便利に通読することができます。 See Paging the Article.

G n
n
     次の未読記事に移動します (gnus-summary-next-unread-article)。

G p
p
     前の未読記事に移動します (gnus-summary-prev-unread-article)。

G N
N
     次の記事に移動します (gnus-summary-next-article)。

G P
P
     前の記事に移動します (gnus-summary-prev-article)。

G C-n
     同じ表題の次の記事に移動します (gnus-summary-next-same-subject)。

G C-p
     同じ表題の前の記事に移動します (gnus-summary-prev-same-subject)。

G f
.
     最初の未読記事に移動します (gnus-summary-first-unread-article)。

G b

,
     最高スコアの未読記事に移動します (gnus-summary-best-unread-article)。接頭引数が与えられると、ディフォルトのスコアより大きいスコアを持つ最初の未読記事に移動します。

G l
l
     直前に読んだ記事に移動します (gnus-summary-goto-last-article)。

G o
     概略の履歴 (history) から最後の記事を一つ取り出して選択します (gnus-summary-pop-article)。この命令が上の命令と違うのは、 l が最後の二つの記事の間を移動するだけなのに対して、これは好きなだけ前の記事を履歴から選び出すことができる点です。これに多少関係することについて、Article Backlog を参照して下さい (これらの命令をたくさん使うのであれば)。

G j

j
     記事番号か Message-ID を尋ね、それからその記事に行きます (gnus-summary-goto-article)。

選ぶための変数
-------

記事の移動と選択に関連するいくつかの変数:

gnus-auto-extended-newsgroup
     この変数が nil でないと、すべての移動命令は、記事が概略バッファーに表示されていない場合でも、前 (もしくは次) の記事に移動しようとします。その際 Gnus はサーバーから記事を取得して、記事バッファーに表示します。

gnus-select-article-hook
     このフックは記事が選択されたときに常に呼ばれます。ディフォルト値は nil です。講読するそれぞれの記事をエージェントに保存させたい場合は、このフックに gnus-agent-fetch-selected-article を追加すれば良いでしょう。

gnus-mark-article-hook
     このフックは記事が選択されたときに常に呼ばれます。これは記事に既読の印を付けるために使われることを意図しています。ディフォルト値は gnus-summary-mark-read-and-unread-as-read で、ほとんどすべての読んだ記事の印を gnus-read-mark に変更します。この関数に影響されない記事は、可視、保留、期限切れ消去可能記事だけです。未読記事に既読の印を付けたいだけであれば、代わりに gnus-summary-mark-unread-as-read を使うことができます。 gnus-low-score-mark や gnus-del-mark (など) の印はそのまま残します。

記事のスクロール
========

SPACE
     SPACE を押すと、現在の記事を一ページ先にスクロールします。記事の最後に行き着いた場合は次の記事を選択します (gnus-summary-next-page)。

     gnus-article-skip-boring が非-nil で、かつ記事の残りに引用と署名しか無い場合、それはスキップされ、代わりに次の記事が表示されます。 gnus-article-boring-faces で、つまらないと思うものをカスタマイズすることができます。どんなにうんざりするものでも、C-M-v を使うことによって、手動で記事のページを見ることはできます。

DEL
     現在の記事を一ページ前にスクロールします (gnus-summary-prev-page)。

RET
     現在の記事を一行先にスクロールします (gnus-summary-scroll-up)。

M-RET
     現在の記事を一行後ろへスクロールします (gnus-summary-scroll-down)。

A g
g
     現在の記事を (再) 取得します。もし接頭引数が与えられると、現在の記事を取得しますが、記事をトリートメントする関数は実行しません。これは、サーバーから来たままの『生の』記事をもたらします。

     接頭引数を与えると、手動で文字セットの操作を行なうことができます。 C-u 0 g cn-gb-2312 RET により、メッセージはあたかも cn-gb-2312 文字セットでエンコードされたかのようにデコードされます。以下のような設定を用意しておくと、C-u 1 g で同じ効果を得ることができます。

          (setq gnus-summary-show-article-charset-alist
                '((1 . cn-gb-2312)
                  (2 . big5)))

A <
<
     記事の最初までスクロールします。 (gnus-summary-beginning-of-article)。

A >
>
     記事の最後までスクロールします (gnus-summary-end-of-article)。

A s
s
     記事バッファーでインクリメンタルサーチ (isearch) を行ないます (gnus-summary-isearch-article)。

h
     記事バッファーを選択します (gnus-summary-select-article-buffer)。

返答、フォローアップ、投稿
=============

概略でのメールの命令
----------

メールメッセージを作成するための命令:

S r

r
     現在の記事を書いた人に返答のメールを送ります (gnus-summary-reply)。

S R
R
     現在の記事を書いた人に、元記事を含んだ返答のメールを出します (gnus-summary-reply-with-original)。この命令はプロセス/接頭引数の習慣を使います。

S w
     現在の記事を書いた人に対して、広い返答 (wide reply) をします (gnus-summary-wide-reply)。広い返答 とはヘッダーの To, From, (もしくは Reply-to) と Cc) のすべての人に返答をすることです。Mail-Followup-To があれば、代わりにそれが使われます。

S W
     現在の記事に元記事を含んだ広い返答のメールを送ります (gnus-summary-wide-reply-with-original)。この命令はプロセス/接頭引数の習慣を使います。

S v
     現在の記事を書いた人に対して、非常に広い返答 (very wide reply) をします (gnus-summary-very-wide-reply)。非常に広い返答 とは、プロセス/接頭引数で指定されたすべての記事のヘッダーの To, From, (もしくは Reply-to) と Cc) のすべての人に返答をすることです。この命令はプロセス/接頭引数の習慣を使います。

S V
     現在の記事に元記事を含んだ非常に広い返答のメールを送ります (gnus-summary-very-wide-reply-with-original)。この命令はプロセス/接頭引数の習慣を使います。

S B r
     現在の記事を書いた人に対して返答をしますが Reply-To フィールドは無視します (gnus-summary-reply-broken-reply-to)。メーリングリストがそのリストを指す Reply-To を過って設定するためにこれが必要なのであれば、おそらくあなたは代わりに broken-reply-to グループパラメーターを設定する必要があります。そうすれば、ものごとは正しく働くようになるでしょう。See Group Parameters.

S B R
     現在の記事を書いた人に対して元記事を含んだ返答をしますが Reply-To フィールドは無視します (gnus-summary-reply-broken-reply-to-with-original)。

S o m
C-c C-f
     誰か他の人に現在の記事を転送します (gnus-summary-mail-forward)。接頭引数が与えられない場合、メッセージは message-forward-as-mime および message-forward-show-mml の値に従ったやり方で転送されます。接頭引数が 1 だったら、デコードされたメッセージが直接埋め込まれた転送用のバッファーが作られます。2 だったら rfc822 形式の MIME パートが挿入されます。この場合、元のメッセージはデコードされません。3 ではデコードされた rfc822 形式の MIME パートが挿入されます (実際に送信する際に再びエンコードされます)。接頭引数 4 では、1 の場合と同じ動作になります。接頭引数がこれら以外の場合には、message-forward-as-mime の値を一時的に反転して、接頭引数が与えられなかった場合と同じ動作を行ないます。ディフォルトでは、デコードされたメッセージが rfc822 形式の MIME パートとして生成されます。

S m
m
     メールを作成します (gnus-summary-mail-other-window)。ディフォルトでは現在のグループの投稿様式 (posting style) を使います。接頭引数が与えられると、それは使いません。もし接頭引数が 1 だったら、どのグループの投稿様式を使うかを尋ねます。

S i
i
     ニュースを作成します (gnus-summary-news-other-window)。ディフォルトでは現在のグループに投稿します。接頭引数が与えられると、現在のグループ名は使われません。もし接頭引数が 1 だったら、どのグループに投稿するかを尋ねます。

     この関数は、たとえメールグループで使われたとしても、実際にはニュースの様式を用意します。これは、メッセージを実際にはネットワーク経由で送らずに、メールグループに ``投稿'' するのに便利です; それらは当のグループに単に直接セーブされます。対応するバックエンドが投稿のためのメソッド (request-post method) を持っていなければなりませんが。

S D b
     メールを送ったのに、何らかの理由 (アドレスの間違い、転送の不調) で戻ってきたときに、この命令を使って戻ってきたメールをもう一回送ることができます (gnus-summary-resend-bonced-mail)。メールバッファーにそのメールが現れて、そこでもう一度メールを送る前にヘッダーを編集することができます。この命令に接頭引数を与えると、戻ってきたメールが何か他のメールへの返答であった場合に、Gnus はそのメールを取得して、それのヘッダーの精密調査ができるように画面に表示しようとします。ま、これはとてもよく失敗しますけど。

S D r
     上の命令と混同しないで下さい。gnus-summary-resend-message は現在のメッセージを送る宛先のアドレスの入力を促して、その場所にメールを送ります。メッセージのヘッダーは変更されません---しかし Resent-To, Resent-From などの、たくさんのヘッダーが付け加えます。これは、(おそらく) あなた自身を To 欄に書いた本人にもメールを送ってしまうということです。これは混乱を招くでしょう。ですから当然、あなたが本当に邪悪な人でなければ、これは使わないでしょう。

     この命令は主に、あなたがいくつかのメールアカウントを持っていて、自分自身の違ったアカウントにメールを転送したいときに用いられます。(もしあなたが root であり、postmaster でもあり、root 宛てに postmaster へのメールを受け取った場合は、それを postmaster にも再送する必要があるかもしれません。秩序がなければなりません! (Ordnung muss sein!))

     この命令はプロセス/接頭引数の習慣に従います (see Process/Prefix)。

S D e
     一つ前のコマンドに似ていますが、再送する前にあたかも新しいメッセージのように編集することができます。

S O m
     現在の一連の記事 (see Decoding Articles) の要約を作り、メールでその結果を送ります (gnus-summary-digest-mail-forward)。この命令はプロセス/接頭引数の習慣に従います (see Process/Prefix)。

S M-c
     現在の記事の書き手に、過剰なクロスポストへの苦情のメールを送ります (gnus-summary-mail-crosspost-complaint)。

     この命令は、現在 Usenet に横行しているクロスポストの世界的流行に対して反撃を行なう手段として提供されています。これは変数 gnus-crosspost-complaint を序文にして返答を作成します。この命令はプロセス/接頭引数の習慣 (see Process/Prefix) に従い、それぞれのメールを送る前に送信するかどうかの確認をします。

また see ヘッダー命令 (The Message Manual), にさらなる情報があります。

概略の投稿命令
-------

ニュースの記事を投稿するための命令:

S p
a
     投稿するための記事を作成します (gnus-summary-post-news)。ディフォルトでは現在のグループに投稿します。接頭引数が与えられると、現在のグループ名は使われません。もし接頭引数が 1 だったら、代わりに別のどのグループに投稿するかを尋ねます。

S f
f
     現在の記事のフォローアップを投稿します (gnus-summary-followup)。

S F
F
     元記事を取り込んで、現在の記事にフォローアップをします (gnus-summary-followup-with-original)。この命令はプロセス/接頭引数の習慣を用います。

S n
     メールのメッセージを受け取っていたとしても、現在の記事のフォローアップをニュースに投稿します (gnus-summary-followup-to-mail)。この命令はプロセス/接頭引数の習慣を用います。

S N
     メールのメッセージを受け取っていたとしても、元記事を引用して、現在の記事のフォローアップをニュースに投稿します (gnus-summary-followup-to-mail-with-original). この命令はプロセス/接頭引数の習慣を用います。

S o p
     現在の記事をニュースグループに転送します (gnus-summary-post-forward)。接頭引数が与えられない場合、メッセージは message-forward-as-mime および message-forward-show-mml の値に従ったやり方で転送されます。接頭引数が 1 だったら、デコードされたメッセージが直接埋め込まれた転送用のバッファーが作られます。2 だったら rfc822 形式の MIME パートが挿入されます。この場合、元のメッセージはデコードされません。3 ではデコードされた rfc822 形式の MIME パートが挿入されます (実際に送信する際に再びエンコードされます)。接頭引数 4 では、1 の場合と同じ動作になります。接頭引数がこれら以外の場合には、message-forward-as-mime の値を一時的に反転して、接頭引数が与えられなかった場合と同じ動作を行ないます。ディフォルトでは、デコードされたメッセージが rfc822 形式の MIME パートとして生成されます。

S O p
     現在の一連の記事を要約して、その結果をニュースグループに送ります (gnus-summary-digest-post-forward)。この命令はプロセス/接頭引数の習慣を用います。

S u
     ファイルを uuencode して分割し、それらを連続して投稿します (gnus-uu-post-news)。(see Uuencoding and Posting)。

また see ヘッダー命令 (The Message Manual), にさらなる情報があります。

概略メッセージ命令
---------

S y
     現在の記事を、すでに存在するメッセージ作成バッファーに貼り付けます (gnus-summaryyank-message)。この命令は貼り付けたいメッセージバッファーの入力を促し、プロセス/接頭引数の習慣を理解します (see Process/Prefix)。

記事を取り消す
-------

何かを書いた後で、本当に、本当に、ほ ん と う にそれを投稿していなければなぁと思ったことはありませんか。

えーと、メールは取り消すことはできないのですが、ニュースの投稿は取り消すことができます。

取り消したい記事を見つけて下さい (取り消すことができるのは自分の記事だけです。変なことは試さないで下さい)。そして C か S c を押して下さい (gnus-summary-cancel-article)。あなたの記事が取り消されます---世界中の機械があなたの記事を取り消します。この命令はプロセス/接頭引数の習慣を用います (see Process/Prefix)。

しかし注意して欲しいのは、すべてのサイトが取り消しを扱っているわけではないことです。ですから、たいていのサイトが問題の記事を取り消しても、あちこちであなたの記事は生き残るかもしれません。

Gnus は取り消すときに『現在』の選択方法を使います。標準の投稿方法を使いたいのであれば、文字接頭引数 a を使って下さい (see Symbolic Prefixes)。

Gnus は Cancel-Lock ヘッダー (see ニュースを取り消す (The Message Manual)) を使って、あなただけがあなたのメッセージをキャンセルできるようにします。

もし何か間違いをしたのに気付いて、訂正をしたいのであれば、代替 (superseding) 記事を投稿して元記事を置き換えることができます。

元記事のところへ移動して、S s を押して下さい (gnus-summary-supersede-article)。それを普通に送信する前に、記事を好きなように編集することができます。

代替に関しても、取り消しと同じことが当てはまります。こちらの方がもっとよく当てはまるかもしれません: いくつかのサイトは代替を受け付けません。これらのサイトでは、ほとんど同じ記事を二回投稿したようになってしまいます。

もしさっき記事を投稿したばかりですぐに変更したくなった場合、記事が最初にあなたのサイトに現れる前に取り消し/代替をするための巧妙な手段があります。まず、投稿バッファー (*sent ... * のようになっています) に戻って下さい。そこにはあなたがちょうど投稿した記事があり、すべてのヘッダーがそのままあります。Message-ID ヘッダーを Cancel もしくは Supersedes に変更して下さい。そして、いつもやっているように単に C-c C-c を押して記事を送信して下さい。前の記事は取り消されるか置き換えられるでしょう。

ちょっと覚えておいて下さい: 'supersede' (代替) という語の中に 'c' は無いということを。

遅延記事
====

ときとして、あなたはメッセージの送信を先延ばしにしたいと思うことはありませんか。例えば、あなたが大切なだれかの誕生日を思い出すために、ちょうどその日に届くメッセージを用意したいと思ったとしましょう。 gnus-delay パッケージはこれにうってつけです。設定は簡単です:

     (gnus-delay-initialize)

普段はメッセージを送信するのに Message モードで C-c C-c コマンドを使いますよね。先延ばしにするには、代わりに C-c C-j (gnus-delay-article) を使って下さい。そうすると、どのくらい遅らせるかを尋ねてきます。可能な返事は次の通りです:

  * 期間。整数と一つの文字で指定します。例えば 42d は 42 日遅らせることを意味します。使うことができる文字は m (分)、h (時)、 d (日), w (週), M (月) および Y (年) です。

  * 日付。YYYY-MM-DD のような形式で指定します。メッセージの送信はその日の特定の時刻 (ディフォルトは 8 時) まで遅らせられます。 gnus-delay-default-hour も参照して下さい。

  * 時刻。am/pm を含まない 24 時間制の、hh:mm の形式で与えます。送信されるのは今日のその時刻ですが、すでにその時刻を過ぎてしまっていた場合は翌日のその時刻になります。ですから、朝の 10 時に 11:15 を指定した場合は 1時間15分後に送信されることになります。しかし 9:20 を指定した場合は翌日の時刻を意味します。

gnus-delay-article の動作は、以下の数個の変数に影響されます:

gnus-delay-default-hour
     特定の日付を指定した場合に、メッセージがその日の何時に送信されるかを与えます。可能な値は 0 から 23 までの整数です。

gnus-delay-default-delay
     ディフォルトの遅延を与える文字列です。前述のどんな形式でも可能です。

gnus-delay-group
     遅延記事は、ドラフトサーバーのこのグループに期限が来るまで保管されます。たぶんあなたはこれを変更する必要は無いでしょう。ディフォルトの値は "delayed" です。

gnus-delay-header
     それぞれの記事が送信される日時はヘッダーに記録されます。この変数はヘッダー名の文字列です。たぶんあなたはこれを変更する必要は無いでしょう。ディフォルトの値は "X-Gnus-Delayed" です。

送信の先延ばしはこんなふうに行なわれます: gnus-delay-article コマンドで、あなたはどのくらい遅らせるかを指定します。Gnus はメッセージを送信する日時を計算して X-Gnus-Delayed ヘッダーに記録し、そのメッセージを nndraft:delayed グループに納めます。

そして、あなたが新着ニュースを取得しようとするときはいつも、Gnus は送信する期限に達した記事をそのグループで探して、それらを送信します。これには関数 gnus-delay-send-queue が使われます。ディフォルトではこの関数は gnus-get-new-news-hook に追加されますが、もちろんあなたはこれを変更することができます。おそらくあなたは、ドラフトの送信にデーモンを使いたいと思うのではないでしょうか? それには、デーモンに関数 gnus-delay-send-queue を実行せよ、と言うだけで良いのです。

gnus-delay-initialize
     ディフォルトではこの関数は gnus-delay-send-queue の gnus-get-new-news-hook への追加を行ないます。ですが、これは第二オプション引数 no-check を受け付けます。もしそれが非-nil だったら gnus-get-new-news-hook は変更されません。第一オプション引数は無視されます。

     例えば (gnus-delay-initialize nil t) は何もしないことを意味します。あなたは遅延記事の送信にデーモンを使いたいのでしょうね。でも、それを設定することを忘れないで下さいね。:-)

記事に印を付ける
========

記事に付けられる印はいくつかあります。

記事の 購読度 (うひょーっ、何てすらばやしい造語だ!) を決定する印があります。英字でない文字が一般に 未読 を意味するのに対して、英字の印は一般に 既読 を意味します。

加えて、購読度に影響しない印もあります。

これらの印を操作する過剰なくらいの命令があります:

未読記事
----

以下の印はいろいろな方法で記事に未読の (ような) 印を付けます。

!
     可視記事 (ticked) として印を付けます (gnus-ticked-mark)。

     可視記事 とは常に可視状態である記事のことです。おもしろいと思う記事があった場合や、読むのを先に延ばしたいときや、後で返答をしたいときに、普通は可視印を付けます。しかし、記事は期限切れ消去されることもあります (ニュースサーバー上の記事を消去するのはニュースサーバーのソフトウェアで、Gnus 自体は可視記事を期限切れ消去しません) ので、永遠に記事を保存しておきたい場合は、その記事を永続にする必要があります (see Persistent Articles)。

?
     保留として印を付けます (gnus-dormant-mark)。

     保留記事 はフォローアップがあったときにだけ概略バッファーに現れます。フォローアップが無いときも表示させたいときは、/ D 命令を使って下さい (see Limiting)。それ以外は (見えるかどうかは別にして)、可視記事 (ticked) と似たようなものです。

SPACE
     未読として印を付けます (gnus-unread-mark)。

     未読記事 は今までまったく読まれていない記事のことです。

既読記事
----

以下のすべての印は記事に既読の印を付けます。

r
     利用者が手動で d 命令もしくはそれに類する手段を使って、既読の印を付けた記事です (gnus-del-mark)。

R
     実際に読まれた記事 (gnus-read-mark)。

O
     前回のセッションで既読の印を付けて、今は 古く なってしまった記事。

K
     削除された印 (gnus-killed-mark)。

X
     削除ファイルによって削除の印がついた記事 (gnus-kill-file-mark)。

Y
     低すぎるスコアのために既読の印がついた記事 (gnus-low-score-mark)。

C
     キャッチアップによって既読の印がついた記事 (gnus-catchup-mark)。

G
     取り消された記事 (gnus-canceled-mark)。

F
     SOUP されている記事 (gnus-souped-mark)。See SOUP.

Q
     まばらに参照された記事 (gnus-sparse-mark)。 See Customizing Threading.

M
     重複抑制により既読の印のついた記事 (gnus-duplicate-mark)。 See Duplicate Suppression.

これらのすべての印は、本当にただ記事が既読として印がついていることを意味するだけです。適応スコアリングをしたときには違ったように解釈されますけれど。

もう一つ、特別な印があります:

E
     期限切れ消去可能として印のついた記事 (gnus-expirable-mark)。

     記事を 期限切れ消去可能 として印を付ける (もしくは、自動的にそのように印を付ける) ことは、普通のグループではあまり意味がありません---利用者はニュース記事の期限による削除を制御していません。しかし、例えばメールグループでは、期限切れ消去可能 として印のついた記事は、いつでも Gnus によって削除されることがあります。

他の印
---

記事が読まれたかどうかには関係しない印がいくつかあります。

  * 現在の記事にしおりを挟むことができます。あなたは猫のおしっこの習慣に関する長い論文を読んでいて、それを読み終わる前に晩ご飯を食べに家に帰らなければならなかったとしましょう。そんなとき、記事にしおりを挟むことができます。次にその記事に出くわすと、Gnus はそのしおりのところへ移動するでしょう。 See Setting Marks.

  * 返信したかフォローアップした (つまり、答えた) すべての記事には、二桁目に A の印が付きます (gnus-replied-mark)。

  * 転送したすべての記事には、二桁目に F の印が付きます (gnus-forwarded-mark)。

  * 記事キャッシュに貯められている記事は、二桁目に * の印が付きます (gnus-replied-mark)。See Article Caching.

  * (何らかの方法によって; 必ずしも宗教的というわけではなく) 『救済された』 (原文は saved==保存された) 記事は、二桁目に S の印が付きます (gnus-saved-mark)。

     まだサーバーが利用者に見せていない記事は、二桁目に N の印が付きます (gnus-recent-mark)。たいていのサーバーはこの印をサポートせず、その場合は単に表示されません。gnus-unseen-mark と見比べて下さい。

  * まだ Gnus で読まれたことがない記事は、二桁目に . の印が付きます (gnus-unseen-mark)。gnus-recent-mark と見比べて下さい。

  * Gnus エージェント (see Agent Basics) を使っているとき、記事は unplugged (オフライン) で見るためにダウンロードされるかもしれません。%O の仕様を使っていると、それらの記事にはその仕様に + の印が付きます。(変数 gnus-downloaded-mark でどの文字を使うかを制御します。)

  * Gnus エージェント (see Agent Basics) を使っているとき、いくつかの記事はダウンロードされていないかもしれません。Unplugged (オフライン) の状態ではそのような記事を見ることができません。%O の仕様を使っていると、それらの記事にはその仕様に - の印が付きます。(変数 gnus-undownloaded-mark でどの文字を使うかを制御します。)

  * Gnus エージェント (see Agent Basics) はいくつかの記事を自動的にダウンロードしますが、自動的にダウンロードされない記事にもダウンロードのための明示的な印を付けることは可能です。そのような明示的に印が付けられた記事には、最初の桁に % の印が付きます。(変数 gnus-downloadable-mark でどの文字を使うかを制御します。)

  * %e の仕様が使われると、スレッドがあるかどうかの印が gnus-not-empty-thread-mark または gnus-empty-thread-mark によって、三桁目に付きます。

  * 最後に プロセス印 があります (gnus-process-mark)。いろいろな種類の命令が、プロセス印があるとそれに対して実行されます。例えば X u (gnus-uu-decode-uu) は、プロセス印の付いたすべての記事を uudecode して表示します。プロセス印の付いた記事は二桁目に # があります。

たいていのこれら『購読度と関係無い』印は、ディフォルトでは二桁目に現れることに気付いたでしょう。では、キャッシュされていて、保存されていて、返答した記事にプロセス印を付けた場合は、どうなるのでしょう?

たいしたことはありません。優先順位は次のようになっています: プロセス → キャッシュ → 返答済み → 保存。ですから、ある記事がキャッシュに入っていて返答されていた場合、キャッシュ印が見えるだけで、返答済み印は見えません。

印を付ける
-----

すべての印を付けるための命令は、数値接頭引数を受け付けます。

M c
M-u
     現在の記事から、すべての購読度に関する印を消去します (gnus-summary-clear-mark-forward)。要するに、記事に未読の印を付けます。

M t
!
     現在の記事に可視記事の印を付けます (gnus-summary-tick-article-forward)。See Article Caching.

M ?
?
     現在の記事に保留記事の印を付けます (gnus-summary-mark-as-read-forward)。See Article Caching.

M d
d
     現在の記事に既読の印を付けます (gnus-summary-mark-as-read-forward)。

D
     現在の記事に既読の印を付け、前の行にポイントを移動します (gnus-summary-mark-as-read-backward)。

M k
k
     現在の記事と同じ表題を持つすべての記事を既読として印を付け、次の未読記事を選択します (gnus-summary-kill-same-subject-and-select)。

M K
C-k
     現在の記事と同じ表題を持つすべての記事を既読として印を付けます (gnus-summary-kill-same-subject)。

M C
     すべての未読記事に既読の印を付けます (gnus-summary-catchup)。

M C-c
     グループのすべての記事に---可視記事や保留記事でさえも、既読の印を付けます (gnus-summary-catchup-all)。

M H
     現在のグループの、現在位置とそれ以前の記事を既読として印を付けます (gnus-summary-catchup-to-here)。

M h
     現在のグループの、現在位置とそれ以降の記事を既読として印を付けます (gnus-summary-catchup-from-here)。

C-w
     ポイントとマークの間の記事に既読の印を付けます (gnus-summary-mark-region-as-read)。

M V k
     ディフォルトのスコア (もしくは数値接頭引数) よりも低いスコアの記事を削除します。

M e
E
     現在の記事を期限切れ消去可能として印を付けます (gnus-summary-mark-as-expirable)。

M b
     現在の記事にしおりを設定します (gnus-summary-set-bookmark)。

M B
     現在の記事のしおりを削除します (gnus-summary-remobe-bookmark)。

M V c
     ディフォルトのスコア (もしくは数値接頭引数) よりも大きいスコアを持つ記事のすべての印を消去します (gnus-summary-clar-above)。

M V u
     ディフォルトのスコア (もしくは数値接頭引数) よりも大きいスコアを持つすべての記事に可視印を付けます (gnus-summary-tick-above)。

M V m
     印の入力を促し、ディフォルトのスコア (もしくは数値接頭引数) よりも大きなスコアを持つすべての記事にその印を付けます (gnus-summary-mark-above)。

変数 gnus-summary-goto-unread は印が付けられた後にどのような動作がなされるかを決定します。もし nil でないと、ポイントは次/前の未読記事に移動します。もし nil であると、ポイントは一行上か下に行くだけです。特別な場合として、この変数が never であると、すべての印を付ける命令と (SPACE のような) 他の命令は次の記事が未読であろうが無かろうが次の記事に移動します。ディフォルト値は t です。

Generic Marking Commands
------------------------

記事に可視の印を付ける命令 (!) に、次の記事に移動してもらいたい人がいます。次の未読記事に移動してもらいたい人もいます。さらに、現在の記事に留まっていてもらいたい人もいるでしょう。そして、前の (未読の) 記事に行って欲しい人がいるとはまだ聞いたことはありませんが、そうしたいと思う人も間違いなくいると思います。

この五つの動作を五つの違った印付け命令と掛け算すると、どの命令が何をすべきかの非常に複雑な変数の組を持つことになります。

この窮地を脱するために、Gnus はこれらすべての違ったことをする命令を提供します。これらは概略バッファーの M M マップにあります。すべてを見るためには M M C-h を入力して下さい---このマニュアルで一覧を出すには多過ぎます。

これらの命令を直接使うことはできますが、ほとんどの利用者は概略モードのキーマップを交換する方を好むでしょう。例えば、! 命令に次の未読記事の代わりに次の記事に移動して欲しいとすると、このようなことができます:

     (add-hook 'gnus-summary-mode-hook 'my-alter-summary-map)
     (defun my-alter-summary-map ()
       (local-set-key "!" 'gnus-summary-put-mark-as-ticked-next))

もしくは、

     (defun my-alter-summary-map ()
       (local-set-key "!" "MM!n"))

プロセス印を付ける
---------

プロセス印は概略バッファーに # として表示され、他のコマンドで処理させる記事に印を付けるために使われます。例えば、四つの記事に印を付けてから * コマンドを使うと、Gnus はそれら四つの記事をキャッシュに入れます。詳しくは Process/Prefix をどうぞ。

M P p
#
     現在の記事にプロセス印を付けます (gnus-summary-mark-as-processable)。

M P u
M-#
     もし現在の記事にプロセス印があれば取り除きます (gnus-summary-unmark-as-processable)。

M P U
     すべての記事からプロセス印を取り除きます (gnus-summary-unmark-all-processable)。

M P i
     プロセス印の付いている記事とそうでない記事を逆にします (gnus-uu-mark-by-regexp)。

M P R
     正規表現に合致する Subject ヘッダーを持つ記事に印を付けます (gnus-uu-mark-by-regexp)。

M P G
     正規表現に合致する Subject ヘッダーを持つ記事から印を削除します (gnus-uu-unmark-by-regexp)。

M P r
     領域にある記事に印を付けます (gnus-uu-mark-region)。

M P g
     領域にある記事から印を削除します (gnus-uu-unmark-region)。

M P t
     現在のスレッド (または副スレッド) のすべての記事に印を付けます (gnus-uu-mark-thread)。

M P T
     現在のスレッド (または副スレッド) のすべての記事から印を取り除きます (gnus-uu-unamrk-thread)。

M P v
     接頭引数よりも大きなスコアを持つすべての記事に印を付けます (gnus-uu-mark-over)。

M P s
     現在の一連の記事に印を付けます (gnus-uu-mark-series)。

M P S
     すでにいくつか印の付いた記事を持つ一連の記事群すべてに印を付けます (gnus-uu-mark-sparse)。

M P a
     一連の記事が出てくる順番にそれに属するすべての記事に印を付けます (gnus-uu-mark-all)。

M P b
     バッファーのすべての記事を現れている順番に印を付けます (gnus-uu-mark-buffer)。

M P k
     現在のプロセス印をスタックに積んで、すべての記事を無印にします (gnus-summary-kill-process-mark)。

M P y
     スタックから前回のプロセス印を取り出して、それを復元します (gnus-summary-yank-process-mark)。

M P w
     現在のプロセス印をスタックに積みます (gnus-summary-save-process-mark)。

そして、記事の本文の内容に基づいてプロセス印を付けるやり方については、 Searching for Articles の & 命令を参照して下さい。

制限をする
=====

現在グループにある記事の一部だけを表示するように概略バッファーを制限できれば便利なことがあります。多くの制限命令が持つ効果は、概略バッファーから少し (もしくは多く) の記事を削除することです。

すべての制限命令はサーバーからすでに取得された記事の一部分に作用します。これらの命令はどれもサーバーに追加の記事を要求しません。

/ /
/ s
     概略バッファーをいくつかの表題と合致するものだけに制限します (gnus-summary-limit-to-subject)。接頭引数が与えられると、合致する記事を除外します。

/ a
     概略バッファーを何人かの著者に合致するものだけに制限します (gnus-summary-limit-to-author)。接頭引数が与えられると、合致する記事を除外します。

/ R
     概略バッファーをいくつかの受信者に合致する記事だけに制限します (gnus-summary-limit-to-recipient)。接頭引数が与えられると、合致する記事を除外します。

/ x
     ``追加'' のヘッダーの一つに合致する記事に概略バッファーを制限します (see To From Newsgroups) (gnus-summary-limit-to-extra)。接頭引数が与えられると、合致する記事を除外します。

/ u
x
     概略バッファーを既読の印が付いていない記事に制限します (gnus-summary-limit-to-unread)。接頭引数が与えられると、バッファーを完全に未読記事のみに制限します。これは、可視と保留の記事は含まれないということです。

/ m
     印を尋ねて、その印が付いている記事に制限します (gnus-summary-limit-to-marks)。

/ t
     数値を尋ねて、概略バッファーをその日数より古い (もしくは同じ) 記事に制限します (gnus-summary-limit-to-age)。接頭引数が与えられると、その数値の日よりも新しい記事に制限します。

/ n
     概略バッファーを現在の記事に制限します (gnus-summary-limit-to-articles)。プロセス/接頭引数の習慣を使います (see Process/Prefix)。

/ w
     前の制限をスタックから取り出して、復元します (gnus-summary-pop-limit)。接頭引数を与えられると、すべての制限をスタックから取り出します。

/ .
     概略バッファーをまだ読まれたことが無い記事に制限します (gnus-summary-limit-to-unseen)。

/ v
     概略バッファーをあるスコアと同じか、それより大きなスコアを持つ記事に制限します (gnus-summary-limit-to-score)。

/ p
     概略バッファーを display グループパラメーターの述語を満足させるように制限します (gnus-summary-limit-to-display-predicate)。この述語に関する詳細は Group Parameters を参照して下さい。

/ r
     概略バッファーを返信した記事だけに制限します (gnus-summary-limit-to-replied)。接頭引数が与えられると、返信した記事以外の記事に制限します。

/ E
M S
     すべての消去された記事を制限に含めます (gnus-summary-limit-include-expunged)。

/ D
     すべての保留記事を制限に含めます (gnus-summary-limit-include-dormant)。

/ *
     すべてのキャッシュに入っている記事を制限に含めます (gnus-summary-limit-include-cached)。

/ d
     すべての保留記事を制限から除外します (gnus-summary-limit-exclude-dormant)。

/ M
     すべての印付き記事を除外します (gnus-summary-limit-exclude-marks)。

/ T
     現在のスレッドのすべての記事を制限に含めます (gnus-summary-limit-include-thread)。

/ c
     子記事の無いすべての保留記事を制限から除外します (gnus-summary-limit-exclude-childless-dormant)。

/ C
     すべての除外された未読の記事に既読の印を付けます (gnus-summary-limit-mark-excluded-as-read)。接頭引数が与えられると、可視と保留のみの印の記事も既読として印を付けます。

/ N
     すべての新しい記事を概略バッファーに挿入します。 BACK-END-get-new-mail が非-nil だったら、新しいメールの到来を調べるということです。

/ o
     すべての古い記事を概略バッファーに挿入します。数値の接頭引数が与えられると、その個数の記事を取り込みます。

スレッド
====

Gnus はディフォルトで記事をスレッド表示します。スレッドにする とは、ある記事への応答を応答した記事の直後に置く---階層的流儀で、ということです。

スレッドは記事の References 欄を調べることによって行なわれます。理想的な世界では、これだけで木を完成させるのに十分なのですが、不運なことに References 欄はしばしば壊れているか、時には単に無いことがあります。怪しげなニュースの伝搬は問題を悪化させるので、満足な結果を得るためには他の検出法を採用しなければなりません。過剰な対策法は存在していて、その恐るべき詳細は Customizing Threading に詳しく書いてあります。

まず、概念の概観です:

根本 (root)
     スレッドで一番頂点にある記事です；スレッドの最初の記事です。

スレッド (thread)
     木のような記事の構成です。

副スレッド (sub-thread)
     木のような構造の (より) 小さな部分です。

無束縛スレッド (loose threads)
     記事の期限切れ消去や、根本がすでに前回のセッションで読まれたことにより概略バッファーに表示されない、等の理由により、スレッドはしばしば根本を失います。そのようなときには、普通は多くの副スレッドがあって、本当は一つのスレッドに属しているのですが、根本にはつながっていない、ということになります。こういうスレッドが無束縛スレッドと呼ばれています。

スレッド集め (thread gathering)
     副スレッドを大きなスレッドに集めようとする試みです。

まばらスレッド (sparse threads)
     そこではたぶんいくつかの記事が失われてしまったのだろうと『推測された』スレッドのことで、概略バッファーでは空行で表示されます。

スレッドをカスタマイズする
-------------

無束縛スレッド
.......

gnus-summary-make-false-root
     もし nil でないと、Gnus はすべてのつながっていない部分木を一つの大きな木にして、頂上にみせかけの根本を作ります。(ちょっと待って下さい。頂上に根元 (root) ですって? ええ、そうなのです。) つながっていない部分木は本当の根本が期限切れ消去されたか、前回のセッションで根本を読んだり削除したときにできます。

     本当のスレッドが無いときは、Gnus は何かでっち上げをする必要があります。この変数は Gnus が使うべきごまかしの方法を示しています。値としてとることができる四つの候補があります。

     養子 (adopt)
          Gnus は孤児になった記事群の最初のものを親にします。この親はすべての他の記事を養子にします。それらの養子記事は、標準の角括弧 ([]) の代わりに、先の尖った括弧 (<>) で印が付けられます。これがディフォルトの手段です。

     みせかけ (dummy)
          Gnus は親のふりをするみせかけの概略行を作ります。このみせかけの行はどの本当の記事にも対応しないので、それを選択することは、みせかけの記事の後の最初の本当の記事を選択をするだけになります。みせかけの根本の様式を指定するために、 gnus-summary-dummy-line-format が使われます。これはたった一つだけのフォーマットの仕様を受け付けます: それは S で、記事の表題です (see Formatting Variables)。たとえ集めるものが無くても、すべてのスレッドにみせかけの根本を持たせたい場合は、 gnus-summary-make-false-root-always を t に設定して下さい。

     空 (empty)
          Gnus は実際にはどの記事も親にはせず、最初の孤児を除いてすべての孤児の表題欄を単に空のままにします。(実際は gnus-summary-same-subject を表題として使います (see Summary Buffer Format)。)

     none
          まったくどの記事も親にしません。スレッドを集めて、単に順繰りに表示するだけです。

     nil
          無束縛スレッドを集めません。

gnus-summary-gather-subject-limit
     無束縛スレッドは記事の表題を比較することによって集められます。もしこの変数が nil であると、Gnus は無束縛スレッドを一つの大きな超スレッドに集める前に、無束縛スレッドの表題が完全に一致することを要求します。これは、長い表題の行を切り落としてしまう間抜けなニュースリーダーが存在する現状では、あまりに厳しい要求かもしれません。そう思うのなら、この変数を例えば 20 に設定して、表題の最初の 20 文字だけが一致することを要求するようにして下さい。この変数を本当に低い数値に設定すると、目についたもののすべてを Gnus が一つのスレッドに集めるのを見ることになるでしょう。それはあまり有用ではありません。

     この変数を特別な値 fuzzy に設定すると、Gnus は表題の文字列を大雑把に比較するアルゴリズムを使います (see Fuzzy Matching)。

gnus-simplify-subject-fuzzy-regexp
     正規表現または正規表現のリストのどちらかです。表題の大雑把な比較を行なうときに、それらに合致する文字列を表題から取り除きます。

gnus-simplify-ignored-prefixes
     もし gnus-summary-gather-subject-limit を 10 くらいに低く設定したならば、この変数を何か意味のあるものに設定することを考えるでしょう:

          (setq gnus-simplify-ignored-prefixes
                (concat
                 "\\`\\[?\\("
                 (mapconcat
                  'identity
                  '("looking"
                    "wanted" "followup" "summary\\( of\\)?"
                    "help" "query" "problem" "question"
                    "answer" "reference" "announce"
                    "How can I" "How to" "Comparison of"
                    ;; ...
                    )
                  "\\|")
                 "\\)\\s *\\("
                 (mapconcat 'identity
                            '("for" "for reference" "with" "about")
                            "\\|")
                 "\\)?\\]?:?[ \t]*"))

     この正規表現に合致するすべての語は、二つの表題を比較する前に取り除かれます。

gnus-simplify-subject-functions
     nil でないと、この変数は gnus-summary-gather-subject-limit よりも優先されます。この変数は Subject の文字列に反復して作用させて簡単にするための、関数のリストである必要があります。

     このリストに入れて役に立つような関数は次のようなものです:

     gnus-simplify-subject-re
          前の方にある Re: を取り除きます。

     gnus-simplify-subject-fuzzy
          大雑把な比較ができるように簡単にします。

     gnus-simplify-whitespace
          余分な空白 (whitespace) を取り除きます。

     gnus-simplify-all-whitespace
          すべての空白 (whitespace) を取り除きます。

     もちろん、あなた自身の関数を書くこともできます。

gnus-summary-gather-exclude-subject
     無束縛スレッド集めは表題だけで行なわれるので、特に や (none) のような良くある表題のときは、多くの間違いを起こす可能性があります。この状況を少し良くするために、正規表現 gnus-summary-gather-exclude-subject を使うことによって、集める過程においてどんな表題を除外するかを指示することができます。ディフォルトは ^ *$\\|^(none)$ です。

gnus-summary-thread-gathering-function
     Gnus は Subject 欄を調べることによってスレッドを集めます。これは、結果的にまったく関係の無い記事が同じ『スレッド』に含まれるかもしれないことを意味し、混乱の元です。代替手段は、合致するものを見つけるために References 欄にある Message-ID をすべて調べることです。これは集められたスレッドが関係の無い記事をまったく含まないことを保証しますが、いかれたニュースリーダーで投稿した記事は適切に集められないということでもあります。ペストかコレラかの選択権はあなたにあります。

     gnus-gather-threads-by-subject
          この関数はディフォルトの収集関数で、排他的に Subject を調べます。

     gnus-gather-threads-by-references
          この関数は排他的に References 欄を調べます。

     References によって集めることを試してみたいのであれば、次のようにすることができます:

          (setq gnus-summary-thread-gathering-function
                'gnus-gather-threads-by-references)

スレッドを埋める
........

gnus-fetch-old-headers
     もし nil でないと、Gnus は古いスレッドをもっと古いヘッダー、すなわち既読の印が付いている記事のヘッダー、を取得することで構築しようとします。できるだけ少ない概略行を表示したいけれど、できるだけたくさんの無束縛スレッドをつなげておきたいときは、この変数を some か数値に設定して下さい。もし数値に設定したときは、それより多い追加のヘッダーは取得されません。どちらの場合でも、古いヘッダーの取得は、使っているバックエンドが overview ファイルを使っている場合だけ動作します。それらのバックエンドは、普通は nntp, nnspool, nnml および nnmaildir です。スレッドの根本がサーバーによって期限切れ消去されてしまったら、Gnus はどうしようもないことも覚えておいて下さい。

     この変数は invisible に設定することもできます。これは視覚的な効果は何もありませんが、A T 命令をよく使うのであれば役に立つでしょう (see Finding the Parent)。

gnus-fetch-old-ephemeral-headers
     gnus-fetch-old-headers と同じですが、一時ニュースグループのためにだけ使われます。

gnus-build-sparse-threads
     古いヘッダーを取得すると遅くなることがあります。この変数を some に設定することによって、同じような低賃金の効果を得ることができます。そうすると、Gnus はすべての記事の完全な References 欄を見て、同じスレッドに属する記事をつなごうとします。これは、記事がそのスレッドから失われていると Gnus が推測したスレッド表示に ずれ を残すでしょう。(これらのずれは普通の概略行のように見えます。もしずれを選択すると、Gnus はその当の記事を取得しようとします。) この変数が t であると、Gnus はスレッドを補完するのに役立つかどうかを考慮せずに、すべての『ずれ』を表示します。最後に、この変数が more であると、Gnus はどこにもつながっていない枝葉のまばらな節を切り落としません。この変数はディフォルトでは nil です。

gnus-read-all-available-headers
     これはあまり役に立たない、いささかはっきりしない変数です。ニュースではないグループにおいて、概略バッファーを作るためにバックエンドが極めて多くのものを取り込まなければならず、しかも親記事を辿ることができない場合に使うことを想定しています。それは主に nnultimate グループのような、ウェブに基づいたグループでの場合です。

     そんなグループを使わない場合はディフォルトの nil のままにしておくのが無難です。使いたい場合はグループ名に合致する正規表現か、すべてのグループが対象になる t にして下さい。

もっとスレッドを
........

gnus-show-threads
     この変数が nil であると、スレッドは作られず、ここにある残りのすべての変数はまったく効果が無くなります。スレッド作りを止めるとグループの選択が少し速くなりますが、記事を読むのがもっと遅く、不便になることは確実です。

gnus-thread-hide-subtree
     これが nil でないと、すべてのスレッドは概略バッファーが生成されたときに隠れます。

     これは述語指示子であることもできます (see Predicate Specifiers)。利用できる述語は gnus-article-unread-p と gnus-article-unseen-p です。

     これは例です:

          (setq gnus-thread-hide-subtree
                '(or gnus-article-unread-p
                     gnus-article-unseen-p))

     (これはかなりばかげた例です。なぜならすべてのまだ読まれたことが無い記事は未読でもあるからなのですが、趣旨は汲み取って下さい。)

gnus-thread-expunge-below
     この数値より少ない総スコア (gnus-thread-score-function で定義された関数を使って算出されます) を持つすべてのスレッドは消去されます。この変数はディフォルトでは nil で、これはどのスレッドも消去されないということです。

gnus-thread-hide-killed
     スレッドを削除すると、この変数が nil でない場合、部分木は隠されます。

gnus-thread-ignore-subject
     ときどき誰かがスレッドの途中で表題を変更することがあります。この変数が nil でないと (これがディフォルトですが)、表題の変更は無視されます。もし nil だと、表題の変更をすると別のスレッドになります。

gnus-thread-indent-level
     これは、それぞれの副スレッドがどれくらい字下げ (indent) されるべきかを決める数値です。ディフォルトは 4 です。

gnus-sort-gathered-threads-function
     とりわけメーリングリストでは、ときとして手元にメールが到着する順番は必ずしもメーリングリストに到着した順番と同じでは無いことがあります。その結果、副スレッドをディフォルトの gnus-thread-sort-by-number で並べ換えると、応答の方がそれの元記事より先に現れてしまうことがあります。グループパラメーターや適切なフック (例えば gnus-summary-generate-hook) でこの変数を代わりの値 (例えば gnus-thread-sort-by-date) に設定することによって、そのような場合に、より論理的な副スレッドの順番を生成することができます。

低レベルにおけるスレッド作成
..............

gnus-parse-headers-hook
     すべてのヘッダーを解析する前に実行されるフックです。

gnus-alter-header-function
     この変数の値が nil ではなくて関数であると、ヘッダー構造 (訳注: 記事の主要なヘッダーの内容を効率良く保持するための Lisp オブジェクト) を変更するために呼ばれます。関数は記事ヘッダーのベクトル (訳注: すなわちヘッダー構造) とともに呼ばれ、それが何らかの方法で変更されます。例えば Message-ID を体系的な方法で (接頭語などを付け加えることによって) 変更してしまうメールからニュースへのゲートウェイがある場合、この変数を設定することによって、その Message-ID を元の意味のあるものに戻すことができます。これは一つの例です:

          (setq gnus-alter-header-function 'my-alter-message-id)

          (defun my-alter-message-id (header)
            (let ((id (mail-header-id header)))
              (when (string-match
                     "\\(<[^<>@]*\\)\\.?cygnus\\..*@\\([^<>@]*>\\)" id)
                (mail-header-set-id
                 (concat (match-string 1 id) "@" (match-string 2 id))
                 header))))

          訳注: 取得した記事の Message-ID 欄から、@ の前に付加された cygnus. で始まる文字列を取り除きます。

スレッドの命令
-------

T k
C-M-k
     現在のスレッド (または副スレッド) のすべての記事に既読の印を付けます (gnus-summary-kill-thread)。もし接頭引数が正であると、代わりにすべての印を取り除きます。接頭引数が負であると、代わりに記事を可視にします。

T l
C-M-l
     現在のスレッド (または副スレッド) のスコアを下げます (gnus-summary-lower-thread)。

T i
     現在のスレッド (または副スレッド) のスコアを上げます (gnus-summary-raise-thread)。

T #
     プロセス印を現在のスレッド (または副スレッド) に付けます (gnus-uu-mark-thread)。

T M-#
     現在のスレッド (または副スレッド) からプロセス印を取り除きます (gnus-uu-unmark-thread)。

T T
     スレッド表示を切り替えます (gnus-summary-toggle-threads)。

T s
     もしあれば、現在の記事の下に隠れているスレッドを表示します (gnus-summary-show-thread)。

T h
     現在のスレッド (または副スレッド) を隠します (gnus-summary-hide-thread)。

T S
     すべての隠されているスレッドを表示します (gnus-summary-show-all-threads)。

T H
     すべてのスレッドを隠します (gnus-summary-hide-all-threads)。

T t
     現在の記事のスレッドをもう一度作り直します (gnus-summary-rethread-current)。これは概略バッファーがスレッド表示されていないときでも動作します。

T ^
     現在の記事を印付きの (もしくは前の) 記事の子記事にします (gnus-summary-reparent-thread)。

以下の命令はスレッド移動命令です。これらはすべて数値接頭引数を受け付けます。

T n
C-M-f
M-down
     次のスレッドに移動します (gnus-summary-next-thread)。

T p
C-M-b
M-up
     前のスレッドに移動します (gnus-summary-prev-thread)。

T d
     スレッドを下ります (gnus-summary-down-thread)。

T u
     スレッドを登ります (gnus-summary-up-thread)。

T o
     スレッドの頂上に移動します (gnus-summary-top-thread)。

スレッドを作成するときに表題を無視すると、当然ながらいくつかの違った表題があるスレッドが出来上がります。そして T k (gnus-summary-kill-thread) のような命令を発するときに、全体のスレッドを削除するのではなく、現在の記事と同じ表題を持つ部分だけを削除したいときがあるかもしれません。もしこの発想が良いと思うのであれば、gnus-thread-operation-ignore-subject をいじってみて下さい。これが nil でないと (それがディフォルトですが)、スレッドの命令を実行しているときに表題は無視されます。これが nil だったら、同じスレッドにある異なる表題を持つ記事は、そのとき行なう操作の対象に含まれません。この変数が fuzzy であると、大雑把な比較によって等しいと判定される表題を持つ記事だけが対象に含まれます (see Fuzzy Matching)。

並べ替え
====

概略でスレッドの表示を使っているのであれば、 gnus-thread-sort-functions を設定することによってスレッドを並べ替えることができます。この変数の値は単独の関数、関数のリスト、または関数と (関数でないもの) の要素を含むリストであることができます。

ディフォルトでは並べ替えは記事番号に基づいて行なわれます。すでに用意されている並べ替え述語関数は gnus-thread-sort-by-number, gnus-thread-sort-by-author, gnus-thread-sort-by-recipient, gnus-thread-sort-by-subject, gnus-thread-sort-by-date, gnus-thread-sort-by-score, gnus-thread-sort-by-most-recent-number, gnus-thread-sort-by-most-recent-date, gnus-thread-sort-by-random および gnus-thread-sort-by-total-score です。

それぞれの関数は二つのスレッドをとり、最初のスレッドがもう一方より先に並べ替えられるべきであれば nil でない値を返します。実際の並べ替えは、普通それぞれのスレッドの根本だけを調べることによって行なわれることに気を付けて下さい。

二つ以上の関数を使う場合、並べ替えの第一の鍵はリストの最後の関数でなければなりません。並べ替え関数のリストのなるべく先頭に、おそらく常に gnus-thread-sort-by-number を含めておくべきでしょう。これは、他の並べ替えの基準が等しいスレッドが、記事番号の登り順に表示されることを保証します。

スコアの逆順、表題、そして最後に番号、の順に並べ替えたいのであれば、次のようにできます:

     (setq gnus-thread-sort-functions
           '(gnus-thread-sort-by-number
             gnus-thread-sort-by-subject
             (not gnus-thread-sort-by-total-score)))

最大のスコアを持つスレッドが、最初に概略バッファーに表示されます。スレッドが同じスコアの場合は、英字順に並びかえられます。同じスコアと表題を持つスレッドは番号で並べ替えられ、(普通は) 記事が到着した順番になります。

スコア、到着の逆順に並べ替えたいのであれば、次のようにできます:

     (setq gnus-thread-sort-functions
           '((lambda (t1 t2)
               (not (gnus-thread-sort-by-number t1 t2)))
             gnus-thread-sort-by-score))

変数 gnus-thread-score-function (ディフォルトは +) に設定されている関数は、スレッドの総スコアを計算するために用いられます。役立つ関数は max, min, もしくは二乗、もしくはあなたの好奇心をくすぐるような何かでしょう。

何か変な理由でスレッド表示を使っていないのなら、変数 gnus-article-sort-functions をいじくる必要があります。これは gnus-thread-sort-functions と非常に似ていますが、記事の比較には少々違った関数を使います。使用可能な並べ替え述語関数は gnus-article-sort-by-number, gnus-article-sort-by-author, gnus-article-sort-by-subject, gnus-article-sort-by-date, gnus-article-sort-by-random および gnus-article-sort-by-score です。

スレッドを使っていない概略の表示を表題で並べ替えたいのであれば、次のようなことをすることができます:

     (setq gnus-article-sort-functions
           '(gnus-article-sort-by-number
             gnus-article-sort-by-subject))

非同期記事取得
=======

遠くにある NNTP サーバーからニュースを取得していると、ネットワークの遅延が記事を読むことを嫌な仕事にしてしまうかもしれません。n を押してから次の記事が現れるまで、しばらく待たなければなりませんものね。どうして前の記事を読んでいる間に Gnus が先行して記事を取得してくれないのでしょうか? なぜできないんでしょう、本当に。

まず警告しておきましょう。非同期で記事を取得、特に Gnus がそれを行なう場合には、いくつかの落とし穴があります。

例えば、あなたは短い記事 1 を読んでいて、記事 2 はとても長くて、あなたはそれを読むことには興味が無いとしましょう。Gnus はこのことはわからないので、先行して記事 2 を取得します。あなたは記事 3 を読むことにしますが、 Gnus は記事 2 を取得している最中なので、接続は封鎖されています。

この状況を避けるために、Gnus はサーバーに二つ (二まで数えて下さい) の接続を張ります。これはあまり良いことではないと考える人もいるでしょうが、私には実際の代替手段が見つからないのです。余分な接続を立ち上げるためにはいくばくかの時間がかかるので、Gnus の起動は遅くなります。

Gnus はあなたが読むであろう記事よりもたくさんの記事を取得します。これは記事の先行取得を使わないときよりも、あなたのマシンと NNTP サーバー間の接続にもっと負荷をかけることになるでしょう。サーバー自身にももっと負荷がかかるようになります---余分な記事の要求と、余分な接続によって。

はい、本当はこのようなことをすべきで無いことがこれで分かったでしょう... 本当にそうしたいと思わない限りは。

やり方です: gnus-asynchronous を t に設定して下さい。それ以外の諸々のことは自動的に行なわれます。

gnus-use-article-prefetch を設定することによって、どれくらいの記事を先に取得するべきかを操作することができます。これはディフォルトでは 30 で、グループの記事を読んでいるときに、バックエンドが次の 30 通の記事を先行取得するということです。この変数が t であると、バックエンドは取得できるすべての記事を際限なく先行取得しようとします。これが nil であると、先行取得は行なわれません。

おそらく先行取得をしたくない記事がいくつかあるでしょう---例えば既読記事です。変数 gnus-async-prefetch-article-p は記事が先に取得されるかどうかを制御します。この変数に設定される関数は、問題の記事を先行取得するのであれば nil でない値を返さなければなりません。ディフォルトの関数は gnus-async-read-p で、これは既読記事には nil を返します。この関数は記事のデータ構造を唯一の引数として呼ばれます。

例えば、100 行よりも短い未読記事だけを先に取得したいのであれば、次のようにできます:

     (defun my-async-short-unread-p (data)
       "Return non-nil for short, unread articles."
       (and (gnus-data-unread-p data)
            (< (mail-header-lines (gnus-data-header data))
               100)))

     (setq gnus-async-prefetch-article-p 'my-async-short-unread-p)

これらの関数は何度も何度も呼ばれるので、Gnus を遅くしすぎないように、短く甘美であるのが好ましいです。このようなものをバイトコンパイル (byte-compile) するのは、おそらく良い着想でしょう。

記事は非同期バッファーから遅かれ早かれ削除されなければなりません。 gnus-prefetched-article-deletion-strategy はいつ記事を削除するかを指定します。これは以下の要素を含むリストです:

read
     記事が読まれたときに削除します。

exit
     グループを抜けたときに記事を削除します。

ディフォルトの値は (read exit) です。

記事のキャッシュ
========

非常に 遅い NNTP 接続を使っているのならば、記事をキャッシュすることを考えても良いでしょう。それをすると、それぞれの記事はあなたのホームディレクトリーの下にローカルに溜められます。もう感付いたかもしれませんが、これは i ノードを非常に速く食いつぶすだけでなく、巨大な ディスクスペースを食う可能性があります。それはあなたにウォッカの中で泳ぐようなめまいを起こさせるでしょう。

でも注意深く使われれば、それは記事を保存する、より楽な方法になり得ます。

キャッシュを実行させるには gnus-use-cache を t に設定して下さい。ディフォルトでは、すべての可視または保留として印の付いている記事はローカルのキャッシュ (gnus-cache-directory) に複写されます。このキャッシュが平らな構造か階層的であるかは、通常通り、変数 gnus-use-long-file-name で制御されます。

可視記事か保留記事を再選択した場合は、サーバーの代わりにキャッシュから取得されます。キャッシュにある記事は期限切れ消去されないので、記事をそれらが属するところに居続けさせている間、それらを保存する方法としてこれは役立つかもしれません。保存したいすべての記事に保留の印を付けるだけで、後は心配無用です。

記事に既読の印が付いたときに、それはキャッシュから削除されるのでしょうか。

記事をキャッシュに入れたりキャッシュから削除することは、変数 gnus-cache-enter-articles および gnus-cache-remove-articles によって制御されます。これらは両方ともシンボルのリストです。前者はディフォルトでは (ticked dormant) で、可視記事と保留記事はキャッシュに入れられます。後者はディフォルトでは (read) で、既読の印が付いた記事はキャッシュから削除されます。おそらくこれら二つのリストに含まれるシンボルは ticked, dormant, unread および read でしょう。

それでは、大規模な記事の取得と格納は、どこで関係してくるのでしょうか。 gnus-jog-cache 命令は、すべての購読グループに対して、すべての未読記事を要求し、スコアを付け、キャッシュに保存します。この命令をいつもいつもいつもいつも使うのは、1) NNTP サーバーとの接続が本当に本当に本当に遅くて、2) 本当に本当に本当に巨大なディスクを持っているときだけにするべきです。これは真面目に言っています。ダウンロードされる記事の数を控える一つの方法は、欲しくない記事のスコアを低くして、それらに既読の印を付けることです。そうすれば、それらはこの命令ではダウンロードされません。

すべてのグループではキャッシュをしたくないというのは良くあることです。例えば nnml のメールがホームディレクトリーにあるのなら、それをホームディレクトリーの別の場所にキャッシュするのは意味がありません。二倍の容量を使う方が良いと思うのでなければ。

キャッシュを制限するには、gnus-cacheable-groups を例えば ^nntp のようなキャッシュするグループの正規表現に設定するか、または正規表現 gnus-uncacheable-groups を例えば ^nnml に設定して下さい。両方とも変数のディフォルト値は nil です。もしグループが両方の変数に合致すると、そのグループはキャッシュされません。

キャッシュは、それがどの記事を含んでいるかの情報を、そのアクティブファイル (gnus-cache-active-file) に格納します。このファイル (もしくはキャッシュの他の部分) が何らかの理由でぐちゃぐちゃになってしまった場合、 Gnus はものごとを正しくするための二つのコマンドを提供します。 M-x gnus-cache-generate-nov-databases はすべての NOV ファイルを (再) 作成し、M-x gnus-cache-generate-active はアクティブファイルを (再) 作成します。

gnus-cache-move-cache コマンドは、すべての gnus-cache-directory をどこか別の場所に移動します。あなたはどこに移動させるかを尋ねられます。それってかっこいいでしょ?

永続記事
====

記事のキャッシュと近い関係にあるものに、永続記事 があります。実際それはキャッシュを見るための別の方法で、私に言わせればはるかに役に立ちます。

例えば、ニュースグループを読んでいて、永久に秘蔵しておく価値のある宝石に出会ったとしましょう。普通はそれをファイルに保存します (多くの保存命令の一つを使って)。問題は、単にあの、嫌なだけです。理想的には、記事はグループで見つけた場所に永遠に残っていることが好ましいでしょう。ニュースサーバーにおける期限切れ消去には影響されないで。

これが 永続記事 です---記事は削除されません。それは普通のキャッシュ命令を使って実装されていますが、永続記事の管理をするために二つの明示的な命令を使います:

*
     現在の記事を永続にします (gnus-cache-enter-article)。

M-*
     現在の記事を永続記事から取り除きます (gnus-cache-remove-articles)。これは普通は記事を削除します。

これらの命令は両方ともプロセス/接頭引数の習慣を理解します。

永続記事にだけ興味があるのなら、可視記事 (やその他のもの) がキャッシュに入るのを避けるために、gnus-use-cache を passive に設定するのが良いでしょう:

     (setq gnus-use-cache 'passive)

記事のバックログ
========

回線が遅いために、キャッシュを使うという発想があまり魅力的ではないとき (実際そうなのですが)、バックログ に切り替えることによって状況を何とかすることができます。これはすでに読んだ記事を再取得しなくても良いように、すでに読んだ記事を Gnus が一時保存しておくところです。これはもちろん、あなたに最近読んだ記事を再び選択する癖があるときだけ役立ちます。絶対にそれをしない人にとっては、バックログを on にすることは Gnus を少し遅くし、メモリーの使用量をいくらか増やすだけのことです。

gnus-keep-backlog を数値 N に設定すると、Gnus は最大で N 個の古い記事を後の再取得のためにバッファーに溜めておきます。この変数が nil ではなく、数値でもない場合、 Gnus は すべて の既読記事を蓄えます。それは Emacs が爆発するまで制限なく膨れ上がって、マシンがあなたもろとも落ちてしまうということです。私はみなさんがいつも注意を怠らないようにするために、ここに書き加えました。

ディフォルト値は 20 です。

記事の保存
=====

Gnus はたくさんの方法で記事を保存することができます。以下のものは非常に率直な方法 (すなわち記事が保存する前にほとんど何もなされない) で記事を保存するための説明です。異なる手続き (uudecode, unshar) のためには gnus-uu を使うのが良いでしょう (see Decoding Articles)。

ここに列挙されているコマンドは対象がファイルです。グループに保存したい場合は B c (gnus-summary-copy-article) コマンドを参照して下さい (see Mail Group Commands)。

gnus-save-all-headers が nil でないと、Gnus は記事を保存する前に不要なヘッダーを消去しません。

もし上記の変数が nil であると、正規表現 gnus-saved-headers に合致するすべてのヘッダーが残される一方、残りのものは保存する前に削除されます。

O o
o
     ディフォルトの記事を保存する手段を用いて現在の記事を保存します (gnus-summary-save-article)。

O m
     現在の記事をメールの様式で保存します (gnus-summary-save-article-mail)。

O r
     現在の記事を Rmail の様式で保存します (gnus-summary-save-article-rmail)。

O f
     現在の記事を普通のファイル (plain file) 様式で保存します (gnus-summary-save-article-file)。

O F
     現在の記事を普通のファイル様式で保存し、以前のファイルの内容を上書きします (gnus-summary-write-article-file)。

O b
     現在の記事の本文を普通のファイル様式で保存します (gnus-summary-save-article-body-file)。

O h
     現在の記事を mh のフォルダーの様式で保存します (gnus-summary-save-article-folder)。

O v
     現在の記事を VM フォルダーに保存します (gnus-summary-save-article-vm)。

O p
|
     現在の記事をパイプに保存します。うーんと、あのぉ、私が言おうとしていることは---現在の記事をプロセスにパイプするということです (gnus-summary-pipe-output)。シンボル接頭引数 (see Symbolic Prefixes) が与えられると、パイプへの出力に完全なヘッダーを含めます。

O P
     現在の記事を muttprint に保存します。つまり、外部プログラム Muttprint (http://muttprint.sourceforge.net/) を使って記事を印刷するということです。プログラム名と使用するオプションは、変数 gnus-summary-muttprint-program で指定されます。 (gnus-summary-muttprint)。

すべてのこれらの命令はプロセス/接頭引数の習慣を使います (see Process/Prefix)。もしこれらの関数を使ってたくさんの記事を保存した場合、それぞれのすべての記事に対してファイル名の入力を要求されることに飽き飽きするでしょう。入力を求める動作は変数 gnus-prompt-before-saving によって制御されます。これはディフォルトでは always で、あなたが嫌な思いを味わっている、過剰な入力要求をします。代わりにこの変数を t に設定すると、保存するそれぞれの一連の記事に対して一回だけ入力を要求します。本当に Gnus にすべての判断を任せてしまいたいのであれば、この変数を nil にすることさえできます。そうすれば、記事を保存するためのファイルを促されることはありません。 Gnus は単純にすべての記事をディフォルトのファイルに保存します。

Gnus を思い通りに動作させるために、変数 gnus-default-article-saver をカスタマイズすることができます。下の六つの既製の関数を使うことができるし、自分自身の関数を作ることもできます。

gnus-summary-save-in-rmail
     これがディフォルトで、Babyl という様式です。変数 gnus-ramil-save-name に設定されている関数を、記事を保存するファイルの名前を取得するために使います。ディフォルトは gnus-plain-save-name です。

gnus-summary-save-in-mail
     Unix メール (mbox) ファイルに保存します。変数 gnus-mail-save-name に設定されている関数を、記事を保存するファイルの名前を取得するために使います。ディフォルトは gnus-plain-save-name です。

gnus-summary-save-in-file
     記事を通常のファイルの後に追加します。変数 gnus-file-save-name に設定されている関数を、記事を保存するファイルの名前を取得するために使います。ディフォルトは gnus-numeric-save-name です。

gnus-summary-write-to-file
     記事をストレートに通常のファイルに保存します。そのファイルが存在していたら上書きされます。変数 gnus-file-save-name に設定されている関数を、記事を保存するファイルの名前を取得するために使います。ディフォルトは gnus-numeric-save-name です。

gnus-summary-save-body-in-file
     記事の本文を通常のファイルの後に追加します。変数 gnus-file-save-name に設定されている関数を、記事を保存するファイルの名前を取得するために使います。ディフォルトは gnus-numeric-save-name です。

gnus-summary-save-in-folder
     MH ライブラリーの rcvstore を使って、記事を MH フォルダーに保存します。変数 gnus-folder-save-name に設定されている関数を、記事を保存するファイルの名前を取得するために使います。ディフォルトは gnus-folder-save-name ですが、gnus-Folder-save-name も使うことができて、こちらは先頭が大文字、残りが小文字になった名前を作ります。

gnus-summary-save-in-vm
     記事を VM フォルダーに保存します。この設定を使うためには VM メールリーダーが必要です。

これらのすべての関数は最後の一つを除いて、環境変数 SAVEDIR によって初期化される gnus-article-save-directory に記事を保存します。これはディフォルトでは ~/News/ です。

上で述べたように、記事を保存するためのファイルの適切な名前を見つけるために、それらは違った関数を用います。以下は名前を生成するために使うことができる関数のリストです:

gnus-Numeric-save-name
     ~/News/Alt.andera-dworkin/45 のようなファイル名。

gnus-numeric-save-name
     ~/News/alt.andera-dworkin/45 のようなファイル名。

gnus-Plain-save-name
     ~/News/Alt.andera-dworkin のようなファイル名。

gnus-plain-save-name
     ~/News/alt.andera-dworkin のようなファイル名。

gnus-sender-save-name
     ~/News/larsi のようなファイル名。

連想リスト gnus-split-methods に正規表現を放り込むことによって、 Gnus に記事を保存する場所をほのめかすことができます。例えば Gnus に関連する記事を gnus-stuff ファイルに、VM に関連する記事を vm-stuff ファイルに保存したければ、この変数を以下のようにすれば良いでしょう:

     (("^Subject:.*gnus\\|^Newsgroups:.*gnus" "gnus-stuff")
      ("^Subject:.*vm\\|^Xref:.*vm" "vm-stuff")
      (my-choosing-function "../other-dir/my-stuff")
      ((equal gnus-newsgroup-name "mail.misc") "mail-stuff"))

これはそれぞれの要素が、二つの要素---合致 と ファイル を持つリストであるリストであるということがわかります。合致は文字列 (この場合は記事のヘッダーに合致する正規表現として使われます)、シンボル (グループ名を引数として、関数として呼ばれます) およびリスト (これは評価 (eval) されます) のどれかであることができます。これらの動作の一つでも nil でない結果を返すと、入力を求めるときのディフォルトとして ファイル が使われます。加えて、呼ばれた関数か式が文字列か文字列のリストを返したときは、演算の結果自体が使われます。

基本的には、現在の記事を保存するのに使われる可能性のあるファイル名のリストを手に入れることになります。(すべての『合致』が使われます。) そして、実際に名前として使いたいものの入力を促されますが、その際、この変数を適用して得られた結果が、ファイル名を補完するときの候補になります。

この変数はディフォルトでは ((gnus-article-archive-name)) で、これは Gnus が保存する記事の Archive-name 行を調べて、それをファイル名の候補として使います。

これはファイル名を多少きれいにする関数の例です。 nnml:mail.whatever のようなメールグループがたくさんあるとすると、保存するためのファイル名を作る前にそれらのグループ名の最初の方を切り落とす必要があるかもしれません。次の物はまさにそれをします:

     (defun my-save-name (group)
       (when (string-match "^nnml:mail." group)
         (substring group (match-end 0))))

     (setq gnus-split-methods
           '((gnus-article-archive-name)
             (my-save-name)))

最後に、gnus-use-long-file-name という変数があります。これが nil であると、すべての上記の関数はグループ名のすべてのピリオド (.) をスラッシュ (/) で置き換えます---つまり、すべてのファイルを一番上のディレクトリーに置くのではなく、それらの関数が階層的なディレクトリーを生成するということです (~/News/alt.andrea-dworkin ではなく ~/News/alt/andrea-dworkin のように)。たいていのシステムにおいて、この変数のディフォルト値は t です。しかし、歴史的な理由によって Xenix と usg-unix-v マシンでは nil がディフォルト値になります。

この関数は削除とスコアのファイル名にも影響します。この変数がリストで、そのリストが not-score という要素を含んでいると、長いファイル名はスコアファイルには使われません。そのリストが not-save という要素を含んでいると、保存するときに長いファイル名は使われません。また、そのリストが not-kill という要素を含んでいると、長いファイル名は削除ファイルには使われません。

記事をスプールのような階層に保存したい場合は、次のようにして下さい。

     (setq gnus-use-long-file-name '(not-save)) ; 階層にする
     (setq gnus-default-article-saver
           'gnus-summary-save-in-file) ; エンコードしない

そうしたならば、o で記事を保存するだけです。すると、階層を nneething 一時グループによって読むことができます---グループバッファーで G D をタイプして、一番上のディレクトリー (~/News/) を引数として渡して下さい。

記事のデコード
=======

ときどき利用者は何らかの方法でエンコードされた記事 (もしくは一連の記事群) を投稿します。Gnus はそれらをデコードすることができます。

     訳注: この章では、複数に分割して送信された一つの巨大な記事を、再び一つにまとめ上げてデコードする処理について説明しています。現在では、そのような分割送信をメールサーバーが受け付けない等の理由によって、ほとんど目にすることはありません。分割して送信しないことを確実にするには、以下の設定を行なって下さい (see メール変数 (The Message Manual)):

          (setq message-send-mail-partially-limit nil)

これらすべての関数はプロセス/接頭引数の習慣 (see Process/Prefix) を、『一つの記事』を『一つの群』と解釈する拡張をして、どの記事に操作をするかを見つけるために使います。Gnus は自分自身でどの記事がその群に属しているかを判断し、すべての記事をデコードして、その結果のファイルを展開/表示/保存することができます。

Gnus は以下の簡単な規則に則ってどの記事が群に属するのかを推測します: 表題は行の最後の二つの数字を除いて (ほとんど) 同じである必要があります。 (空白は大体無視されますが。)

例えば: cat.gif (2/3) というような表題を選ぶと、Gnus は正規表現 ^cat.gif ([0-9]+/[0-9]+).*$ に合致するすべての記事を見つけようとします。

cat.gif (2/3) Part 6 of a series のような標準でない表題はどの自動表示命令によっても適切に認識されないため、手で記事に # の印を付けなければなりません。

uuencode された記事
--------------

X u
     現在の群を uudecode します (gnus-uu-decode-uu)。

X U
     現在の群を uudecode して保存します (gnus-uu-decode-uu-and-save)。

X v u
     現在の群を uudecode して、表示します (gnus-uu-decode-uu-view)。

X v U
     現在の記事を uudecode して、表示して保存します (gnus-uu-decode-uu-and-save-view)。

これらはすべて、プロセス印が付けられた記事に対して反応するということを覚えておいて下さい。例えばニュースグループ全体をデコードして保存したいのであれば、例によって M P a (gnus-uu-mark-all) に続いて X U (gnus-uu-decode-uu-and-save) を実行して下さい。

このすべては、白日の下にいちいちキーを打っていた GNUS 4.1 のときの gnus-uu の動作とはまったく違っています。一般にこの版の gnus-uu は、何かの方法 (see Setting Process Marks) で記事に印を付け、それから X u を押すことを前提としています。

注意: 定数 gnus-uu-notify-files (値が [Cc][Ii][Nn][Dd][Yy][0-9]+.\\(gif\\|jpg\\) にハードコードされています) に合致する名前を持つ記事をデコードしようとすると、あなたが問題の記事を今まさに見たことをバラすために、gnus-uu は自動的に comp.unix.wizards に記事を投稿します。この機能を使わないようにすることはできません (訳注: そんな Cindy Crawford 嬢の写真がニュースで大量に流れていた、まだ WWW がロクに普及していなかった時代の産物です)。

シェルアーカイブ
--------

シェルアーカイブ (『shar ファイル』) はソースを配布するための人気のある方法でしたが、今日ではそんなに使われていません。とにかくこれらを扱うための命令があります:

X s
     現在の群を解凍します (gnus-uu-decode-unshar)。

X S
     現在の群を解凍して保存します (gnus-uu-decode-unshar-and-save)。

X v s
     現在の群を解凍して表示します (gnus-uu-decode-unshar-view)。

X v S
     現在の群を解凍し、表示して保存します (gnus-uu-decode-unshar-and-save-view)。

ポストスクリプトファイル
------------

X p
     現在のポストスクリプト群を展開します (gnus-uu-decode-postscript)。

X P
     現在のポストスクリプト群を展開して保存します (gnus-uu-decode-postscript-and-save)。

X v p
     現在のポストスクリプト群を表示します (gnus-uu-decode-postscript-view)。

X v P
     現在のポストスクリプト群を表示して保存します (gnus-uu-decode-postscript-and-save-view)。

他のファイル
------

X o
     現在の群を保存します (gnus-uu-decode-save)。

X b
     現在の記事を binhex で解凍します (gnus-uu-decode-binhex)。これは実際には動作しません。

デコードのための変数
----------

形容詞です。動詞ではありません。

規則変数
....

Gnus はファイルをどうやって表示するかを決めるために 規則変数 を使います。これらの変数はすべて以下のような様式です。

           (list '(regexp1 command2)
                 '(regexp2 command2)
                 ...)

gnus-uu-user-view-rules
     この変数はファイルを表示するときに最初に調べられます。例えば、もし .au 音響ファイルを変換するために sox を使いたいときは、次のように設定することができます:

          (setq gnus-uu-user-view-rules
                (list '("\\\\.au$\" "sox %s -t .aiff > /dev/audio")))

gnus-uu-user-view-rules-end
     この変数は Gnus が利用者とディフォルトの表示規則から合致するものを見つけることができなかったときに調べられます。

gnus-uu-user-archive-rules
     この変数はアーカイブを展開するときにどの命令が使われるべきかを決めるために使うことができます。

他のデコードのための変数
............

gnus-uu-grabbed-file-functions
     これは関数のリストです。すぐにファイルを移動したり表示することを可能にし、何かができるようになる前にすべてのファイルがデコードされるのを待つ必要が無いように、それぞれのファイルのデコードに成功した直後にそれらの関数が呼ばれます。このリストに入れることができる既製の関数は以下の通りです:

     gnus-uu-grab-view
          ファイルを表示します。

     gnus-uu-grab-move
          ファイルを移動します (もし保存関数を使っているのであれば)。

gnus-uu-be-dangerous
     デコードの最中に異常な状況が起こったときに何をするかを指定します。もし nil であると、できるだけ保守的になります。もし t であると、動作しないものは無視して、現存するファイルを上書きします。その他の場合は、それぞれのときに尋ねます。

gnus-uu-ignore-files-by-name
     この正規表現に合致する名前のファイルは表示されません。

gnus-uu-ignore-files-by-type
     この変数に合致する MIME の型を持つファイルは表示されません。 Gnus はファイル名に基づいて型を推測していることに注意して下さい。 gnus-uu は (まだ) MIME パッケージではないので、これは少々お行儀が悪いものです。

gnus-uu-tmp-dir
     gnus-uu がその仕事をする場所です。

gnus-uu-do-not-unpack-archives
     nil でないと、gnus-uu は表示するためのファイルを探すためにアーカイブの中身までは見ません。

gnus-uu-view-and-save
     nil でないと、利用者はファイルを表示した後で常に保存するかどうかを尋ねられます。

gnus-uu-ignore-default-view-rules
     nil でないと、gnus-uu はディフォルトの表示規則を無視します。

gnus-uu-ignore-default-archive-rules
     nil でないと、gnus-uu はディフォルトのアーカイブ展開命令を無視します。

gnus-uu-kill-carriage-return
     nil でないと、gnus-uu は記事からすべてのキャリッジリターンを取り去ります。

gnus-uu-unmark-articles-not-decoded
     nil でないと、gnus-uu はデコードに失敗した記事に未読の印を付けます。

gnus-uu-correct-stripped-uucode
     nil でないと、gnus-uu は後続の空白が削除されてしまっている uuencode されたファイルを修復しようと 試み ます。

gnus-uu-pre-uudecode-hook
     メッセージを uudecode に送る前に実行されるフックです。

gnus-uu-view-with-metamail
     nil でないと、gnus-uu は規則変数で定義された表示命令を無視して、ファイル名に基づいた MIME Content-Type をでっちあげます。その結果は表示のために metamail にかけられます。

gnus-uu-save-in-digest
     nil でないと、デコードせずに保存することを指示されたときに、 gnus-uu は要約 (digest) を保存します。この変数が nil であると、gnus-uu は何も加工を施さずにすべてを一つのファイルに保存します。要約の作成は概ね RFC1153 に準拠していますが、意味のある目次を付ける簡単な方法が見つからなかったので、私はそれらを単に落としました。

uuencode と投稿
............

gnus-uu-post-include-before-composing
     nil でないと、gnus-uu は記事を作成する前にエンコードするファイルを尋ねます。この変数が t であると、C-c C-i によってエンコードされたファイルを取り込むか、記事を投稿するときに取り込むかのどちらかをすることができます。

gnus-uu-post-length
     記事の最大の長さです。エンコードされたファイルは全体のファイルを投稿するのに必要な量のファイルに分割されます。

gnus-uu-post-threaded
     nil でないと、gnus-uu はエンコードされたファイルをスレッドで投稿します。これはあまり賢い方法ではないかもしれません。というのは、今まで私が見た中で uuencode された記事を集めるのに、スレッドを追っていくことのできる他のデコーダーが存在しないからです。(えーと、私はそれをする一つのパッケージを見たことがあります---gnus-uu です。しかしどうも、それが数のうちに入るとは思えないのです...) ディフォルトは nil です。

gnus-uu-post-separate-description
     nil でないと、説明文は別の記事で投稿されます。最初の記事は普通 (0/x) のように番号が付けられます。もしこの変数が nil であると、利用者の書いた説明分は最初のファイルの始めに取り込まれ、(1/x) の番号が付けられます。ディフォルトは t です。

ファイルの表示
-------

デコードした後でファイルが何らかのアーカイブである場合、Gnus はアーカイブを展開しようと試み、アーカイブの中に表示できるファイルがあるかどうかを調べます。例えば、gzip された tar ファイル pics.tar.gz があって、ファイル pic1.jpg と pic2.gif を含んでいる場合、Gnus は主ファイルを解凍して tar を展開し、それから二つの絵を表示します。この展開の過程は再帰的なので、アーカイブにアーカイブのアーカイブがあると、それはすべて展開されます。

最後に、Gnus は普通はそれぞれの抽出された記事ごとに 疑似記事 を概略バッファーに挿入します。これらの『記事』に移動した場合は、実行する命令 (普通は Gnus が提案をします) を入力するように促され、それからその命令が実行されます。

gnus-view-pseudo-asynchronously が nil であると、Emacs は先へ進む前に表示の終了を待ちます。

gnus-view-pseudos が automatic であると、Gnus は概略バッファーに疑似記事を挿入せず、それらをすぐに表示します。この変数が not-confirm であると、利用者は表示が済む前に確認さえも求められません。

gnus-view-pseudos-separately が nil でないと、表示されるそれぞれのファイルにつき一つの疑似記事が作成されます。nil であると、同じ表示命令を使うすべての命令がその命令の引数のリストとして渡されます。

gnus-insert-pseudo-articles が nil でないと、デコードのときに疑似記事を挿入します。ディフォルトでは t です。

さて、あなたはそんなふうに 仮想サーバー の 仮想グループ にある 疑似記事 を読むことになるわけです。どうしてすべてが現実ではなくなってしまったんでしょうか?  どうしてこんなところに来てしまったんでしょうか?

記事のトリートメント
==========

この巨大な説明文書を読んできて、人々の著作を読むことがニュースリーダーの本当の目的だったことを、すっかり忘れてしまったかもしれません。記事を読むことです。残念ながら人々は書くことがとても苦手ですが、記事を読みやすくするための関数と変数は山のようにあります。

記事のハイライト
--------

記事バッファーをフルーツサラダのように、いや総天然色のフルーツサラダのようにしたくありませんか。

W H a
     現在の記事をもっとハイライトします。この関数は、ヘッダー、引用文、署名をハイライトし、本文とヘッダーにボタンを加えます。

W H h
     ヘッダーをハイライトします (gnus-article-highlight-headers)。ハイライトは変数 gnus-header-face-alist に従って行なわれ、それはそれぞれの要素が (正規表現 名前 内容) という様式のリストです。正規表現 はヘッダーに合致する正規表現、名前 はヘッダーの名前をハイライトするのに使われるフェース (see Faces and Fonts)、内容 はヘッダーの値をハイライトするフェースです。最初に合致したものが使われます。正規表現 の先頭に ^ を付けてはいけないことに注意して下さい---Gnus がそれを付け加えます。

W H c
     引用された文をハイライトします (gnus-article-highlight-citation)。

     引用文のハイライトをカスタマイズする変数は次の通りです:

     gnus-cite-parse-max-size
          記事の大きさがこの変数 (ディフォルトでは 25000) より大きい記事は、引用文のハイライトが行なわれません。

     gnus-cite-max-prefix
          引用符の最大の長さです (ディフォルトでは 20 です)。

     gnus-cite-face-list
          引用文をハイライトするために使われるフェースのリストです (see Faces and Fonts)。同じメッセージの中に複数の記事からの引用があると、Gnus はそれぞれの記事からの引用をそれ用のフェースで表示しようとします。これにより、誰が何を書いたかが分かりやすくなるでしょう。

     gnus-supercite-regexp
          普通の Supercite 著者行に合致する正規表現です。

     gnus-supercite-secondary-regexp
          引き裂かれた Supercite 著者行に合致する正規表現です。

     gnus-cite-minimum-match-count
          それが引用文であると判定する前に調べなければならない引用符の最小の数です。

     gnus-cite-attribution-prefix
          著者行の始まりに合致する正規表現です。

     gnus-cite-attribution-suffix
          著者行の終りに合致する正規表現です。

     gnus-cite-attribution-face
          著者行に使われるフェースです。その著者が書いた文の引用のためのフェースと融合されます。

     gnus-cite-ignore-quoted-from
          非-nil だったら、>From  で始まる行で引用文のハイライトは行なわれません。それらの行は、エンベロープ From 行と混同しないように、 MTA がクオートした可能性があります。ディフォルト値は t です。

W H s
     署名 (signature) をハイライトします (gnus-article-highlight-signature)。 gnus-signature-separator (see Article Signature) の後のすべてのものは署名であると解釈され、gnus-signature-face でハイライトされます。それはディフォルトでは italic です。

記事を自動的にハイライトする方法については Customizing Articles を参照して下さい。

記事中の文の強調表示
----------

(訳注: Fontisize == Fontify + Emphasize)

人々はよくニュースの記事で _これ_ や *これ* または /これ/ のようなものを使って単語を強調します。Gnus は記事を W e 命令 (gnus-article-emphasize) にかけることによって素敵に見えるようにできます。

強調がどのように処理されるかは変数 gnus-emphasis-alist によって制御されます。これは連想リストで、最初の要素は合致するべき正規表現です。二番目の要素は、正規表現の中のどのグループが強調語全体を見つけるために使われるかを示す数値です。三番目は正規表現のどのグループが表示されハイライトされるかを決める数値です。(この二つのグループの間にあるテキストは隠されます。) 四番目はハイライトさせるためののフェースです。

     (setq gnus-emphasis-alist
           '(("_\\(\\w+\\)_" 0 1 gnus-emphasis-underline)
             ("\\*\\(\\w+\\)\\*" 0 1 gnus-emphasis-bold)))

(訳注: 上記の変数の値は、ディフォルトのままにしておくのが無難です。)

ディフォルトでは七つの規則があり、それらは以下のフェースを用います:

gnus-emphasis-bold, gnus-emphasis-italic, gnus-emphasis-underline, gnus-emphasis-bold-italic, gnus-emphasis-underline-italic, gnus-emphasis-underline-bold, gnus-emphasis-underline-bold-italic。

これらのフェースを変更したいのであれば、 M-x customize か copy-face を使うことができます。例えば gnus-emphasis-italic が代わりに赤のフェースを使うようにしたいのならば、次のようにすれば良いでしょう:

     (copy-face 'red 'gnus-emphasis-italic)

任意の語を強調表示させたいときは、 gnus-group-highlight-words-alist 変数を使うことができます。これは gnus-emphasis-alist と同じ構文を使います。 highlight-words グループパラメーター (see Group Parameters) を使うこともできます。

記事を自動的に強調表示させるやり方については Customizing Articles を参照して下さい。

記事を隠す
-----

と言うよりはむしろ、記事の中にある特定のものを隠すことです。たいていの記事には、普通はありすぎるくらいのごみがあります。

W W a
     記事バッファーでたくさんのものを隠します (gnus-article-hide)。特にこの関数はヘッダー、PGP、引用文、それに署名を隠します。

W W h
     ヘッダーを隠します (gnus-article-hide-headers)。 See Hiding Headers.

W W b
     あまり興味の持てないヘッダーを隠します (gnus-article-hide-boring-headers)。See Hiding Headers.

W W s
     署名を隠します (gnus-article-hide-signature)。 See Article Signature.

W W l
     gnus-list-identifiers で指定されているメーリングリストの標識を削除します。これらはいくつかのメーリングリストのサーバーがすべての Subject ヘッダーの最初に付ける文字列、例えば [zebra 4711] のようなものです。文字列の初めにある Re:  は、削除を行なう前に跳び越されます。 gnus-list-identifiers に \\(..\\) を含めてはいけません。

     gnus-list-identifiers
          表題から削除されるべきメーリングリストの標識に合致する正規表現です。これは正規表現のリストであることもできます。

W W P
     不要な PEM (privacy enhanced messages (プライバシー拡張メッセージ)) の部分を隠します (gnus-article-hide-pem)。

W W B
     banner グループパラメーターで指定されたバナーを取り除きます (gnus-article-strip-banner)。これは主に、いくつかのメーリングリストや司会者付きのグループがすべての記事に追加する、欝陶しいバナーと/ もしくは署名を隠すために使用されます。この関数を使う方法は banner グループパラメーター (see Group Parameters) をバナーを取り除きたいグループに追加することです。パラメーターは、消去されるテキストに合致する正規表現として解釈される文字列か、(最後の) 署名を消去するためのシンボル signature、または gnus-article-banner-alist の正規表現に対応した他のシンボルのいずれかであることができます。

     グループにかかわらず、記事の送信者が gnus-article-address-banner-alist で設定されている特定のメールアドレスを持っているときだけ、広告のようなものを隠すことができます。

     gnus-article-address-banner-alist
          メールアドレスとバナーの連想リストです。それぞれの要素は (ADDRESS . BANNER) の形式を持ち、ここで ADDRESS は From ヘッダーにあるメールアドレスに合致する正規表現です。また、BANNER はシンボル signature、 gnus-article-banner-alist の要素、正規表現または nil のうちの一つです。ADDRESS が著者のメールアドレスに合致すると、広告のようなものを消します。例えば、送信者が hail@yoo-hoo.co.jp というメールアドレスを持っていて、彼が送信するすべての記事に Do You Yoo-hoo!? のようなものがある場合、以下の要素でそれらを消すことができます。

               ("@yoo-hoo\\.co\\.jp\\'" . "\n_+\nDo You Yoo-hoo!\\?\n.*\n.*\n")

W W c
     引用文を隠します (gnus-article-hide-citation)。隠蔽をカスタマイズするいくつかの変数は:

     gnus-cited-opened-text-button-line-format
     gnus-cited-closed-text-button-line-format
          Gnus はどこの引用文が隠されているかを示すためにボタンを付け加え、文章の隠蔽を切り替えられるようにします。この変数の様式は、以下のフォーマットのような変数によって指定されます (see Formatting Variables)。次の指定が有効です:

          b
               隠された文の最初のポイントです。

          e
               隠された文の最後のポイントです。

          l
               隠されたリージョンの文字の数です。

          n
               隠された文の行の数です。

     gnus-cited-lines-visible
          隠さずに表示しておく、引用文の先頭からの行数です。これは、隠さずに表示する先頭からの行と、隠さずに表示する末尾からの行の、それぞれの数の cons セルであることもできます。

W W C-c
     以下の二つの変数に依存して、引用文を隠します (gnus-article-hide-citation-maybe):

     gnus-cite-hide-percentage
          引用文の割合のパーセンテージが、この変数 (ディフォルト値は 50) より大きかったら、引用文を隠します。

     gnus-cite-hide-absolute
          隠される前に、引用文は少なくともこの長さ (ディフォルト値は 10) でなければまりません。

W W C
     根本でない記事の引用文を隠します (gnus-article-hide-citation-in-followups)。これは対話的命令としてはあまり役に立たないかもしれませんが、自動的に実行させるには手軽な関数でしょう (see Customizing Articles)。

これらのすべての『隠蔽』命令は切り替え命令ですが、これらの命令に負の接頭引数を与えると、それらは前に隠されていたものを表示します。正の接頭引数を与えれば、それらは常に隠します。

引用文をカスタマイズするためのさらなる変数について、 Article Highlighting も参照して下さい。

自動的に記事の要素を隠すための方法は Customizing Articles を参照して下さい。

記事の洗濯
-----

私たちはこれをもっともな理由の下で『記事の洗濯』(article washing) と呼んでいます。A キーは使われていたので、代わりに W キーを使う必要がありました。

洗濯 は『何かの何かを何か別のものに変換する』と定義されますが、普通はもっと良く見える何かに落ち着きます。もっときれいになります、たぶん。

Gnus が記事を表示するディフォルトのやり方を変えたいときは Customizing Articles を参照して下さい。

C-u g
     これは洗濯ではなくて、その逆です。これをタイプすると、ディスクやサーバーにあるがままの記事が見えます。

g
     現在の記事の再表示を強制します (gnus-summary-show-article)。これもまた本当の洗濯ではありません。これをタイプすると、以前に適用された対話的な洗濯機能はご破算にされ、すべてのディフォルトのトリートメントを施された記事が表示されます (see Customizing Articles)。

W l
     ページの区切りを現在の記事から取り除きます (gnus-summary-stop-page-breaking)。ページの区切りに付いては Misc Article を参照して下さい。

W r
     記事バッファーでカエサル変換 (Caesar rotate, rot13) を行ないます (gnus-summary-caesar-message)。カエサル変換か rot13 を用いて読むことを指定する、判読不可能な記事です (典型的には攻撃的な冗談などです。)

     普通は ``rot13'' と呼ばれています。それはアルファベットの位置が 13 個回転するからです。例えば、B (2 番目の文字) → O (15 番目の文字)。これは時々『カエサル変換』と呼ばれることもあります。というのは、カエサルがこの形式の、えーと、いささか貧弱な暗号化を採用したという噂があるからです。

W m
     記事バッファーをモールスでデコードします (gnus-summary-morse-message)。

W i
     現在の記事にある IDNA エンコードされたドメイン名をデコードします。 IDNA エンコードされたドメイン名は xn--bar のように見えます。これを実行した後で文字列がデコードされないままだったら、おそらくそれは不正な IDNA 文字列でしょう (xn--bar は不正です)。このコマンドを動かすためには、GNU Libidn (http://www.gnu.org/software/libidn/) をインストールしていなければなりません。

W t

t
     記事バッファーにすべてのヘッダーを表示するかどうかを切り替えます (gnus-summary-toggle-header)。

W v
     記事バッファーにすべてのヘッダーを永続的に表示するかどうかを切り替えます (gnus-summary-verbose-headers)。

W o
     オーバーストライクを処理します (gnus-article-treat-overstrike)。

     訳注: 以下のような重ね打ちを指示する文字列を bold や underline で表示します。

     B^HBo^Hol^Hld^Hd, U^H_n^H_d^H_e^H_r^H_l^H_i^H_n^H_e^H_

W d
     gnus-article-dumbquotes-map に応じて、マ■■■ソ■ ■ sm*rtq**t*s を処理します。この関数は文字が sm*rtq**t* かどうかを推測するので、対話的にのみ使用されるべきであることに注意して下さい。

     Sm*rtq**t*s はもっと多くの引用文字を提供するために、マ■■■ソ■■が勝手に文字マップを拡張したものです。もし、アポストロフィ (') や引用記号 (") などがあるべきところに \222 や \264 のようなものが見えてしまったら、洗濯してみて下さい。

W Y f
     いかれた Outlook (Express) の記事を完全に醜くなくすること (訳注: de-ugly-fy) (sm*rtq**t*s を処理、行の折り返しを解除、著者行の修復と引用文の整頓) をします。 (gnus-article-outlook-deuglify-article)。

W Y u
     折り返された引用行のように見える行の折り返しを解きます。折り返しが解かれた行の最小および最大の長さを表す gnus-outlook-deuglify-unwrap-min および gnus-outlook-deuglify-unwrap-max を調整することによって、どんな行の折り返しが解かれるかを制御することができます。 (gnus-article-outlook-unwrap-lines)。

W Y a
     壊れた著者行を修復します。

     (gnus-article-outlook-repair-attribution)。

W Y c
     壊れた引用文を、テキストを整理し直すことによって修復します。 (gnus-article-outlook-rearrange-citation)。

W w
     行を折り返します (gnus-article-fill-cited-articles)。

     折り返す幅を指定するために、命令に数値接頭引数を与えることができます。

W Q
     長い行を折り返します (gnus-article-fill-mode-lines)。

W C
     それぞれの文の最初の語を大文字にします (gnus-article-capitalize-sentences)。

W c
     CRLF の組 (すなわち、行の最後の ^M) を LF に変換します (これは DOS の行末の世話をします)。そうしてから残りの CR を LF に変換します (これは MAC の行末の世話をします) (gnus-article-remove-cr)。

     Quoted-printable を処理します (gnus-article-de-quoted-unreadable)。 Quoted-Printable は 非-ASCII (すなわち 8-bit) の記事を送るときに使われる一般的な MIME エンコーディングです。それは概して d,Aij,A` vu のようなものを d=E9j=E0 vu に見せるので、とても読み辛くなります。問題の記事が、そのエンコーディングが行なわれたことを示す Content-Transfer-Encoding ヘッダーを持っていれば、通常それは Gnus によって自動的に行なわれることに注意して下さい。接頭引数が与えられると、文字セットが尋ねられます。

W 6
     Base64 をデコードします (gnus-article-de-base64-unreadable)。 Base64 は非-ASCII (すなわち 8-bit) の記事を送るときに使われる、一般的な MIME エンコーディングです。問題の記事が、そのエンコーディングが行なわれたことを示す Content-Transfer-Encoding ヘッダーを持っていれば、通常それは Gnus によって自動的に行なわれることに注意して下さい。接頭引数が与えられると、文字セットが尋ねられます。

W Z
     HZ または HZP を処理します。HZ (または HZP) は中国語の記事を伝送するときに使われる一般的な符号です。これは ~{<:Ky2;S{#,NpJ)l6HK!#~} のような典型的な文字列を作ります。

W A
     ANSI SGR シーケンスを overlay または extent に変換します (gnus-article-treat-ansi-sequences)。ANSI シーケンスは中国語のニュースグループで強調表示に使われています。

W u
     URL に含まれる改行を削除します。いくつかのメイラーは、行を短くするために出ていくメールに改行を挿入しますが、これは長い URL を複数の行に分割してしまいます。改行を削除することによって、それらの URL を復旧させます (gnus-article-unsplit-urls)。

W h
     HTML を処理します。当該メッセージが HTML であることを示す Content-Type ヘッダーを持っていたならば、それは Gnus によって自動的に行なわれることに注意して下さい。

     接頭引数が与えられると、文字セットを尋ねられます。

     ディフォルトでは HTML の変換に mm-text-html-renderer (see 表示のカスタマイズ (The Emacs MIME Manual)) で設定された関数を使いますが、変数 gnus-article-wash-function が設定されていると、記事の洗濯ではそれが優先されます。使うことができる、あらかじめ用意された関数は以下の通りです:

     w3
          Emacs/W3 を使います。

     w3m
          emacs-w3m (http://emacs-w3m.namazu.org/) を使います。

     links
          Links (http://links.sf.net/) を使います。

     lynx
          Lynx (http://lynx.isc.org/) を使います。

     html2text
          html2text (シンプルな HTML コンバーターで、Gnus に含まれています) を使います。

     訳注: 例えば mm-text-html-renderer を w3m などに設定してあって正しく動作するのならば、gnus-article-wash-function はディフォルトの nil のままにしておいて構いません。

W b
     クリックできるボタンを記事に加えます (gnus-article-add-buttons)。 See Article Buttons.

W B
     クリックできるボタンを記事のヘッダーに加えます (gnus-article-add-buttons-to-head)。

W p
     署名付きコントロールメッセージの認証を行ないます (gnus-article-verify-x-pgp-sig)。 newgroup や checkgroups といったコントロールメッセージは、通常そのニュースグループ階層のメインテイナーによって署名されています。認証を行なうためには、メインテイナーの PGP 公開鍵をあなたのキーリングに追加しなければなりません。 (多くのニュースグループ階層のメインテイナーの PGP の鍵は ftp://ftp.isc.org/pub/pgpcontrol/README.html から入手することができます。)

W s
     署名されたメッセージ (PGP, PGP/MIME または S/MIME によって) を検証します (gnus-summary-force-verify-and-decrypt)。See Security.

W a
     記事の本文の先頭から X-No-Archive ヘッダーのようなヘッダーを取り除きます (gnus-article-strip-headers-in-body)。

W E l
     記事の先頭にあるすべての空白行を取り除きます (gnus-article-strip-leading-blank-lines)。

W E m
     すべての空白行を空行で置き換えてから、すべての複数の空行を一つの空行で置き換えます (gnus-article-strip-multiple-blank-lines)。

W E t
     記事の最後にあるすべての空白行を取り除きます (gnus-article-remove-trailing-blank-lines)。

W E a
     上の三つの命令をすべて実行します (gnus-article-strip-blank-lines)。

W E A
     すべての空白行を取り除きます (gnus-article-strip-all-blank-lines)。

W E s
     記事の本文のすべての行頭にあるすべての空白を取り除きます (gnus-article-strip-leading-space)。

W E e
     記事の本文のすべての行末にあるすべての空白を取り除きます (gnus-article-strip-trailing-space)。

自動的に記事の洗濯を行なわせる方法は Customizing Articles を参照して下さい (訳注: 実は多くの洗濯がディフォルトで自動的に行なわれます)。

記事ヘッダー
------

これらのコマンドは記事ヘッダーをいろいろに変形させます。

W G u
     折り返されたヘッダー行を一行にします (gnus-article-treat-unfold-headers)。

W G n
     Newsgroups と Followup-To ヘッダーを折り返します (gnus-article-treat-fold-newsgroups)。

W G f
     すべてのメッセージヘッダーを折り返します (gnus-article-treat-fold-headers)。

W E w
     すべてのヘッダーから余分な空白を取り除きます (gnus-article-remove-leading-whitespace)。

記事のボタン
------

人々はよく記事の中に他の資料を参照するための案内を入れることがありますが、それらの参照への案内の上で RET を打つか、マウスの真中のボタンを使ったときに、彼らが話題にしているのが何であれ、最小限の曖昧さで Gnus が取得することができれば素敵でしょう。

特定の標準的な参照に、Gnus はディフォルトで ボタン を付けます: ちゃんとした URL、メールアドレス、Message-ID、Info へのリンク、man ページ、それに関連する Emacs または Gnus の参考文献です。これは二つの変数によって制御されていて、その一つは記事の本文を扱い、もう一つは記事のヘッダーを扱います。

gnus-button-alist
     それぞれの要素が次のような様式を持つ連想リストです:

          (REGEXP BUTTON-PAR USE-P FUNCTION DATA-PAR)

     regexp
          この正規表現 (大文字と小文字は区別されません) に合致するすべてのテキストは、外部への参照であるとみなされます。これは埋め込まれた URL に合致する典型的な正規表現です: <URL:\\([^\n\r>]*\\)>。これはまた正規表現の値を持つ変数であってもよく、有用な変数として gnus-button-url-regexp および gnus-button-mid-or-mail-regexp があります。

     button-par
          Gnus は合致したもののどの部分がハイライトされるのかを知らなければなりません。これは正規表現のどの副表現がハイライトされるかを指定する番号です。すべてをハイライトしたいのなら、ここで 0 を使って下さい。

     use-p
          この式は 評価 され、結果が nil でなかったら、これは合致であるとみなされます。これは間違った合致を避けるために特別な選別をしたいときに役に立ちます。ここではしばしば gnus-button-*-level のような名前の変数が使われますが、see Article Button Levels, 他のどんな形式でも使うことができます。

     function
          この関数が、このボタンをクリックしたときに呼ばれます。

     data-par
          BUTTON-PAR のように、これは部分表現の番号ですが、これは合致のどの部分が FUNCTION にデータとして送られるかを指定します。

     したがって URL をボタンにする完全な要素は、こうなります。

          ("<URL:\\([^\n\r>]*\\)>" 0 t gnus-button-url 1)

gnus-header-button-alist
     これは他の連想リストと同じようなものですが、記事のヘッダーだけに適用されることと、それぞれの項目がどのヘッダーにボタンを付けるかを指示するための追加の要素を持っていることが異なります:

          (HEADER REGEXP BUTTON-PAR USE-P FUNCTION DATA-PAR)

     HEADER は正規表現です。

関連する変数と関数
.........

gnus-button-*-level
     Article Button Levels を参照して下さい。

gnus-button-url-regexp
     埋め込まれた URL に合致する正規表現です。上述の変数のディフォルトの値で使われます。

gnus-button-man-handler
     Man ページの表示に使う関数です。少なくとも一つの引数として Man ページの名前の文字列を受け付けなければなりません。

gnus-button-mid-or-mail-regexp
     Message-ID かメールアドレスに合致する正規表現です。

gnus-button-prefer-mid-or-mail
     この変数は foo123@bar.invalid のような文字列のボタンが押されたときに、何を行なうかを決める変数です。このような文字列は Message-ID かメールアドレスのいずれかです。もし mid か mail というシンボルのうちの一つだったら、Gnus は常にそれぞれ文字列が Message-ID またはメールアドレスであると仮定します。この変数が ask というシンボルに設定されると、Gnus はいつも利用者が何をしたいかを尋ねます。それが関数だった場合、たった一つの文字列を引数として呼ばれます。その関数は mid、 mail、invalid または ask を返さなければなりません。ディフォルト値は関数 gnus-button-mid-or-mail-heuristic です。

gnus-button-mid-or-mail-heuristic
     その引数が Message-ID かメールアドレスであるかを推定する関数です。 Message-ID だったら mid を、メールアドレスだったら mail を、不確かだったら ask を、そして無効な文字列だったら invalid を返します。

gnus-button-mid-or-mail-heuristic-alist
     関数 gnus-button-mid-or-mail-heuristic で使われる (RATE . REGEXP) 対の連想リストです。

gnus-button-ctan-handler
     CTAN リンクの表示に使う関数です。URL 名の文字列を、引数として一つ受け付けなければなりません。

gnus-ctan-url
     gnus-button-ctan-handler で使われる CTAN (Comprehensive TeX Archive Network) アーカイブのディレクトリーです。

gnus-article-button-face
     ボタンに使われるフェースです。

gnus-article-mouse-face
     マウスのカーソルがボタンの上にあるときに使われるフェースです。

記事に自動的にボタンを付ける方法は、Customizing Articles を参照して下さい。

Article button levels
---------------------

変数 gnus-button-*-level の値が高いほど、より多くのボタンが現れます。レベルがゼロだったらボタンは表示されません。ディフォルト値 (それは 5) では、とてもたくさんのボタンをすでに見ているはずです。高いレベルではより多くのボタンを見ることになりますが、多くの要らないものも現れるかもしれません。それらを避けるために、特定のグループに対して変数 gnus-button-*-level を設定しても良いでしょう (see Group Parameters)。gnus-parameters 変数の例です:

     ;; いくつかのグループで gnus-button-*-level を増やす:
     (setq gnus-parameters
           '(("\\<\\(emacs\\|gnus\\)\\>" (gnus-button-emacs-level 10))
             ("\\<unix\\>"               (gnus-button-man-level 10))
             ("\\<tex\\>"                (gnus-button-tex-level 10))))

gnus-button-browse-level
     Message-ID、メールアドレスおよびニュースの URL を参照する案内の表示を制御します。関連する変数と関数には gnus-button-url-regexp、 browse-url および browse-url-browser-function があります。

gnus-button-emacs-level
     Emacs または Gnus への参照の表示を制御します。関連する関数は、 gnus-button-handle-custom, gnus-button-handle-describe-function, gnus-button-handle-describe-variable, gnus-button-handle-symbol, gnus-button-handle-describe-key, gnus-button-handle-apropos, gnus-button-handle-apropos-command, gnus-button-handle-apropos-variable, gnus-button-handle-apropos-documentation および gnus-button-handle-library です。

gnus-button-man-level
     (Unix の) man ページへの参照の表示を制御します。 gnus-button-man-handler を見て下さい。

gnus-button-message-level
     Message-ID、メールアドレスおよびニュースの URL の表示を制御します。関連する変数と関数には gnus-button-mid-or-mail-regexp, gnus-button-prefer-mid-or-mail, gnus-button-mid-or-mail-heuristic および gnus-button-mid-or-mail-heuristic-alist があります。

gnus-button-tex-level
     TeX または LaTex への参照、例えば CTAN の URL の表示を制御します。変数 gnus-ctan-url, gnus-button-ctan-handler, gnus-button-ctan-directory-regexp および gnus-button-handle-ctan-bogus-regexp を見て下さい。

記事の日付
-----

日付は聞いたことの無い何か辺鄙なタイムゾーンで作成されていることが良くあるので、記事が送られたときに何時だったかを知ることができるのはとても良いことです。

W T u
     UT (別名 GMT, ZULU) で日付を表示します (gnus-article-date-ut)。

W T i
     日付を国際的な形式、ISO 8601 で表示します (gnus-article-date-iso8601)。

W T l
     日付をローカル・タイムゾーンで表示します (gnus-article-date-local)。

W T p
     日付を英語で楽に発音できる形式で表示します (gnus-article-date-english)。

W T s
     日付を利用者定義の様式を使って表示します (gnus-article-date-user)。その様式は変数 gnus-article-time-format で指定される、 format-time-string に渡される文字列です。指定することができる様式の一覧は、変数の説明文を見て下さい。

W T e
     記事が投稿されてから今までどれくらいの時間が経過したかを表示します (gnus-article-date-lapsed)。こんなふうに。

          X-Sent: 6 weeks, 4 days, 1 hour, 3 minutes, 8 seconds ago

     gnus-article-date-lapsed-new-header の値で、このヘッダーを既存の Date の下に追加するか、置き替えるかを指定します。

     Gnus でメールを読むことの利点は、それが単純なバグを素晴らしい不条理に置き換えることです。

     この行が連続して更新されるようにしたいのであれば、

          (gnus-start-date-timer)

     を ~/.gnus.el ファイルに入れるか、それを何かのフックで実行するようにすることができます。タイマーを止めたい場合は、 gnus-stop-date-timer 命令を使って下さい。

W T o
     本来の日付を表示します (gnus-article-date-original)。これはあなたが普段は他の変換関数を使っていて、それが完全に間違ったことをしているのではないかと心配になったときに役に立ちます。例えば、記事が 1854年に投稿されたと主張したとしましょう。しかし、そのようなことは 完全に  不可能です。私が信用できませんか? *くすくす*

好みの書式で自動的に日付を表示する方法は Customizing Articles を参照して下さい。

Article Display
---------------

これらのコマンドは、いろんな取るに足らないギミック (gimmicks) の表示を、それらをサポートしている Emacs の記事バッファーに追加します。

X-Face ヘッダーは小さな白黒画像で、メッセージヘッダーから持ってきます (see X-Face)。

Face ヘッダーは小さなカラー画像で、メッセージヘッダーから持ってきます (see Face)。

スマイリーは、人々がメッセージに散らかしたがる小さな :-) シンボルです。

一方 Picon はあなた自身のシステムに依存し、Gnus はヘッダーに合致するあなたの持ち物を探してみます (see Picons)。

これらすべての機能はトグルです。もしすでにそれらが存在していたならば、それらは削除されます。

W D x
     X-Face を From ヘッダーに表示します (gnus-article-display-x-face)。

W D d
     Face を From ヘッダーに表示します (gnus-article-display-face)。

W D s
     スマイリーを表示します (gnus-treat-smiley)。

W D f
     From ヘッダーを Picon 化します (gnus-treat-from-picon)。

W D m
     すべてのメールヘッダー (すなわち Cc、To) を Picon 化します (gnus-treat-mail-picon)。

W D n
     すべてのニュースヘッダー (すなわち Newsgroups と Followup-To) を Picon 化します (gnus-treat-newsgroups-picon)。

W D D
     記事バッファーからすべての画像を削除します (gnus-article-remove-images)。

記事の署名
-----

それぞれの記事は二つの部分に分けられます---ヘッダーと本文です。本文は署名部分と文章部分に分けることができます。どれが署名とみなされるかを決める変数は gnus-signature-separator です。これは普通は son-of-RFC 1036 で規定されている標準の ^-- $ です。しかし、多くの人が標準ではない署名セパレーターを使うので、この変数は一つ一つ試される、正規表現のリストであることもできます。(探索は本文の最後から始めへとなされます。) よくありそうな値は:

     (setq gnus-signature-separator
           '("^-- $"         ; 標準
             "^-- *$"        ; 普通の崩し方
             "^-------*$"    ; 多くの人は長ーーい横棒の
                             ; 行を使います。みっともない!
             "^ *--------*$" ; 二倍みっともない!
             "^________*$"   ; 下線も人気があります
             "^========*$")) ; 邪道!

あなたが寛容であればあるほど、間違った結果を得ることになるでしょう。

gnus-signature-limit は記事を表示するときにどれが署名とみなされるかへの制限を提供します。

 1. これが整数であれば、署名はこの整数より (文字数で) 長くなっていてはいけません。

 2. これが浮動小数点数であれば、署名はその数値より (行数で) 長くなっていてはいけません。

 3. これが関数であれば、その関数は引数なしで呼ばれ、それが nil を返せば、そのバッファーには署名がありません。

 4. これが文字列であれば、それは正規表現として使われます。もしそれが合致すれば、当のその文字列は署名ではありません。

この変数は、要素が上に列挙された型のリストであることもできます。例です:

     (setq gnus-signature-limit
           '(200.0 "^---*Forwarded article"))

これは署名セパレーターの後に 200 を超える行があるか、セパレーターの後のテキストが正規表現 ^---*Forwarded article に合致すれば、結局それは署名ではないということです。

記事いろいろ
------

A t
     記事をある言語から別のものへ変換します (gnus-article-babel)。

MIME コマンド
=========

以下のコマンドはすべて数値接頭引数を理解します。例えば 3 K v は「三番目の MIME パートを表示する」という意味です。

b
K v
     MIME パートを表示します。

K o
     MIME パートを保存します。

K O
     ファイル名の入力を求めてから MIME パートを保存し、それを記事から取り除きます。取り除かれた MIME オブジェクトは message/external-body 型の MIME 形式として参照されるようになります。

K r
     MIME パートを外部にある本体で置き換えます。

K d
     MIME パートを削除して、削除したことの案内を追加します。

K c
     MIME パートをコピーします。

K e
     MIME パートを外部コマンドで表示します。

K i
     MIME パートをバッファー内に表示します。

K |
     MIME パートを外部コマンドにパイプします。

以降の MIME コマンドの残りは、数値接頭引数を同じやり方では使いません:

K b
     すべての MIME パートの先頭にボタンを付加します。埋め込まれたパートをセーブ (または他の動作を実行) しようとするときに、たいてい便利です。

K m
     ときたま、ヘッダーが無かったり間違ったヘッダーを持つマルチパートのメッセージが送信されてきます。このコマンドは、それらのメッセージがより快適に表示されるように「修復」を試みます (gnus-summary-repair-multipart)。

X m
     MIME タイプに合致するすべてのパートを、ディレクトリーにセーブします (gnus-summary-save-parts)。プロセス/接頭引数の習慣を理解します (see Process/Prefix)。

M-t
     記事バッファーにボタンを表示するかしないかを切り替えまます (gnus-summary-toggle-display-buttonized)。

W M w
     記事ヘッダーにある RFC 2047 でエンコードされた語をデコードします (gnus-article-decode-mime-words)。

W M c
     エンコードされた記事の本文を、文字セットでデコードします (gnus-article-decode-charset)。

     このコマンドは、文字セットを決めるために Content-Type ヘッダーを調べます。記事にそんなヘッダーが無い場合でも、接頭引数を与えることによって、デコードするための文字セットを入力することは可能です。ある共通のエンコーディングを使って (でも MIME ヘッダーは含めずに) 人々が記事を投稿する地域的なグループでは、charset グループ/トピック・パラメーターに必要な文字セットを設定すれば良いでしょう (see Group Parameters)。

W M v
     現在の記事にある、すべての MIME パートを表示します (gnus-mime-view-all-parts)。

関連する変数:

gnus-ignored-mime-types
     これは正規表現のリストで、これに含まれている正規表現に合致する MIME タイプは、Gnus によって完全に無視されます。ディフォルト値は nil です。

     すべての Vcard を無視させるには、こんなふうにして下さい:

          (setq gnus-ignored-mime-types
                '("text/x-vcard"))

gnus-article-loose-mime
     非-nil だったら、Gnus は記事を MIME メッセージとして解読する前に、MIME-Version があることを必要としません。これは、ある壊れたメール・ユーザー・エージェントからのメッセージを読むときに役立ちます。ディフォルト値は nil です。

gnus-article-emulate-mime
     MIME ではない別のエンコーディングの手法があります。最も一般的なのは uuencode ですが、yEncode も普及してきています。この変数が非-nil になっていると、Gnus はメッセージの本文にそれらのエンコーディングが見つかるかどうかを調べ、もしあったならば、それらを Gnus の MIME 機構で処理します。ディフォルト値は t です。

gnus-unbuttonized-mime-types
     これは正規表現のリストで、これに含まれている正規表現に合致する MIME タイプには、ボタンが付加されません。ただし、それらが表示されないか、gnus-buttonized-mime-types 変数の方が優先される場合を除いて、ですが。ディフォルト値は (".*/.*") です。この変数は gnus-inhibit-mime-unbuttonizing が nil のときだけ使われます。

gnus-buttonized-mime-types
     これは正規表現のリストで、これに含まれている正規表現に合致する MIME タイプには、それらが表示されない場合を除いて、ボタンが付加されます。この変数は gnus-unbuttonized-mime-types よりも優先されます。ディフォルト値は nil です。この変数は gnus-inhibit-mime-unbuttonizing が nil のときだけ使われます。

     例えば、セキュリティーのボタンだけを表示して、他のボタンを表示しないようにするには、この変数を ("multipart/signed") に設定して、 gnus-unbuttonized-mime-types はディフォルト値のままにしておいて下さい。

gnus-inhibit-mime-unbuttonizing
     これが非-nil だと、すべての MIME パートにボタンを付加します。ディフォルト値は nil です。

gnus-article-mime-part-function
     それぞれの MIME パートに対して、この関数が MIME ハンドル (訳注: パートのタイプや内容物を表現するために、Gnus の内部で使われるデータの構造体) を引数にして呼ばれます。この関数は、利用者が記事から情報を集め (例えば Vcard の情報を bbdb のデータベースに加え) たり、パートに基づいて何かを起動 (例えば、すべての jpeg をあるディレクトリーにセーブ) するために使われることが意図されています。

     後者を行なう関数の例です:

          (defun my-save-all-jpeg-parts (handle)
            (when (equal (car (mm-handle-type handle)) "image/jpeg")
              (with-temp-buffer
                (insert (mm-get-part handle))
                (write-region (point-min) (point-max)
                              (read-file-name "Save jpeg to: ")))))
          (setq gnus-article-mime-part-function
                'my-save-all-jpeg-parts)

gnus-mime-multipart-functions
     MIME マルチパートの型と、それらを扱う関数の連想リストです。

gnus-mime-display-multipart-alternative-as-mixed
     "multipart/alternative" のパートを "multipart/mixed" であるものとして表示します。

gnus-mime-display-multipart-related-as-mixed
     "multipart/related" のパートを "multipart/mixed" であるものとして表示します。

     もし "text/html" を表示するのが気に入らないのなら、see 表示のカスタマイズ (The Emacs MIME Manual), にある mm-discouraged-alternatives を参照して下さい。ただし (それで "text/html" を表示しないように設定して、かつ) この変数が nil だと、"multipart/related" パートの中にある画像や他の資料を見逃してしまうかもしれません。

gnus-mime-display-multipart-as-mixed
     "multipart" のパートを "multipart/mixed" であるものとして表示します。もし t だと、 gnus-mime-display-multipart-alternative-as-mixed および gnus-mime-display-multipart-related-as-mixed が nil であっても、この設定の方が優先されます。

mm-file-name-rewrite-functions
     MIME パートのファイル名を書き換えるために使われる関数のリストです。それぞれの関数はファイル名を受け取って、ファイル名を返します。

     出来合いの関数は

     mm-file-name-delete-whitespace, mm-file-name-trim-whitespace, mm-file-name-collapse-whitespace および mm-file-name-replace-whitespace です。最後のものはファイル名に含まれるそれぞれの空白文字を、変数 mm-file-name-replace-whitespace の値で置き換えます。ディフォルト値は "_" (単一の下線) です。

     標準の関数である capitalize, downcase, upcase および upcase-initials も、役に立つでしょう。

     ファイル名に含まれる空白文字が害をもたらすことは、みんなが知っています。ただし、気にかけない人たちを除いて、ですが。そんな蒙昧の人たちから、たくさんの添付ファイルを受け取るのであれば、こんなものを ~/.gnus.el ファイルに追加することによって、安寧な生活を送ることができるでしょう。

          (setq mm-file-name-rewrite-functions
                '(mm-file-name-trim-whitespace
                  mm-file-name-collapse-whitespace
                  mm-file-name-replace-whitespace))

文字セット
=====

人々はいろいろな文字セットを使いますが、私たちは彼らが何の文字セットを使っているかを教えてくれる MIME を持っています。あるいはもっと正確に言えば、持っていたらいいなあと思います。多くの人たちが MIME を利用しないか理解しないニュースリーダーとメイラーを使って、何の文字セットを使うかを言わずに、単にメッセージを送出するのですが、これを少しばかり救済するために、いくつかの地域的なニュース階層には、何の文字セットがディフォルトであるかを宣言する取り決めがあります。例えば fj 階層では iso-2022-jp を使っています。

この知識は gnus-group-charset-alist 変数にエンコードされています。これは正規表現 (グループのフルネームに合致した最初の項目を使います) と、それらのグループを講読するときに使われるディフォルトの文字セットの、連想リストです。

加えて、人々のいくらかは MIME を意識していると自称 (soi-disant) しているくせに、実はそうではないエージェントを使っています。それらは、実際にはメッセージが koi-8 なのに iso-8859-1 だと、陽気にメッセージに刻印するのです。ここでは救済のために gnus-newsgroup-ignored-charsets 変数を使うことができます。そのリストに連ねられた文字セットは無視されます。この変数は、グループパラメーター (see Group Parameters) を使って、グループ毎に設定することができます。ディフォルト値は (unknown-8bit x-unknown) で、それはいくつかのエージェントが内蔵し、主張する値を含んでいます。

投稿する場合に、MIME でエンコードしてはいけない文字セットを判定するために、gnus-group-posting-charset-alist が使われます。例えばいくつかの階層では、quoted-printable でヘッダーをエンコードすることは嫌われます。

この変数は正規表現と、投稿に際してエンコードしなくても良いことを許された (またはエンコードすることが嫌われる) 文字セットの連想リストです。それぞれの要素は (TEST HEADER BODY-LIST) の形式であり、それらは次の意味を持ちます。

test
     Newsgroups ヘッダーに合致する正規表現、または変数シンボルのどちらかです。後者の場合は、その値を調べた結果が非-nil だったら、その要素が採用されることになります。

header
     ヘッダーをエンコードしなくても良い文字セットです (nil は、すべての文字セットをエンコードすることを意味します)。

body-list
     「Content-Transfer-Encoding: 8bit」でもって本文をエンコードしても良い (または quoted-printable や base64 でエンコードすることが嫌われる) 文字セットのリスト、または特別な値の一つである nil (常に quoted-printable でエンコードする)、または t (常に「Content-Transfer-Encoding: 8bit」を使う) です。

メッセージを送信するときに何の文字セットが使われるかを制御する付加的な変数については、see エンコーディングのカスタマイズ (The Emacs MIME Manual), を参照して下さい (訳注: 特に日本語のメッセージの文字セットについては、例えば変数 mm-coding-system-priorities を参照して下さい)。

Gnus 固有ではないけれど、役に立つかもしれない文字セットに関する他の秘訣:

もし、同一の Emacs の文字セットをエンコードする MIME の文字セットが複数あるのならば、以下の宣言を使うことによって、使う文字セットを選択することができます:

     (put-charset-property 'cyrillic-iso8859-5
                           'preferred-coding-system 'koi8-r)

これは、ロシア語がディフォルトの iso-8859-5 MIME 文字セットの代わりに、koi8-r でエンコードされることを意味します。

メッセージを koi8-u で読みたいのであれば、以下のように騙すことができます。

     (define-coding-system-alias 'koi8-u 'koi8-r)

これは、ほとんど正しいことをするでしょう。

そして最後に、windows-1251 のような文字セットを読むには、次のように宣言すれば良いでしょう (訳注: Emacs の版によっては、 windows-1251 が最初から実装されています)。

     (codepage-setup 1251)
     (define-coding-system-alias 'windows-1251 'cp1251)

記事命令
====

A P
     記事バッファーのポストスクリプト (PostScript) イメージを作成して印刷します (gnus-summary-print-article)。gnus-ps-print-hook がバッファーを印刷する直前に実行されます。他に Muttprint を使って印刷することもできます (see Saving Articles)。

概略の並べ替え
=======

私はどうしてあなたがそうしたいのかはわからないのですが、それでもあなたはたくさんの方法で概略バッファーを並べ替えることができます。

C-c C-s C-n
     記事番号によって並べ替えます (gnus-summary-sort-by-number)。

C-c C-s C-a
     著者によって並べ替えます (gnus-summary-sort-by-author)。

C-c C-s C-t
     受信者によって並べ替えます (gnus-summary-sort-by-recipient)。

C-c C-s C-s
     表題によって並べ替えます (gnus-summary-sort-by-subject)。

C-c C-s C-d
     日付によって並べ替えます (gnus-summary-sort-by-date)。

C-c C-s C-l
     行数によって並べ替えます (gnus-summary-sort-by-lines)。

C-c C-s C-c
     記事の長さ (文字数) で並べ替えます (gnus-summary-sort-by-chars)。

C-c C-s C-i
     スコアによって並べ替えます (gnus-summary-sort-by-score)。

C-c C-s C-r
     ランダムに並べ替えます (gnus-summary-sort-by-random)。

C-c C-s C-o
     ディフォルトの方法で並べ替えます (gnus-summary-sort-by-original)。

これらの関数はスレッドを使っているときと使っていないときの両方で動作します。後者では、すべての概略行が一行一行並べ替えられます。前者では根本だけに基づいて並べ替えられ、それはあなたが求めていることとは異なっているかもしれません。スレッドを使うかどうかを切り替えるには T T を打って下さい (see Thread Commands)。

親記事を探す
======

^
     現在の記事の親記事を読みたいのに、それが概略バッファーに表示されていなくても、おそらくそれは可能でしょう。というのは、現在のグループが NNTP で取得されていて、親がまだ期限切れ消去されていない上、現在の記事の References がぶち壊されていなければ、ただ ^ か A r を押せば良いだけですから (gnus-summary-refer-parent-article)。すべてがうまくいけば、親記事を取得できるでしょう。もし親記事がすでに概略バッファーに表示されているのであれば、ポイントがその記事に移動するでしょう。

     正の数値接頭引数を与えられると、その数の祖先たちを遡って取得します。負の数値接頭引数が与えられた場合は、その数の世代だけ前の祖先の記事のみを取得します。ですから 3 ^ とすれば、Gnus は現在の記事の親と祖父母と曾祖父母を取得します。-3 ^ とすれば、Gnus は現在の記事の曾祖父母だけを取得します。

A R (概略)
     記事の References 欄にあるすべての記事を取得します (gnus-summary-refer-references)。

A T (概略)
     現在の記事があるスレッドの、全部の記事を表示します (gnus-summary-refer-thread)。この命令は動作するために現在のグループのすべてのヘッダーを取得しなければならないので、普通は少し時間がかかります。これをしばしば行なうのであれば、 gnus-fetch-old-headers を invisible に設定することを考えたほうが良いでしょう (see Filling In Threads)。これは普通は視覚的な効果はありませんが、この命令の動作をかなり速くします。もちろんグループに入るのはいくらか遅くなりますが。

     変数 gnus-refer-thread-limit はこの命令を実行するときにどのくらい古い (すなわち、現在のグループで最初に表示されたものよりも前の記事の) ヘッダーを取得するかを指定します。ディフォルトは 200 です。もし t であれば、取得可能なすべてのヘッダーを取得します。A T 命令に数値接頭引数を与えると、代わりにそれが使われます。

M-^ (概略)
     どのグループに属しているかに関わらず、任意の記事を Gnus に要求することができます。 M-^ (gnus-summary-refer-article) は Message-ID、つまりあの長くてなかなか読むことのできない <38o6up$6f2@hymir.ifi.uio.no> のようなものをあなたに尋ねます。あなたはすべてを正確に打ち込まなければなりません。残念ながら、あいまいな検索はできないのです。

     Gnus はすでに取得してあるヘッダーたちの中で Message-ID を探しますが、見つからなかったら gnus-refer-article-method に設定されているすべての選択方法を試してもみます。

もしあなたの読んでいるグループが Message-ID での取得があまり良くできないようなバックエンド (nnspool など) であるのなら、 gnus-refer-article-method を NNTP の選択方法に設定すれば良いでしょう。おそらく、あなたが問い合わせる NNTP サーバーがあなたの読んでいるスプールを更新していると最も良いでしょう。しかし、それはどうしても必要なわけではありません。

それは選択方法のリストのみならず、現在の選択方法を意味する特別なシンボル current であることもできます。Gnus は合うものを発見するまでそれらすべての方法を試します。

これは現在の選択方法を試して、それが失敗した場合には Google に訊く設定の例です:

     (setq gnus-refer-article-method
           '(current
             (nnweb "google" (nnweb-type google))))

ほとんどのメールバックエンドは Message-ID での取得が可能ですが、あまり優雅な方法でやっているわけではありません。nnmbox, nnbabyl, nnmaildir および nnml がどのグループからでも記事を捜索できるのに対して、nnfolder と nnimap は現在のグループに投稿された記事しか探すことができません。(その他のものは時間がかかりすぎます。) nnmh ではまったく不可能です。

代替手段
====

ニュースを読む方法の好みは人それぞれです。これは Gnus なのですから、概略バッファーのためのマイナーモードに少しばかり選択肢を設けます。

選んで読む
-----

いくつかのニュースリーダー (nn や、ええと VM/CMS の Netnews など) は二段階の講読インターフェースを使います。利用者はまず概略バッファーで読みたい記事に印を付けます。それから、記事バッファーだけを表示して記事を読みます。

Gnus はこれをするための概略バッファーマイナーモードを提供します---gnus-pick-mode です。これは、基本的には簡単に印を付けられるように少数のプロセス印命令を一個のキーだけで済む命令にして、概略バッファーへ切り替えるための追加の命令を一つ提供します。

     訳注: Pick マイナーモードを有効にするには、以下のフックを使って下さい:

          (add-hook 'gnus-summary-mode-hook 'gnus-pick-mode)

     そうせずに、概略バッファーに入ってから M-x gnus-pick-mode を実行しても、うまくいかないようです。

これらが pick mode で使うことができるキーです:

.
     現在の行の記事かスレッドを選択します (gnus-pickd-article-or-thread)。変数 gnus-thread-hide-subtree が非-nil だったら、このキーがスレッドの最初の記事で使われるとスレッド全体を選択します。そうでなければ、その記事だけを選択します。もし数値接頭引数を与えられると、その番号のスレッドか記事に移動して、それを選択します。(普通は行番号が概略行の最初に表示されます。)

SPACE
     概略バッファーを一ページ次にスクロールします (gnus-pick-next-page)。もしバッファーの最後であれば、選択した記事を読み始めます。

u
     スレッドか記事を未選択にします (gnus-pick-unmark-article-or-thread)。変数 gnus-thread-hide-subtree が非-nil だったら、このキーがスレッドの最初で使われるとそのスレッドを未選択にします。そうでなければ、その記事だけを未選択にします。その行にあるスレッドか記事を未選択にするために、このキーに数値接頭引数を与えることができます。

RET
     選択された記事を読み始めます (gnus-pick-start-reading)。接頭引数が与えられると、最初にすべての未選択記事に既読の印を付けます。 gnus-pick-display-summary が nil でないと、概略バッファーは読んでいる間も表示されます。

すべての普通の概略モード命令は pick-mode でも使用可能ですが、u は例外です。それでも、同じ関数 gnus-summary-tick-article-forward に割り当てられている ! を使うことができます。

これが良さそうだと思ったら、次のようにして下さい:

     (add-hook 'gnus-summary-mode-hook 'gnus-pick-mode)

gnus-pick-minor-mode-hook は pick マイナーモードのバッファーで実行されます。

gnus-mark-unpicked-articles-as-read が非-nil だったら、選択されなかったすべての記事に既読の印を付けます。ディフォルト値は nil です。

pick モードでの概略行の様式は標準の様式とは少し違います。それぞれの行の最初に行数が表示されます。Pick モードの行の様式は変数 gnus-summary-pick-line-format で制御されます (see Formatting Variables)。これは gnus-summary-line-format と同じ様式指定を受け付けます (see Summary Buffer Lines)。

バイナリーグループ
---------

多くの時間をバイナリーグループで過ごしているのなら、いつも X u, n, RET を叩くのが嫌になっているでしょう。 M-x gnus-binary-mode は、単に記事を普通の方法で表示する代わりに、記事を選択するための普通の Gnus の関数を、一連の記事を uudecode してその結果を表示するように変更する、概略バッファーのためのマイナーモードです。

現実には、このモードにしたときに、実際に記事を見るための唯一の命令が g です (gnus-binary-show-article)。

gnus-binary-mode-hook がバイナリーマイナーモードのバッファーで呼ばれます。

木表示
===

もし普通の Gnus の概略表示を好きでないならば、 gnus-use-trees を t に設定してみると良いかもしれません。これは (ディフォルトで) 追加の 木バッファー (tree buffer) を作成します。木バッファーではすべての概略モード命令を実行することができます。

もちろん、木表示をカスタマイズする変数が少しあります:

gnus-tree-mode-hook
     すべての木モードのバッファーで実行されるフックです。

gnus-tree-mode-line-format
     木モードのバッファーにおけるモード行のためのフォーマット文字列です (see Mode Line Formatting)。ディフォルトは Gnus: %%b %S %Z です。使用可能な指定は Summary Buffer Mode Line を参照して下さい。

gnus-selected-tree-face
     木バッファーで選択された記事をハイライトするために使われるフェースです。ディフォルトでは modeline です。

gnus-tree-line-format
     木の節のためのフォーマット文字列です。でもこれは少し誤った名称です---それは行ではなく、ただ節を定義するだけです。ディフォルトの値は %(%[%3,3n%]%) で、それは投稿者の名前の最初の三文字を表示します。すべての節が同じ長さであることが重要なので、%4,4n のような指定を 使わなければなりません。

     有効な指定は:

     n
          投稿者の名前。

     f
          From 欄。

     N
          記事の番号。

     [
          開き括弧。

     ]
          閉じ括弧。

     s
          表題。

     See Formatting Variables.

     表示に関連した変数は:

     gnus-tree-brackets
          これは『本当の』記事と『まばら』な記事に違いを付けるために使われます。様式は

               ((本当の開 . 本当の閉)
                (まばら開 . まばら閉)
                (偽の開 . 偽の閉))

          となっていて、ディフォルトは ((?[ . ?]) (?( . ?)) (?{ . ?}) (?< . ?>)) です。

     gnus-tree-parent-child-edges
          これは親の節を子に接続するために使われる文字を含むリストです。ディフォルトは (?- ?\\ ?|) です。

gnus-tree-minimize-window
     もしこの変数が nil でないと、他の Gnus ウィンドウがもっと場所を取れるように Gnus は木バッファーをできるだけ小さくします。もしこの変数が数値であると、木バッファーの高さはその数値より大きくなることはありません。ディフォルトは t です。フレームでいくつかのウィンドウが横に並んで表示されていて、木バッファーがそのうちの一つである場合、木ウィンドウを最小化することはその隣に表示されているすべてのウィンドウの大きさをも変更することに注意して下さい。

     以下のフックを追加して、いつでも木ウィンドウを最小化するようにしても良いでしょう。

          (add-hook 'gnus-configure-windows-hook
                    'gnus-tree-perhaps-minimize)

gnus-generate-tree-function
     実際にスレッドの木を作成する関数です。二つの定義済みの関数 gnus-generate-horizontal-tree および gnus-generate-vertical-tree (これがディフォルトです) が利用可能です。

水平木バッファー (horizontal tree buffer) の例です:

     {***}-(***)-[odd]-[Gun]
          |      \[Jan]
          |      \[odd]-[Eri]
          |      \(***)-[Eri]
          |            \[odd]-[Paa]
          \[Bjo]
          \[Gun]
          \[Gun]-[Jor]

同じスレッドが垂直木バッファー (vertical tree buffer) で表示されたものです:

     {***}
       |--------------------------\-----\-----\
     (***)                         [Bjo] [Gun] [Gun]
       |--\-----\-----\                          |
     [odd] [Jan] [odd] (***)                   [Jor]
       |           |     |--\
     [Gun]       [Eri] [Eri] [odd]
                               |
                             [Paa]

もし水平木を使っているのなら、概略バッファーで木を隣り合わせで表示できれば嬉しいでしょう。次のようなものを ~/.gnus.el ファイルに加えることができます:

     (setq gnus-use-trees t
           gnus-generate-tree-function 'gnus-generate-horizontal-tree
           gnus-tree-minimize-window nil)
     (gnus-add-configuration
      '(article
        (vertical 1.0
                  (horizontal 0.25
                              (summary 0.75 point)
                              (tree 1.0))
                  (article 1.0))))

See Window Layout.

メールグループ命令
=========

いくつかの命令はメールグループでのみ意味を持ちます。これらの命令が現在のグループで有効でないなら、それらは大騒ぎをしてあなたに知らせるでしょう。

これらすべての命令は (期限切れ消去と編集命令は除く) プロセス/接頭引数の習慣を使います (see Process/Prefix)。

B e
     現在のグループのすべての期限切れ消去可能な記事について、期限切れ消去の処理 (gnus-summary-expire-articles) を行ないます。これは、そのグループにしばらく存在していた期限切れ消去可能なすべての記事を消去するということです。(see Expiring Mail)。

B C-M-e
     グループのすべての期限切れ消去可能な記事を削除します (gnus-summay-expire-articles-now)。これは、現在のグループにある すべて の期限切れ消去可能な記事が、永遠に空の大きな /dev/null へ消え去るということです。

B DEL
     メール記事を削除します。これは『あなたのディスクから永久に削除して二度と戻らない』の意味の『削除』です。注意して使って下さい (gnus-summary-delete-article)。

B m
     あるメールグループから別のメールグループへ記事を移動します (gnus-summary-move-article)。gnus-preserve-marks の値が nil でなければ (これがディフォルト値ですが)、マークは保存されます。

B c
     あるグループ (メールグループや他のもの) からメールグループに記事をコピーします (gnus-summary-copy-article)。gnus-preserve-marks の値が nil でなければ (これがディフォルト値ですが)、マークは保存されます。

B B
     現在の記事を他のグループにクロスポストします (gnus-summary-crosspost-article)。これは他のグループの記事の新しい複製を作成し、記事の Xref 欄も適切に更新されます。

B i
     任意のファイルを現在のメールグループに取り込みます (gnus-summary-import-article)。あなたはファイル名と、 From 欄と Subject 欄の入力を促されます。

B I
     空の記事を現在のメールグループに作ります (gnus-summary-create-article)。From ヘッダーと Subject ヘッダーの内容を尋ねられます。

B r
     メール記事をスプールし直します (gnus-summary-move-article)。 gnus-summary-respool-default-method が再スプールするときのディフォルトの選択方法として使用されます。この変数はディフォルトでは nil で、その場合は現在のグループの選択方法が代わりに使われます。 gnus-preserve-marks の値が nil でなければ (これがディフォルト値ですが)、マークは保存されます。

     訳注: 「スプールし直す」というのはメールの分割 (Splitting Mail または Fancy Mail Splitting) の規則に基づいて、メールを適切なグループに入れ直すことです。そのグループに間違って入ってしまったメールを、分割の規則を修正した後で、正しいグループに移動させる場合などに使います。この章の B q と B t も見て下さい。

B w
e
     現在の記事を編集します (gnus-summary-edit-article)。編集を終了して変更を固定するには C-c C-c (gnus-summary-edit-article-done) を打ちます。もし C-c C-c 命令に接頭引数を与えると、Gnus は記事を再ハイライトしません。

     訳注: 変更しないで編集を終るには、C-c C-k をタイプして下さい。

B q
     記事を再スプールするときは、再スプールをする前にどのグループに記事が移るかを知りたいでしょう。この命令でそれがわかります (gnus-summary-respool-query)。

B t
     同様に、この命令は再スプールするときに使われるすべての特級分割方式を、もしあれば表示します (gnus-summary-respool-trace)。

B p
     一部の人たちには、あなたが投稿した記事にフォローアップするときに、「親切な」複製を送る傾向があります。これらは普通はそこに Newsgroups ヘッダーが付いているのですが、いつもそうであるとは限りません。この命令 (gnus-summary-article-posted-p) は現在の記事をあなたのニュースサーバーから (というよりは、むしろ gnus-refer-article-method や gnus-select-method から) 取得しようとして、記事を発見できたかどうかを報告します。それが記事を発見しなかったとしても、それはとにかく投稿されているかもしれません---メールの伝達はニュースの伝達よりもずっと速いので、ニュースの複製がまだ到着していないだけかもしれないのです。

     訳注: その「親切な」複製が、概略バッファーで独立した記事として見えていないと検査することができないので、そうするために A D または C-d 命令 (see Really Various Summary Commands) を使う必要があるかもしれません。この命令はとにかくすべての選択方法を試すので、特にそれらに遅いものが含まれているときは、注意して使って下さい。

K E
     記事の本文を暗号化します (gnus-article-encrypt-body)。本文は、変数 gnus-article-encrypt-protocol で指定されたプロトコルで暗号化されます。

いつも記事をどこかに移動 (もしくは複製) することを習慣にしているのならば、記事をどこに入れれば良いかを Gnus に提案してもらいたいと思うでしょう。 gnus-move-split-methods は gnus-split-methods と同じ構文を使う変数です (see Saving Articles)。あなたが妥当だと思うような提案をするようにその変数をカスタマイズすることができます。 (gnus-split-methods がファイル名を使うのに対して gnus-move-split-methods はグループ名を使うことに注意して下さい。)

     (setq gnus-move-split-methods
           '(("^From:.*Lars Magne" "nnml:junk")
             ("^Subject:.*gnus" "nnfolder:important")
             (".*" "nnml:misc")))

概略のいろいろなもの
==========

gnus-summary-display-while-building
     非-nil だったら、構築中の概略バッファーを更新しながら表示します。 t だった場合は、行が挿入される度に毎回バッファーを更新します。値が整数 N であった場合は、N 行毎に表示を更新します。ディフォルトは nil です。

gnus-summary-display-arrow
     非-nil だったら、現在の記事を指し示すためにフリンジに矢印を表示します。(訳注: フリンジとは Emacs 21 以上でウィンドウの左右に現れる余白のことです。)

gnus-summary-mode-hook
     概略モードのバッファーを作成するときにこのフックが呼ばれます。

gnus-summary-generate-hook
     これはスレッド作成と概略バッファー作成の前に実行する最後のものとして呼ばれます。これはニュースグループの持っているデータに基づいてスレッドの変数をカスタマイズするのに非常に便利です。このフックはほとんどの概略バッファー変数が設定された後に概略バッファーから呼ばれます。

gnus-summary-prepare-hook
     これは概略バッファーが作成された後に呼ばれます。例えば、これを何かしら神をも畏れぬ方法で行をハイライトしたり、バッファーの見え方を修正したりするのに使ったりするかもしれません。

gnus-summary-prepared-hook
     概略バッファーが作成された後で一番最後に呼ばれるフックです。

gnus-summary-ignore-duplicates
     Gnus が同じ Message-ID を持つ二つの記事を発見したときは、何か思い切ったことをしなければなりません。別の記事が同じ Message-ID を持つことは許されていませんが、それは何らかのソースからメールを読んでいるときに起こるかもしれません。この変数によって Gnus が何をするかをカスタマイズできるようになっています。nil だったら (それがディフォルトです)、 Gnus は Message-ID を付け替えて (表示のためだけに) その記事を他の記事と同じように表示します。t にすると、それは記事を表示しません---最初から存在しなかったかのように。

gnus-alter-articles-to-read-function
     この変数に設定した関数で、選択する記事のリストを変更することができます。関数は二つの引数 (グループ名と選択する記事のリスト) を受け付けます。

     例えば以下の関数は、キャッシュされた記事のリストを、あるグループのリストだけに追加します。

          (defun my-add-cached-articles (group articles)
            (if (string= group "some.group")
                (append gnus-newsgroup-cached articles)
              articles))

gnus-newsgroup-variables
     ニュースグループ (その概略バッファーの) のローカル変数、または変数とそれらの評価されるディフォルトの表現 (ディフォルト値が nil でない場合) の cons セルのリストで、その概略バッファーが活きている間はグローバル変数になります。(訳注: いわゆるバッファーローカル変数ではありません。)

     注: ディフォルトの表現は単にローカル変数に設定されるのではなく、その前に (eval 関数を使って) 評価されます。ディフォルトの表現が global というシンボルだった場合は評価されず、代わりにそのローカル変数のグローバル値が使われます。

     これらグループパラメーターの値が他のバッファーで行なわれる処理に影響するようになっていても、(訳注: その概略バッファーの) グループパラメーターを設定するために使うことができます。例です:

          (setq gnus-newsgroup-variables
               '(message-use-followup-to
                 (gnus-visible-headers .
                   "^From:\\|^Newsgroups:\\|^Subject:\\|^Date:\\|^To:")))

     Group Parameters も参照して下さい。

     訳注: もっと良い例が必要です。gnus-newsgroup-variables および gnus-parameters (see Group Parameters) の値を次のように設定したとしましょう:

          (setq gnus-newsgroup-variables '((VAR . FOO)))
          (setq gnus-parameters
                '(("^fj\\." (VAR . BAR))
                  ("^japan\\." (VAR . BAZ))))

     こうしておくと変数 VAR の値が、fj 階層のニュースグループ (の概略バッファー) に入ると BAR になり、japan 階層のグループに入ると BAZ になります。グループを抜けても変数 VAR の値は変化しませんが、fj または japan 階層以外のグループに入ると変数 VAR の値は FOO になります (正確には、FOO, BAR または BAZ の値は、本編で説明されているように eval した結果が使われます)。

     通常のグループパラメーターは、そのグループの概略バッファでだけ値を知ることができるのに対して、gnus-newsgroup-variables で設定した変数は、同じ Emacs のどのバッファーでも、現在選択されているグループ固有の値を持つ点が違います。異なる複数のグループの概略バッファーを使う場合には、注意する必要があります。

     特別な場合として FOO が nil で良い場合は、次のように記述することができます:

          (setq gnus-newsgroup-variables '(VAR))
          (setq gnus-parameters
                '(("^fj\\." (VAR . BAR))
                  ("^japan\\." (VAR . BAZ))))

     gnus-newsgroup-variables および gnus-parameters はどちらもリストなので、setq よりはむしろ add-to-list や push などを使って、値を「追加」した方が便利かもしれません。

概略グループ情報
--------

H f
     現在のグループの FAQ (frequently asked questions (頻繁にされる質問) のリスト) を取得しようとします (gnus-summary-fetch-faq)。 Gnus は gnus-group-faq-directory (通常これは遠隔マシンのディレクトリー) から FAQ を取得しようとします。この変数はディレクトリーのリストであることもできます。その場合、この命令に接頭引数を与えることによっていろいろなサイトから選ぶことができます。おそらく ange-ftp もしくは efs がファイルの取得に使われるでしょう。

H d
     現在のグループの簡潔な説明を表示します (gnus-summary-describe-group)。接頭引数が与えられると、サーバーから強制的に説明の再読み込みをします。

H h
     最も重要な概略コマンドの、非常に簡潔な説明を表示します (gnus-summary-describe-briefly)。

H i
     Gnus の info の節 (node) に移動します (gnus-info-find-node)。

記事を探す
-----

M-s
     それ以降のすべての (生の) 記事を正規表現で検索します (gnus-summary-search-article-forward)。

M-r
     それ以前のすべての (生の) 記事を正規表現で検索します (gnus-summary-search-article-backward)。

&
     この命令は、ヘッダー、そのヘッダーの内容に合致する正規表現、および合致したときに実行されるコマンドの入力を要求します (gnus-summary-execute-command)。ヘッダーが空文字列だったら、記事全体で合致するものを探します。接頭引数を与えられると、代わりに後ろ向きに探します。

     例えば & RET 何かの.*文字列 RET # は、ヘッダーか本文に 何かの.*文字列 を持つすべての記事にプロセス印を付けます。

M-&
     この命令に続けて入力する命令を、プロセス印が付けられているすべての記事で実行します (gnus-summary-universal-argument)。

概略生成命令
------

Y g
     現在の概略バッファーを再作成します (gnus-summary-prepare)。

Y c
     (現在のグループのために) キャッシュされたすべての記事を概略バッファーに挿入します (gnus-summary-insert-cached-articles)。

Y d
     (現在のグループのための) すべての保留記事を概略バッファーに挿入します (gnus-summary-insert-dormant-articles)。

本当にいろいろな概略命令
------------

A D
C-d
     現在の記事が別の記事を寄せ集めたもの (例えばダイジェスト) であるならば、それらの記事でできているグループに入るためにこの命令を使うことができます (gnus-summary-enter-digest-group)。この命令に接頭引数を与えないと Gnus はどのような型の記事が現在表示されているかを推測しようとし、実際にはそれが『ダイジェスト』であるものとして強引に解釈します。基本的に、ある様式で寄せ集められた別のメッセージを見るときはいつでも、C-d を使うことによって、もっと便利なやり方でそれらのメッセージを読むことができます。

C-M-d
     この命令は上のものによく似ていますが、いくつかの文書を一つのおおーきなグループに集めます (gnus-summary-read-read-document)。それを実現するために、この命令はそれぞれの文書のための nndoc グループを開いてから、それら複数の nndoc グループのてっぺんで nnvirtual グループを開きます。この命令はプロセス/接頭引数の習慣を理解します (see Process/Prefix)。

C-t
     長い概略行を切り詰めるかどうかを切り替えます (gnus-summary-toggle-truncation)。これはおそらく概略バッファーで行を中央に表示する機能を混乱させるので、記事を読んでいるときに行の切り詰めを off にするのは良い考えではないでしょう。

=
     概略バッファーのウィンドウを拡大します (gnus-summary-expand-window)。接頭引数を与えられると、記事バッファーのためのウィンドウの配置の設定を強制します (訳注: ディフォルトでは記事バッファーのためのウィンドウの配置の設定には概略バッファーを表示することも含まれているので、普通に記事を読んでいるときと同じになるでしょう)。

C-M-e
     現在のグループのグループパラメーター (see Group Parameters) を編集します (gnus-summary-edit-parameters)。

C-M-a
     現在のグループのグループパラメーター (see Group Parameters) をカスタマイズします (gnus-summary-customize-parameters)。

概略バッファーを抜ける
===========

概略バッファーから抜けると、普通はグループのすべての情報を更新してグループバッファーに戻ります。

Z Z
Z Q
q
     現在のグループを出て、グループのすべての情報を更新します (gnus-summary-exit)。抜け出るための多くの処理を行なう前に gnus-summary-prepare-exit-hook が呼ばれ、それはディフォルトで gnus-summary-expire-articles を呼びます。抜け出るための処理を終えた後で gnus-summary-exit-hook が呼ばれます。グループモードに戻るときに (未読の) グループが残っていなかったら gnus-group-no-more-groups-hook が実行されます。

Z E
Q
     グループのどんな情報も更新せずに現在のグループを抜け出ます (gnus-summary-exit-no-update)。

Z c
c
     グループのすべての可視ではない (unticked) 記事に既読の印を付けてから抜けます (gnus-summary-catchup-and-exit)。

Z C
     可視記事さえも含むすべての記事に既読の印を付けてから抜けます (gnus-summary-catchup-all-and-exit)。

Z n
     すべての記事に既読の印を付けて次のグループへ移動します (gnus-summary-catchup-and-goto-next-group)。

Z R
C-x C-s
     現在のグループを出て、それから入り直します (gnus-summary-reselect-current-group)。接頭引数が与えられると、既読と未読の両方のすべての記事を選択します。

Z G
M-g
     グループを抜け、そのグループの新しい記事を調べてから、再びそのグループを選択します (gnus-summary-rescan-group)。接頭引数が与えられると、既読と未読の両方のすべての記事を選択します。

Z N
     グループを抜けて、次のグループへ移動します (gnus-summary-next-group)。

Z P
     グループを抜けて、前のグループへ移動します (gnus-summary-prev-group)。

Z s
     現在の既読と印付き記事の数をドリブルバッファー (dribble buffer) に保存し、それからドリブルバッファーを保存します (gnus-summary-save-newsrc)。接頭引数が与えられると .newsrc ファイル (と .newsrc.eld ファイル) も保存します。この命令を使うと、更新なしで抜け出ること (Q 命令) は意味が無くなります。

グループのすべての情報を「更新」して現在のグループを抜けるときに gnus-exit-group-hook が呼ばれます。例えば Q 命令 (gnus-summary-exit-no-update) はこのフックを呼びません。

グループを抜けた後でそれを後悔する癖があるのなら、 gnus-kill-summary-on-exit を nil に設定と良いかもしれません。そうすると Gnus は抜け出るときに概略バッファーを削除しません。(何という驚き!) 代わりに、それはバッファーの名前を *Dead Summary ... * のようなものに変更して、 gnus-dead-summary-mode というマイナーモードを導入します。今やそのバッファーに切り替えると、すべてのキーが関数 gnus-summary-wake-up-the-dead に割り当てられていることに気付くでしょう。死んだ概略バッファー (dead summary buffer) でどんなキーでも叩くと、それは生きた普通の概略バッファーになります。

死んだ概略バッファーは同時に一つしか存在することはできません。

概略バッファーを抜け出ると、現在のグループのデータは更新されます (どの記事を読んで、どの記事に返答したか、などなど。) もし変数 gnus-use-cross-reference が t であると (それがディフォルトです)、そのグループに相互参照された (cross referenced) 記事には、それがクロスポストされた他の購読しているグループにあっても、既読の印が付きます。この変数が nil でも t でもなければ、記事には購読しているグループと購読していないグループの両方で既読の印が付きます (see Crosspost Handling)。

クロスポストの扱い
=========

クロスポストされた記事に既読の印を付けることによって、同じ記事を二回以上読まないで済むことを保証します。もちろん、だれかがそれを複数のグループに別々に投稿しない限りは。同じ記事を複数のグループに (クロスポストではではなく) 投稿することは spamming と呼ばれ、あなたはそのような憎むべき犯罪を行なうものに対して、法律によって不快な記事を送ることが義務づけられています。spam を振い落すために、NoCeM で処理することを試してみる必要があるかもしれません (see NoCeM)。

覚えておいて下さい: クロスポストはまあ構いませんが、同じ記事を別々に複数のグループに投稿するのは許されません。大量のクロスポスト (velveeta として知られているもの) は何としても避けられるべきで、過剰なクロスポストに対して不満を言うために gnus-summary-mail-crosspost-complaint 命令を使うことさえできます。

Gnus にクロスポストを正しく扱えなくさせる原因の一つは、XOVER (これは非常に良いです、というのはそれは速度をとても速くするからです) をサポートしているけれども NOV 行に Xref 欄を含めない NNTP サーバーを使っていることです。これは害悪です。でも、あぁ、悲しいかな、非常に良くあることなのです。Gnus はあなたが読んだすべての記事に Xref 行を記録することによって The Right Thing (正しいこと) をしようとしますが、記事を削除したり単に読まないで既読の印を付けると、Gnus がこれらの記事の Xref 行をのぞきまわる機会が無くなってしまうので、相互参照 (cross reference) の機構を使えなくなってしまいます。

あなたの NNTP サーバーがその概観ファイル (overview file) に Xref 欄を含めるかどうかを調べるには、 telnet your.nntp.server nntp をタイプして、inn サーバーでは MODE READER コマンドを与えてから、LIST overview.fmt を試して下さい。これは動作しないかもしれません。しかし、もし動作して、取得した最後の行が Xref:full でないならば (訳注: 最後の行ではないかもしれません)、ニュースの管理者が概観ファイルに Xref 欄を含めるようにしてくれるまで、彼女に向かって叫び、泣き付くべきでしょう。

Gnus にいつでも正しい Xref を取得するようにさせたいのであれば、 gnus-nov-is-evil を t にする必要があり、それは非常に速度を遅くします。

ま、人生はそのようなものです。

代替手段に付いては Duplicate Suppression を参照して下さい。

重複の抑制
=====

ディフォルトでは Gnus はクロスポスト機構を利用することによって、同じ記事を二回以上読まないようにしようとします (see Crosspost Handling)。しかし、その単純で効果的な方法は、いろいろな理由により、満足する結果をもたらさないかもしれません。

 1. NNTP サーバーは Xref 欄の生成に失敗するかもしれません。これは悪いことで、あまり起こりません。

 2. NNTP サーバーは .overview データベースに Xref 欄を含めるのに失敗するかもしれません。これは悪いことで、非常に良くあることです、あぁ悲しい。

 3. 同じグループ (もしくはいくつかの関連したグループ) を違った NNTP サーバーから読んでいるかもしれません。

 4. グループに投稿された記事と重複するメールを受け取ったかもしれません。

Xref の扱いに失敗する状況は確かに他にもありますが、これら四つが最も良くある状況です。

もし、本当にもしも Xref の扱いに失敗したら、重複抑制 に切り替えることを考慮する必要があるかもしれません。そうすれば、Gnus はあなたが読んだすべての記事、あるいは既読の印を付けたすべての記事の Message-ID を記憶し、そしてまるで魔法のように、以後それらを読むときはいつでも既読の印が付いているようにします---すべて のグループで。この機構を使うのは何だかとても非効率になりそうですが、過度に非効率なわけではありません。同じ記事を二回以上読むよりは、間違い無く望ましいです。

重複抑制はあまり精密な道具ではありません。どちらかというと大槌のようなものです。それは非常に単純なやり方で動作しています---あなたが記事に既読の印を付けると、その Message-ID をキャッシュに加えます。次にその Message-ID に出会うと、M 印によって記事に既読の印を付けます。その記事をどのグループで見たかは気にしません。

gnus-suppress-duplicates
     nil でなければ、重複抑制をします。

gnus-save-duplicate-list
     nil でなければ、重複のリストをファイルに保存します。これは起動と終了の時間を長くするので、ディフォルト値は nil です。しかし、これは Gnus を一回実行したときに読まれた重複記事だけが抑制されるということです。

gnus-duplicate-list-length
     この変数はどのくらい多くの Message-ID を重複抑制リストに保っておくかを決定します。ディフォルトは 10000 です。

gnus-duplicate-file
     重複抑制のリストを格納しておくファイルの名前です。ディフォルトは ~/News/suppression です。

何度も Gnus を終了して起動する傾向があるのであれば、おそらく gnus-save-duplicate-list を t にするのは良い考えでしょう。もし Gnus を続けて何週間も走らせておくのであれば、それを nil にした方が良いかもしれません。一方、リストを保存することは起動と終了をずっと遅くするので、頻繁に Gnus を終了して起動するのであれば、 gnus-save-duplicate-list を nil に設定するべきです。うーむ。私はあなたがどうするかに任せようと思います。

セキュリティー
=======

Gnus は署名されたメッセージを検証したり、暗号化されたメッセージをデコードすることができます。PGP, PGP/MIME および S/MIME の形式をサポートしますが、それらを動作させるためには、いくつかの外部プログラムを必要とします:

 1. PGP と PGP/MIME のメッセージを扱うには、OpenPGP の実装である GnuPG のようなものをインストールしなければなりません。Gnus に含まれている GnuPG へのインターフェースは PGG というもの (see PGG (PGG Manual)) ですが、Mailcrypt と gpg.el もサポートします。

 2. S/MIME のメッセージを扱うには、OpenSSL をインストールする必要があります。OpenSSL 0.9.6 か、それより新しいものがお勧めです。

それらをどうやって設定するかについてのもっと詳しい情報が、message マニュアル (see セキュリティー (The Message Manual)) で見つかるでしょう。

mm-verify-option
     署名されたパートを検証するためのオプション。never は検証しない、 always はいつも検証する、known は知られたプロトコルの場合だけ検証する、の意味です。それら以外の場合は、どうするかを利用者に尋ねます。

mm-decrypt-option
     暗号化されたパートをデコードするためのオプション。never はデコードしない、always はいつもデコードする、known は知られたプロトコルの場合だけデコードする、の意味です。それら以外の場合は、どうするかを利用者に尋ねます。

mml1991-use
     PGP のメッセージのための、OpenPGP の実装への elisp インターフェースを示すシンボルです。ディフォルトは pgg ですが、反論があるものの mailcrypt と gpg もサポートします。

mml2015-use
     PGP/MIME のメッセージのための、OpenPGP の実装への elisp インターフェースを示すシンボルです。ディフォルトは pgg ですが、反論があるものの mailcrypt と gpg もサポートします。

メニュー項目やコマンドから OpenPGP の鍵を取得 (snarf) する (すなわち、記事から鍵を鍵束に輸入 (import) する) 機能は、明示的にはサポートされません。というよりはむしろ、あなたが適切だと思うどんな動作をも通常の MIME の機構を介して指定できるように、 Gnus は application/pgp-keys として鍵を検出し、ラベルを付けます。 MIME ボタンをクリック (see Using MIME) したときに、GNU Privacy Guard を使って鍵を輸入してくれるようにするには、以下のような行を ~/.mailcap ファイル (see mailcap (The Emacs MIME Manual)) に記入して下さい。

     application/pgp-keys; gpg --import --interactive --verbose; needsterminal

これは、たまたま mailcap-mime-data ですでに定義されている、ディフォルトの動作でもあります。

メーリングリスト
========

Gnus は RFC 2369 で既定された各種のメーリングリストで使われるフィールドを理解します。これを有効にするには概略バッファーで A M (gnus-mailing-list-insinuate) を使うなどして、 to-list グループパラメーター (see Group Parameters) を追加して下さい。

これによって概略バッファーでの以下の命令が使えるようになります。

C-c C-n h
     List-Help フィールドがあったら、メーリングリストのヘルプを取り寄せるためのメッセージを送信します。

C-c C-n s
     List-Subscribe フィールドがあったら、メーリングリストの講読を始めるためのメッセージを送信します。

C-c C-n u
     List-Unsubscribe フィールドがあったら、メーリングリストの講読をやめるためのメッセージを送信します。

C-c C-n p
     List-Post フィールドがあったら、メーリングリストに投稿します。

C-c C-n o
     List-Owner フィールドがあったら、メーリングリストの管理者宛てにメッセージを送信します。

C-c C-n a
     List-Archive フィールドがあったら、メーリングリストのアーカイブを閲覧します。

記事バッファー
*******

記事は一つしかない記事バッファーに表示されます。すべての概略バッファーは (Gnus に指示しない限り) 同じ記事バッファーを共有します。

余分なヘッダーを隠す
==========

各記事の頭の部分はヘッダー (head) と呼ばれます。(残りの部分はボディー (body) です。すでにお気づきでしょうが。)

ヘッダーにはたくさんの有益な情報が含まれています。記事を書いた人の名前、それが書かれた日付、および記事の表題です。これはとても良いのですが、ヘッダーには大部分の人にとっては見たくもない情報---記事があなたのところに着くまでにどんなシステムを経由してきたか、Message-ID、 References などなど…もううんざりするくらい---たくさん含まれています。たぶんあなたはこれらの行のいくつかは取り除いてしまいたいと思うでしょう。もしこれらの行をすべて記事バッファー内に残しておきたければ、 gnus-show-all-headers を t に設定して下さい。

Gnus はヘッダーを選り分けるために二つの変数を用意しています:

gnus-visible-headers
     この変数が nil 以外であれば、どのヘッダーを記事バッファーに残したいかを指定する正規表現であるとみなされます。この変数に合致しないヘッダーはすべて隠されます。

     例えば、記事を書いた人の名前と表題のみを見たければ、こう指定します:

          (setq gnus-visible-headers "^From:\\|^Subject:")

     この変数は、表示させたいヘッダーに合致する正規表現をリストで指定することもできます。

gnus-ignored-headers
     この変数は gnus-visible-headers の反対です。この変数が設定されていれば (かつ gnus-visible-headers が nil であれば)、これは隠したいヘッダー行すべてに合致する正規表現であるとみなされます。この変数に合致しないすべてのヘッダー行が表示されます。

     例えば、単に References 欄と Xref 欄のみを消し去りたければ、以下のようにします:

          (setq gnus-ignored-headers "^References:\\|^Xref:")

     この変数は消したいヘッダーに合致する正規表現のリストでも構いません。

     なお、gnus-visible-headers が nil 以外の場合は、この変数には効果が無いことに注意して下さい。

Gnus はヘッダーの並べ替え (sort) も行ないます (これはディフォルトで行なわれます)。この並べ替えは gnus-sorted-header-list 変数を設定することで制御することができます。これはヘッダーをどういう順序で表示するかを指定する正規表現のリストです。

例えば、記事の著者名を最初に、次に表題を表示したければ、こんな風になるでしょう。

     (setq gnus-sorted-header-list '("^From:" "^Subject:"))

表示するようになっているヘッダーでこの変数に指定されていないものは、この変数に指定されているすべてのヘッダーの後に、適当な順序で表示されるでしょう。

gnus-treat-hide-boring-headers を head に設定することによって、もっとつまらないヘッダーを隠すことができます。この関数が何をするかは gnus-boring-article-headers 変数に依存します。この変数はリストですが、このリストには実際のヘッダーの名前が入るのではありません。代わりに Gnus がチェックして視界から消し去るためのさまざまな「つまらない条件」 (boring conditions) のリストを指定します。

この条件には以下のようなものがあります。

empty
     空のヘッダーをすべて消去します。

followup-to
     Followup-To 欄が Newsgroups 欄と同一である場合には消去します。

reply-to
     Reply-To 欄が From 欄と同じアドレスを示しているか、 broken-reply-to グループパラメーターが設定されている場合には消去します。

newsgroups
     Newsgroups 欄が現在のグループ名しか含んでいない場合には消去します。

to-address
     To 欄が現在のグループの to-address パラメーターと同じものしか含んでいない場合には消去します。

to-list
     To 欄が現在のグループの to-list パラメーターと同じものしか含んでいない場合には消去します。

cc-list
     CC 欄が現在のグループの to-list パラメーターと同じものしか含んでいない場合には消去します。

date
     その記事が過去三日以内のものであれば、Date 欄を消去します。

long-to
     To 欄があまりにも長い場合には消去します。

many-to
     To 欄が一つよりも多ければ、それらをすべて消去します。

これらのうちの三つの要素を入れたければ、こんな風になります:

     (setq gnus-boring-article-headers
           '(empty followup-to reply-to))

これはこの変数のディフォルト値でもあります。

MIME を使う
========

パントマイム (mime) は、観客があくびをしながらぼんやりしているのにもかかわらず、意味も無く空中で手を振るものの標準として広く知られています。

一方 MIME は、そのためにすべてのニュースリーダが恐怖で死んでしまうのにもかかわらず、意味も無く記事をエンコードする標準です。

MIME は記事がどんな文字セットを使うか、文字をどうエンコードするかを指定することができ、さらには絵やその他のみだらなものを無邪気な格好の記事に埋め込むことさえ可能にします。

Gnus は MIME パートを表示するために、 gnus-display-mime-function によって MIME 記事を処理します。これはディフォルトでは gnus-display-mime で、 MIME オブジェクトを表示し、セーブし、かつ操作するために使うことができる、ひとかたまりのクリック可能なボタンを作成します。

MIME ボタンの上にポイントを置いたならば、以下のコマンドが利用できます:

RET (記事)
BUTTON-2 (記事)
     MIME オブジェクトの表示をトグルで切り替えます (gnus-article-press-button)。そのオブジェクトを内蔵のビューワーで表示できないときは、Gnus は mailcap ファイルにある外部のビューワーに助けを求めます。ビューワーが copiousoutput 仕様になっている場合は、オブジェクトはインラインで (訳注: Emacs の表示に埋め込まれて) 表示されます。

M-RET (記事)
v (記事)
     手段を尋ね、その手段を使って MIME オブジェクトを表示します (gnus-mime-view-part)。

t (記事)
     MIME オブジェクトを、異なる MIME メディア・タイプであるかのように表示します (gnus-mime-view-part-as-type)。

C (記事)
     文字セットを尋ね、その文字セットを使って MIME オブジェクトを表示します (gnus-mime-view-part-as-charset)。

o (記事)
     ファイル名を尋ねて MIME オブジェクトをセーブします (gnus-mime-save-part)。

C-o (記事)
     ファイル名を尋ね、MIME オブジェクトをセーブして、それを記事から取り外します (記事を編集することによって行なわれます)。取り外された MIME オブジェクトは message/external-body MIME タイプとして参照されるようになります (gnus-mime-save-part-and-strip)。

r (記事)
     ファイル名の入力を求めて、MIME オブジェクトを message/external-body 型の MIME 形式のファイルとして参照される外部にある本体で置き換えます。(gnus-mime-replace-part)。

d (記事)
     記事から MIME オブジェクトを取り外し、取り外したことを表す告知で置き換えます (gnus-mime-delete-part)。

c (記事)
     MIME オブジェクトを新たに作ったバッファーにコピーして、それを表示します (gnus-mime-copy-part)。接頭引数が与えられると、デコードせずに生の内容物をコピーします。数値の接頭引数を与えると、文字セットによるデコードを半手動で切り替えることができます (Paging the Article で述べられている gnus-summary-show-article-charset-alist を参照して下さい)。auto-compression-mode (see Accessing Compressed Files (The Emacs Editor)) が設定されていると、.gz や .bz2 のような圧縮されたファイルを自動的に解凍します。

p (記事)
     MIME オブジェクトを印刷します (gnus-mime-print-part)。このコマンドは .mailcap ファイルで定義された print= 仕様に従います。

i (記事)
     MIME オブジェクトの内容物を、その記事バッファーに text/plain として挿入します (gnus-mime-inline-part)。接頭引数が与えられると、デコードせずに生の内容物を挿入します。数値の接頭引数を与えると、文字セットによるデコードを半手動で切り替えることができます (Paging the Article で述べられている gnus-summary-show-article-charset-alist を参照して下さい)。 auto-compression-mode (see Accessing Compressed Files (The Emacs Editor)) の設定とは無関係に、.gz や .bz2 のような圧縮されたファイルを jka-compr を使って自動的に解凍します。

E (記事)
     内部ビューワーで MIME オブジェクトを表示します。内部ビューワーが使えないときは、外部ビューワーを使います (gnus-mime-view-part-internally)。

e (記事)
     外部ビューワーで MIME オブジェクトを表示します (gnus-mime-view-part-externally)。

| (記事)
     MIME オブジェクトをプロセスに出力します (gnus-mime-pipe-part)。

. (記事)
     MIME オブジェクトをどう処理するかを、対話的に決めて実行します (gnus-mime-action-on-part)。

Gnus はいくつかの種類の MIME オブジェクトを自動的に表示します。どのパートに対してそうするかを Gnus が決めるやり方については、 Emacs MIME マニュアルで述べられています。

不愉快なものでびっくりさせられるのを避けるには、トグルで切り替える関数を使うのが最も良いでしょう。 (例えば、alt.sing-a-long グループに入ると、あなたの気づかないうちに MIME は記事中のサウンドファイルをデコードして、何やら怪しげな長い長い歌があなたのスピーカーから大音響で流れ出し、あなたはボリュームボタンを見つけられず、というのはそんなものはもともと付いていないからで、みんなはあなたの方を睨みはじめ、あなたはプログラムを止めようとするけれどもできなくて、ボリュームを制御するプログラムも見つけられなくて、そして部屋中の全員は突然あなたのことを軽蔑の眼差しで見るようになってしまい、あなたはちょっと面白くない思いをする、とか)。

現実の出来事と実在の人物に類似しているかもしれませんが、これはすべてホントのことです。げほげほ。

MIME Commands も見て下さい。

記事のカスタマイズ
=========

記事をどのように見せるかをカスタマイズするためのたくさんの関数が存在しています。これらの関数を対話的に呼ぶこともできるし (see Article Washing)、記事を選択したときに自動的に選択することもできます。

自動的に呼ばれるようにするためには、対応するトリートメント変数を設定しなければなりません。例えばヘッダーを隠すためには、 gnus-treat-hide-headers を設定します。以下は設定できる変数の一覧ですが、まずこれらの変数の取り得る値について話しましょう。

注意: いくつかの値は、有効な値であってもほとんど意味を無しません。実用的な値は下の一覧を調べて下さい。

 1. nil: このトリートメントをしません。

 2. t: このトリートメントをすべての本文のパートで行ないます。

 3. head: ヘッダーでそのトリートメントをします。

 4. last: このトリートメントを最後のパートで行ないます。

 5. 整数: このトリートメントをこの数値より短いすべての本文のパートで行ないます。

 6. 文字列のリスト: このリストに含まれている正規表現に合致する名前のグループで読まれた記事の、すべての本文のパートでこのトリートメントを行ないます。

 7. 最初の要素が文字列でないリストです:

     リストは再帰的に評価されます。リストの最初の要素は述語です。以下の述語が認識されます: or, and, not, typep。例です:

          (or last
              (typep "text/x-vcard"))

ここで パート という語が使われていることに気付いたと思います。これはメッセージには MIME マルチパート記事があり、いくつかのパートに分割されているかもしれないという事実に関連しています。マルチパートでない記事は一つのパートのみであるとみなされます。

このトリートメントはすべてのマルチパートのパートたちに適用されるのでしょうか?  はい、そうしたければそうなります。ですが、ディフォルトでは text/plain パートだけにトリートメントが施されます。これは gnus-article-treat-types 変数で制御され、これはパートの型に合致する正規表現のリストです。制御変数の値が、上で説明されているように述語のリストであるときは、この変数は無視されます。

以下のトリートメントのオプションが使用可能です。これをカスタマイズするための最も簡単な方法は gnus-article-treat カスタマイズグループを調査することです。丸括弧の中の値は提案されている意味のある値です。他のものも可能ですが、ほとんどの人にとってはおそらくここに一覧表示されているもので十分でしょう。

gnus-treat-buttonize (t, integer)

gnus-treat-buttonize-head (head)

     See Article Buttons.

gnus-treat-capitalize-sentences (t, integer)

gnus-treat-overstrike (t, integer)

gnus-treat-strip-cr (t, integer)

gnus-treat-strip-headers-in-body (t, integer)

gnus-treat-strip-leading-blank-lines (t, integer)

gnus-treat-strip-multiple-blank-lines (t, integer)

gnus-treat-strip-pem (t, last, integer)

gnus-treat-strip-trailing-blank-lines (t, last, integer)

gnus-treat-unsplit-urls (t, integer)

gnus-treat-wash-html (t, integer)

     See Article Washing.

gnus-treat-date-english (head)

gnus-treat-date-iso8601 (head)

gnus-treat-date-lapsed (head)

gnus-treat-date-local (head)

gnus-treat-date-original (head)

gnus-treat-date-user-defined (head)

gnus-treat-date-ut (head)

     See Article Date.

gnus-treat-from-picon (head)

gnus-treat-mail-picon (head)

gnus-treat-newsgroups-picon (head)

     See Picons.

gnus-treat-display-smileys (t, integer)

gnus-treat-body-boundary (head)

     ヘッダーと本文の間に境界線を追加します。境界線には gnus-body-boundary-delimiter に設定された文字列が使われます。

     See Smileys.

gnus-treat-display-x-face (head)

     See X-Face.

gnus-treat-display-face (head)

     See Face.

gnus-treat-emphasize (t, head, integer)

gnus-treat-fill-article (t, integer)

gnus-treat-fill-long-lines (t, integer)

gnus-treat-hide-boring-headers (head)

gnus-treat-hide-citation (t, integer)

gnus-treat-hide-citation-maybe (t, integer)

gnus-treat-hide-headers (head)

gnus-treat-hide-signature (t, last)

gnus-treat-strip-banner (t, last)

gnus-treat-strip-list-identifiers (head)

     See Article Hiding.

gnus-treat-highlight-citation (t, integer)

gnus-treat-highlight-headers (head)

gnus-treat-highlight-signature (t, last, integer)

     See Article Highlighting.

gnus-treat-play-sounds

gnus-treat-translate

gnus-treat-ansi-sequences (t)

gnus-treat-x-pgp-sig (head)

gnus-treat-unfold-headers (head)

gnus-treat-fold-headers (head)

gnus-treat-fold-newsgroups (head)

gnus-treat-leading-whitespace (head)

     See Article Header.

もちろん、gnus-part-display-hook から呼ばれる自分用の関数を書くこともできます。関数はそのパートに範囲が狭められた状態で呼ばれ、ほとんどなんでも好きなことができます。バッファーに保存しておかなければならない情報はありません---何でも変えることができます。

記事のキーマップ
========

概略バッファーにおけるキー操作のほとんどは記事バッファーでも使用できます。これらは概略バッファーでそれらを押したかのように動作するはずです。つまり記事を読んでいる間、実際に概略バッファーを表示させておく必要がありません。すべての操作は記事バッファーから行なうことができるのです。

他にもいくつかのキーが利用できます。

SPACE
     記事を一ページ先にスクロールします。(gnus-article-next-page)。 h SPACE h とまったく同じです。

DEL
     記事を一ページ前にスクロールします (gnus-article-prev-page)。 h DEL h とまったく同じです。

C-c ^
     カーソルが Message-ID の近辺にあるときに C-c ^ を押すと、 Gnus はサーバーからその記事を取ってこようとします (gnus-article-refer-article)。

C-c C-m
     カーソルの近くにあるアドレスに返信を送ります (gnus-article-mail)。接頭引数を与えると、そのメールを引用します。

s
     バッファーを再配置して、概略バッファーが見えるようにします (gnus-article-show-summary)。

?
     利用できるキー操作のごく簡単な説明を出します (gnus-article-describe-briefly)。

TAB
     次のボタンがあればそこに移動します (gnus-article-next-button)。これは記事にボタンを付ける機能をオンにしているときのみ意味を持ちます。

M-TAB
     一つ前のボタンがあればそこに移動します (gnus-article-prev-button)。

R
     現在の記事に元記事を含んだ返答のメールを送ります (gnus-article-reply-with-original)。接頭引数を与えると広い返答 (wide reply) になります。もし領域が活性化されていたならば、その領域にあるテキストだけを yank します。

F
     現在の記事に元記事を含んでフォローアップをします (gnus-article-followup-with-original)。接頭引数を与えると広い返答 (wide reply) になります。もし領域が活性化されていたならば、その領域にあるテキストだけを yank します。

記事のその他
======

gnus-single-article-buffer
     nil 以外であれば、すべてのグループに対して同じ記事バッファーを使用します (これはディフォルトです)。nil であれば、各グループ毎の固有の記事バッファーを持つようになります。

gnus-article-decode-hook
     MIME 記事をデコードするときに使用されるフックです。ディフォルト値は (article-decode-charset article-decode-encoded-words) です。

gnus-article-prepare-hook
     このフックは記事が記事バッファーに挿入された直後に呼び出されます。これは主に、何か記事の内容に依存する処理をする関数のために用意されています。記事バッファーの内容を変更するような目的で使うべきではないでしょう。

gnus-article-mode-hook
     記事モードのバッファーで呼び出されるフックです。

gnus-article-mode-syntax-table
     記事バッファーで用いられるシンタックステーブルです。これは text-mode-syntax-table をもとに初期化されます。

gnus-article-over-scroll
     非-nil にすることによって、それ以上スクロールする新しいテキストが無くても記事バッファーをスクロールすることを可能にします。ディフォルトは nil です。(訳注: 記事の最下行が見えているときに、nil だと RET キーでそれ以上スクロールしませんが、非-nil にすると記事が見えなくなるまでスクロールします。)

gnus-article-mode-line-format
     この変数は gnus-summary-mode-line-format と同じ仕様に沿った様式文字列です (see Summary Buffer Mode Line)。これは、その変数と同じ様式指定および二つの拡張を受付けます。

     w
          記事の「洗濯状態」(wash status)。これは記事に対して行なわれたであろう洗濯操作を、それぞれ一文字で示す短い文字列になります。文字とそれらの意味は次の通りです:

          c
               記事バッファーにおいて、引用された文が隠されているかもしれない場合に表示されます。

          h
               記事バッファーにおいて、ヘッダーが隠されている場合に表示されます。

          p
               記事が電子署名または暗号化されていて、Gnus がセキュリティーのためのヘッダーを隠していると表示されます。(注: 署名が正しいか間違っているかを表すものではありません。)

          s
               記事バッファーにおいて、署名が隠されている場合に表示されます。

          o
               記事バッファーにおいて、Gnus が重ね打ち文字のトリートメントを行なった場合に表示されます。

          e
               記事バッファーにおいて、Gnus が強調された文字のトリートメントを行なった場合に表示されます。

     m
          記事の MIME パートの数です。

gnus-break-pages
     改ページ (page breaking) を行なうかどうかを制御します。この変数が nil 以外であれば、記事中にページ区切り文字が現れるごとにページ分割をします。この変数が nil であればページ分けは行なわれません。

gnus-page-delimiter
     これが上で触れた区切り文字です。ディフォルトでは ^L (フォームフィード) です。

gnus-use-idna
     この変数は From:、To: および Cc: ヘッダーにある国際化ドメイン名を、Gnus が IDNA デコードするかどうかを制御します。そのようなメッセージの作り方については see 国際化ドメイン名 (The Message Manual), を参照して下さい。これには GNU Libidn (http://www.gnu.org/software/libidn/) が必要で、この変数はそれをインストールしてある場合だけ有効になります。

メッセージの作成
********

すべての投稿とメールを送るためのコマンドは、あなたをメッセージバッファーに導きます。そこでは C-c C-c を押すことによって記事を送信する前に、記事を好きなように編集することができます。See Overview (Message Manual).  メッセージはあなたの設定に基づいて投稿またはメールとして送信されます (see Posting Server)。

投稿するべきでなかった記事を削除するための情報について Canceling and Superseding も参照して下さい。

メール
===

出て行くメールをカスタマイズする変数です:

gnus-uu-digest-headers
     要約メッセージ (digested message) に含まれるヘッダーに合致する正規表現のリストです。ヘッダーは合致した順に取り込まれます。nil だったら、すべてのヘッダーを含みます。

gnus-add-to-list
     nil でなければ、a を押したときに、to-list グループパラメーターをそれの無いメールグループに付け加えます。

gnus-confirm-mail-reply-to-news
     非-nil だったら、あなたがニュース記事への返答をメールでしようとすると Gnus は確認を求めます。nil ならば、あなたがやりたいことに何も口出ししません。これは関数か正規表現であることもできます。関数は唯一のパラメーターとしてグループ名を受け取り、確認する必要がある場合に非-nil を返します。これを正規表現にすると、それに合致する名前のグループで確認を求めます。

     メールで返信する気は無いのに時たまぞんざいに R を押してしまう癖があるならば、この変数はそんなあなたのためにあります。

gnus-confirm-treat-mail-like-news
     非-nil だったら、Gnus はメールに返信する時にも gnus-confirm-mail-reply-to-news に基づいた確認を求めます。これはメーリングリストをニュースグループのように扱うのに便利です。

投稿するサーバー
========

最新の (もちろん、非常に知的な) 記事を送り出すために、あの魔法のような C-c C-c キーを押した時、それはどこにいくのでしょう?

尋ねてくれてありがとう。あなたを恨みます。

それは非常に複雑になり得ます。

ニュースを投稿するとき、通常 Message は message-send-news を呼び出します (see ニュース変数 (The Message Manual))。普通は、Gnus は講読用と同じ選択方法を使って投稿します (このことは、あなたがたくさんのグループを異なったサーバーで講読している場合に、たぶん都合が良いのです)。しかし、あなたが講読しているそのサーバーが投稿を許可せず、読むことのみを許可しているのならば、おそらくあなたの (非常に知的でとんでもなく興味深い) 記事を投稿するために、他のサーバーを使いたいと思うでしょう。そうならば gnus-post-method を他の方法に設定することができます:

     (setq gnus-post-method '(nnspool ""))

さて、この設定をした後でサーバーがあなたの記事を拒否したり、サーバーが落ちていたりしたら、どうしたらよいのでしょう? この変数よりも優先させるために C-c C-c 命令にゼロでない数の接頭引数を与えることによって、投稿に ``current'' (現在の) サーバーを使わせること、すなわちディフォルトの動作 (訳注: gnus-post-method のディフォルト値は current) に戻すことができます。

もし、ゼロを接頭引数をその命令に与えたなら (すなわち、C-u 0 C-c C-c)、Gnus は投稿にどの方法を使うかをあなたに尋ねます。

gnus-post-method を選択方法のリストにすることもできます。その場合は、Gnus は常に投稿にどの方法を使うかをあなたに尋ねます。

最後に、あなたがいつでも基本の選択方法を使って投稿したいのならば、この変数を native にして下さい。

メールを送信するときに、Message は message-send-mail-function を呼び出します。ディフォルトの関数 message-send-mail-with-sendmail は記事を順番待ちに入れ (queuing) たり送信するために、記事を sendmail コマンドにパイプします。ローカルシステムが sendmail でメールを送信するように設定されていなくても、あなたが遠隔 SMTP サーバーに接続する権利を持っているならば、 message-send-mail-function を smtpmail-send-it に設定することができます。smtpmail パッケージを使うために正しい設定がなされているかどうか確認して下さい。例です:

     (setq message-send-mail-function 'smtpmail-send-it
           smtpmail-default-smtp-server "YOUR SMTP HOST")

これと似たものに message-smtpmail-send-it があります。 ISP が POP-before-SMTP の認証を要求している場合に有用です。See POP before SMTP.

他の可能な message-send-mail-function の選択肢には message-send-mail-with-mh, message-send-mail-with-qmail および feedmail-send-it があります。

POP before SMTP
===============

あなたの ISP は POP-before-SMTP 認証を要求しますか? それは、メールを送信する前の一定時間以内に POP メールサーバーに接続しなければならないかどうかです。もしそうならば、便利な手があります。それには ~/.gnus.el ファイルに以下の行を入れて下さい:

     (setq message-send-mail-function 'message-smtpmail-send-it)
     (add-hook 'message-send-mail-hook 'mail-source-touch-pop)

これは、メールを送信するときはいつでも Gnus に前もって POP メールサーバーに接続させることを意味します。関数 mail-source-touch-pop は、メールを送信する直前に、メールを取得せずに mail-sources の値に従って POP 認証だけを行ないます。smtpmail-send-it ではなくて、message-send-mail-hook を実行する message-smtpmail-send-it を使わなければならないことと、 POP 接続のために mail-sources の値を正しく設定しなければならないことに注意して下さい。See Mail Sources.

もし mail-sources に二つ以上の POP メールサーバーを設定しているならば、それらの一つを POP-before-SMTP 認証に使われる POP メールサーバーとして mail-source-primary-source に設定する必要があるでしょう。それが第一 POP メールサーバーならば (すなわち、主にそのサーバーからメールを取得しているならば)、それを以下のように恒久的に設定することができます:

     (setq mail-source-primary-source
           '(pop :server "pop3.mail.server"
                 :password "secret"))

さもなければ、POP-before-SMTP 認証を行なうときだけ、それを以下のように動的に束縛して下さい:

     (add-hook 'message-send-mail-hook
               (lambda ()
                 (let ((mail-source-primary-source
                        '(pop :server "pop3.mail.server"
                              :password "secret")))
                   (mail-source-touch-pop))))

メールと投稿
======

これはメールの送信とニュースの投稿の両方に関連する変数のリストです:

gnus-mailing-list-groups
     あなたのニュースサーバーが、本当にメーリングリストの記事を NNTP サーバーに流し込むゲートウェイによって、それらがニュースグループの記事として見えるようにしているのであれば、それらのグループは問題なく読めるでしょう。しかしいくらか面倒なことを克服すること無しに、それらに投稿またはフォローアップすることはできません。一つの解決法は、グループパラメーター (see Group Parameters) に to-address を加えることです。簡単にできるのは、gnus-mailing-list-groups を、本当はメーリングリストであるグループに合致する正規表現に設定することです。そうすれば、少なくともメーリングリストへのフォローアップはたいていのときに行なうことができるでしょう。これらのグループに投稿すること (a) は、それでも苦痛を引き起こすでしょうけれど。

gnus-user-agent
     この変数は、どの情報が User-Agent ヘッダーに陳列されるかを制御します。それは次のシンボルまたは文字列のうちのどれかであることができます: gnus (Gnus のバージョンのみ)、 emacs-gnus (Emacs と Gnus のバージョンだけ)、 emacs-gnus-config (emacs-gnus と同じ＋システム構成)、 emacs-gnus-type (emacs-gnus) と同じ＋システムタイプ) または好みの文字列。これを文字列にするときは、正しいフォーマットになっていることを確かめて下さい (RFC2616 参照)。

あなたは自分が送るメッセージで、綴りをチェックしたいかもしれません。もしくは手で綴りのチェックをしたくないのであれば、自動綴りチェックを ispell パッケージを使うことによって付け加えることができます:

     (add-hook 'message-send-hook 'ispell-message)

ispell の辞書をグループに応じて切り替えたいならば、以下のようにすれば良いでしょう。

     (add-hook 'gnus-select-group-hook
               (lambda ()
                 (cond
                  ((string-match
                    "^de\\." (gnus-group-real-name gnus-newsgroup-name))
                   (ispell-change-dictionary "deutsch"))
                  (t
                   (ispell-change-dictionary "english")))))

あなたの必要に応じて変更して下さい。

メッセージの保管
========

Gnus はあなたが送ったメールとニュースを貯めておくためのいくつかの違った方法を提供します。ディフォルトの方法はメッセージを保存するために アーカイブ仮想サーバー を使うことです。これを完全に禁止したいのであれば、変数 gnus-message-archive-group を nil にしなければなりません。それがディフォルトです。

グループで読んだ興味のあるメッセージの保存については、B c (gnus-summary-copy-article) コマンドを参照して下さい (see Mail Group Commands)。

gnus-message-archive-method は、送ったメッセージを蓄積するためにどの仮想サーバーを Gnus が使うかを指定します。ディフォルトは:

     (nnfolder "archive"
               (nnfolder-directory   "~/Mail/archive")
               (nnfolder-active-file "~/Mail/archive/active")
               (nnfolder-get-new-mail nil)
               (nnfolder-inhibit-expiry t))

しかし、どのメール選択方法でも使うことができます (nnml, nnmbox などなど)。しかし nnfolder はこのようなことをするのにとても好ましい選択方法です。ディフォルトで選択されるディレクトリーを好きでないならば、次のようにできます:

     (setq gnus-message-archive-method
           '(nnfolder "archive"
                      (nnfolder-inhibit-expiry t)
                      (nnfolder-active-file "~/News/sent-mail/active")
                      (nnfolder-directory "~/News/sent-mail/")))

訳注: 上記のような例は「意図した通りに動作しない」FAQ のネタになりつつあり、不具合の原因が特定できない事例が少なくありません。例えば、同じ "archive" という名前の仮想サーバーを過去に使ったことがあると、それが ~/.newsrc.eld ファイルの中で gnus-server-alist 変数に登録されているかもしれません。それを削除するには ~/.newsrc.eld ファイルを手作業で書き換えなければなりませんが、かなり危険です。あるいは単に、同名の仮想サーバーを現在も使っているかもしれません。そのような場合は、別の名前を使う必要があります。

Gnus は外へ出て行くすべてのメッセージに、 gnus-message-archive-method で指定されたアーカイブ仮想サーバーにある (あるいはそれ以外のサーバーにある) 一つかそれ以上のグループに保存することを意図した Gcc 欄を挿入します。どのグループを使うかは変数 gnus-message-archive-group によって決まります。

この変数 (gnus-message-archive-group) は次のようなことをするために使うことができます:

文字列
     メッセージはそのグループに保存されます。

     グループ名に選択方法を含めることができますが、そうするとそのメッセージは gnus-message-archive-method で指定した選択方法ではなくて、代わりにグループ名の選択方法で保存されることに注意しましょう。 gnus-message-archive-method は、上に示したようなディフォルト値を持つためものであると考えて下さい。ですから gnus-message-archive-group を "foo" にしておけば、外へ出て行くメッセージは nnfolder+archive:foo に保存されますが、 "nnml:foo" という値を使うと、外へ出て行くメッセージは nnml:foo に保存されるでしょう。

文字列のリスト
     メッセージはそれらのすべてのグループに保存されます。

正規表現、関数、Lisp フォームの連想リスト
     キーが『合致』すると、その結果が使われます。

     訳注: 正確には以下の三種類です。

       * 正規表現とグループ名 (または複数のグループ名リスト) の連想リスト。最初に正規表現が合致した要素のグループ名 (またはグループ名のリスト) が使われます。

       * 関数のリスト。それぞれの関数には現在のグループ名が引数として与えられ、最初に返ってきた nil 以外の値が使われます。

       * Lisp フォームのリスト。それぞれのフォームが評価され、最初に返ってきた nil 以外の値が使われます。

nil
     メッセージの保存は行なわれません。これがディフォルトです。

例をあげてみましょう:

MisK という単一のグループに保存するだけならば:

     (setq gnus-message-archive-group "MisK")

二つのグループ、MisK と safe に保存するならば:

     (setq gnus-message-archive-group '("MisK" "safe"))

どのグループにいるかによって違ったグループに保存するなら:

     (setq gnus-message-archive-group
           '(("^alt" "sent-to-alt")
             ("mail" "sent-to-mail")
             (".*" "sent-to-misc")))

もっと複雑なもの:

     (setq gnus-message-archive-group
           '((if (message-news-p)
                 "misc-news"
               "misc-mail")))

すべてのニュースメッセージを一つのファイルに保存して、メールメッセージを一月につき一つのファイルに保存するというのはどうでしょう:

     (setq gnus-message-archive-group
           '((if (message-news-p)
                 "misc-news"
               (concat "mail." (format-time-string
                                "%Y-%m" (current-time))))))

さあ、メッセージを送ると適切なグループに保存されるようになりました。(もし特定のメッセージを保存をしたくないのであれば、挿入された Gcc 欄を取り除いて下さい。)  保管グループは次に Gnus を起動したときか、次にグループバッファーで F を押したときにグループバッファーに現れます。他のグループと同じように、そのグループに入って記事を読むことができます。そのグループが本当に大きくて悩ましくなったら、なにか良いものにその名前を変更することができます (グループバッファーで G r を使うことによって)---misc-mail-september-1995 その他何でも。新しいメッセージは古い (今は空になった) グループに溜められます。

以上が送ったメッセージを保管するディフォルトの方法です。Gnus はディフォルトの方法を好きではない人には違ったやり方を勧めています。そのような場合は、gnus-message-archive-group を nil に設定するべきです。これは保管をしないようにします。

gnus-outgoing-message-group
     すべての外にいくメッセージはこのグループに入れられます。もしすべての外に行くメールと記事を nnml:archive グループに保管したいのであれば、この変数をその値に設定して下さい。この変数はグループ名のリストであることもできます。

     もしそれぞれのメッセージをどのグループに入れるかをもっと制御したいのであれば、この変数を現在のニュースグループ名を調べて、適切なグループ名 (もしくは名前のリスト) を返す関数に設定することができます。

     この変数は gnus-message-archive-group の代わりに使うことができますが、後者の方が好ましい方法です。

     (訳注:「後者」とは gnus-message-archive-group のこと。前者より四ヶ月遅れて、1996年1月に新設されました。)

gnus-gcc-mark-as-read
     もし非-nil なら、Gcc の記事に既読の印を付けます。

gnus-gcc-externalize-attachments
     nil だったら、ファイルを通常のパートとして Gcc で保存する記事のコピーに添付します。それが正規表現で Gcc のグループ名に合致する場合は、外部パートとしてファイルを添付します。all だったらローカルファイルを参照する外部パートとして添付します。それが別の非-nil だった場合の動作は all のときと同じですが、将来は変わるかもしれません。

     (訳注: 送信したメッセージと同じものを Gcc で保存する代わりに、添付ファイルをメッセージから切り離して、別にセーブするかどうかを制御する変数です。)

投稿様式
====

それらはすべて変数で、私の頭をくらくらさせます。

投稿するグループによって違った Organization と署名を付けたいんですか?  そして、家のマシンと職場のマシンの両方から投稿するけれども、違った From 行などを使いたいんですか?  そんなこと、どうでもいいじゃありませんか。

そのようなことをする方法の一つは、変更する必要のある変数を変更する賢いフックを書くことです。それは少し退屈なので、利用者にこれらのことを手軽な連想リストで指定するというすばらしい着想にたどり着いた人がいました。これが変数 gnus-posting-styles の例です:

     ((".*"
        (signature "Peace and happiness")
        (organization "What me?"))
      ("^comp"
       (signature "Death to everybody"))
      ("comp.emacs.i-love-it"
       (organization "Emacs is it")))

この例から推測されるように、この連想リストはいくつかの 様式 (style) からなっています。それぞれの様式は最初の要素が何らかの形で ``合致'' したときに適用されます。連想リスト全体は最初から最後まで反復して実行され、それぞれの合致が適用されます。これは、後の様式の属性が前に合致した様式の属性よりも優先されるということです。ですから comp.programming.literate は、Death to everybody という署名と What me? という Organization ヘッダーを持ちます。

それぞれの様式の最初の要素は マッチ (match) と言います。もしそれが文字列であれば、Gnus はそれを正規表現であるものとして、グループ名に合致するかどうかを調べます。(header 合致 正規表現) という形式であれば、Gnus は元記事の中からその名前が 合致 であるヘッダーを探し、それを 正規表現 と比較します。合致 と 正規表現 は文字列です。(元記事とは、あなたがそれに対して返信またはフォローアップしようとしている対象の記事です。返信あるいはフォローアップを作成していなければ、合致するものは何もありません。) もし マッチ が関数のシンボルであれば、その関数が引数無しで呼ばれます。それが変数のシンボルであれば、その変数が参照されます。それがリストであれば、そのリストが 評価 されます。どの場合でも、これが nil でない値を返せば、様式は 合致した と言います。

それぞれの様式は任意の量の 属性 を持つことができます。それぞれの属性は (NAME VALUE) の対により成り立っています。加えて (NAME :file VALUE) の形式か (NAME :value VALUE) の形式を使うこともできます。ここで :file は VALUE がファイル名を表して、その内容が属性値として使用されるべきであることを示し、:value は VALUE がファイル名を表わさないことを明示的に示します。属性名 (NAME) は、以下のどれかであることができます。

  * signature

  * signature-file

  * x-face-file

  * address (user-mail-address よりも優先されます)

  * name ((user-full-name) よりも優先されます)

  * body

属性名は文字列またはシンボルであることもできます。その場合それはヘッダー名として使われ、その値が記事のヘッダーに挿入されます。もし属性名が nil だったら、そのヘッダー名は削除されます。もし属性名が eval だったらその様式が評価され、結果は捨てられます。

属性値は文字列 (そのまま使われます)、引数の無い関数 (返り値が使われます)、変数 (その値が使われます) またはリスト (それは 評価 されて、返り値が使われます) であることができます。関数と S式 (sexp) はセットアップされつつあるメッセージバッファーで呼ばれるか評価されます。現在の記事のヘッダー群は変数 message-reply-headers から得られます。これは number subject from date id references chars lines xref extra の各ヘッダーから成るベクトルです。

作成しようとしているメッセージがニュース記事かメールメッセージであるかを調べたいときは、関数 message-news-p と message-mail-p の戻り値を調べて下さい。

そして、これは例です:

     (setq gnus-posting-styles
           '((".*"
              (signature-file "~/.signature")
              (name "User Name")
              ("X-Home-Page" (getenv "WWW_HOME"))
              (organization "People's Front Against MWM"))
             ("^rec.humor"
              (signature my-funny-signature-randomizer))
             ((equal (system-name) "gnarly")  ;; 様式
              (signature my-quote-randomizer))
             (message-news-p        ;; 関数シンボル
              (signature my-news-signature))
             (window-system         ;; 変数シンボル
              ("X-Window-System" (format "%s" window-system)))
             ;; Lars さんに返事をするときは
             ;; Organization ヘッダーを付けよう。
             ((header "to" "larsi.*org")
              (Organization "Somewhere, Inc."))
             ((posting-from-work-p) ;; 利用者が定義した関数
              (signature-file "~/.work-signature")
              (address "user@bar.foo")
              (body "You are fired.\n\nSincerely, your boss.")
              (organization "Important Work, Inc"))
             ("nnml:.*"
              (From (save-excursion
                      (set-buffer gnus-article-buffer)
                      (message-fetch-field "to"))))
             ("^nn.+:"
              (signature-file "~/.mail-signature"))))

nnml:.* の規則は、あなたが出すすべての返事の To アドレスを From アドレスとして使うことを意味します。これは、あなたがたくさんのメーリングリストに参加している場合に便利でしょう。

下書き
===

メッセージ (メールもしくはニュース) を書いているときに、オーブンにステーキが入っている (もしくはあなたがとーってもすごい菜食主義者で、何かのペーストがフードプロセッサーに入っている) ことを突然思い出したなら、書いているメッセージを保存する方法があれば良いと思うでしょう。いつか別の日に編集を続けることができ、それが完成したと思ったときに送ることができるように。

えぇ、心配しないで下さい。メールかニュースを送信するための Gnus の命令を使って何らかのメッセージを書き始めたときにあなたが手にするバッファーは、自動的に特別な draft グループに関連付けられます。普通の方法  (例えば C-x C-s) でバッファーを保存すれば、その記事はそこに保存されます。 (自動保存 (auto-save) ファイルも下書きグループ (draft group) に行きます。)

下書きグループは nndraft:drafts と呼ばれる特別なグループです (あなたが絶対に知っていなければならないのであれば、それは nndraft グループとして実装されています)。変数 nndraft-directory は nndraft がそのファイルをどこに保管するかを指定します。このグループを特別なものにしているのは、その中の記事に可視や既読の印を付けることができないことです---そのグループのすべての記事は永久に未読です。

もしグループが存在しないと、それは作成され、購読させられます。グループバッファーからそれを消し去る唯一の方法は、それを購読しないようにすることです。下書きグループの特別の特性はグループの特性 (see Group Parameters) によって生じ、それが失われてしまうと他のグループのように振る舞うようになります。これは (グループの特性を消してしまうことは) 以下のコマンドが使えないことを意味します。そのグループの特別の特性を復活させる最も簡単な方法は、 C-k でそのグループを削除してから Gnus を再起動することです。そのグループの内容物は失われません。

記事の編集を続けたいときは、下書きグループに入って D e (gnus-draft-edit-message) を押すだけです。編集を中断したときの状態のバッファーに移動します。

送信を拒否された記事も、この下書きグループに入れられます (see Rejected Articles)。

送信を拒否されたメッセージがたくさんあって、それ以上編集せずにそれらを送信したい場合は、D s 命令を使うことができます。この命令はプロセス/ 接頭引数の習慣を理解します (see Process/Prefix)。D S 命令 (gnus-draft-send-all-messages) はバッファーのすべてのメッセージを送り出します。

送りたくないメッセージがいくつかあるのであれば、D t 命令 (gnus-draft-toggle-sending) を使ってメッセージに送信不可の印を付けることができます。これは切り替え命令です。

拒否された記事
=======

時々ニュースサーバーは記事を送信することを拒否します。おそらくサーバーはあなたの顔を好きではないのでしょう。おそらく落ち込んでいるのでしょう。おそらく 悪魔 (demon) がいるのでしょう。おそらく引用文を入れすぎたのでしょう。おそらくディスクが一杯だったのでしょう。おそらくサーバーが落ちていたのでしょう。

もちろんこれらの状況は完全に Gnus の扱える範囲外です。(もちろん Gnus はあなたの風貌を愛しているし、いつも機嫌が良いし、中を飛び回る天使がいて、どれくらい引用文が含まれていようと気にせず、一杯になったり、落っこちたりしません。) ですから Gnus はこれらの記事を後でサーバーの機嫌が良くなるまで保存します。

拒否された記事は自動的に特別な下書きグループ (see Drafts) に入れられます。サーバーが復旧した暁には、普通あなたはそのグループに入って、すべての記事を送ることになるでしょう。

署名と暗号化
======

素の PGP 形式、PGP/MIME または S/MIME を使って、Gnus はメッセージに電子署名したり暗号化することができます。そのようなメッセージのデコードに関しては、mm-verify-option オプションおよび mm-decrypt-option オプション (see Security) を参照して下さい。

署名したメッセージを送ってきた人たちに、署名した返信を返したいことはしばしばあります。さらに暗号化されたメッセージへの返信を暗号化したいことは、もっとたびたびあるかもしれません。Gnus は前者のために gnus-message-replysign の機能を、後者のために gnus-message-replyencrypt の機能を提供します。さらに gnus-message-replysignencrypted を設定することによって (ディフォルトで on になっています)、暗号化したメッセージに自動的に署名もします。

MIME パートに対してセキュリティーの操作を行なうための MML への指示は、以下のように署名の場合は C-c C-m s キーマップを使って、暗号化の場合は C-c C-m c キーマップを使って行ないます。

C-c C-m s s

     S/MIME を使って現在のメッセージに電子署名します。

C-c C-m s o

     PGP を使って現在のメッセージに電子署名します。

C-c C-m s p

     PGP/MIME を使って現在のメッセージに電子署名します。

C-c C-m c s

     S/MIME を使って現在のメッセージを電子暗号化します。

C-c C-m c o

     PGP を使って現在のメッセージを電子暗号化します。

C-c C-m c p

     PGP/MIME を使って現在のメッセージを電子暗号化します。

C-c C-m C-n
     メッセージから、セキュリティー関連の MML タグを外します。

もっと詳しいことは see セキュリティー (The Message Manual), を参照して下さい。

選択方法
****

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

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

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

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

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

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

サーバーバッファー
=========

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

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

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

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

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

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

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

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

n
     サーバーの名前。

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

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

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

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

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

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

S
     サーバー名。

M
     サーバーの選択方法。

Formatting Variables も参照して下さい。

サーバー命令
------

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

e
     サーバーを編集します (gnus-server-edit-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)。これは同期が外れてしまったメールバックエンドがあるときに役に立ちます。

方法の例
----

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

     (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 して、そこから NNTP サーバーに telnet をするように Gnus に指示することができます。こんなことをするのはいささかばかげているのですが、でも仮想サーバーの定義はおそらくこのようなものになるはずです:

     (nntp "firewall"
           (nntp-open-connection-function nntp-open-via-rlogin-and-telnet)
           (nntp-via-address "the.firewall.machine")
           (nntp-address "the.real.nntp.host")
           (nntp-end-of-line "\n"))

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

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

nntp-via-rlogin-command-switches も参照して下さい。

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

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

もちろん、自動認証を行なわせるためには ssh-agent を適切に設定しなければなりません。加えて、通信内容を圧縮するためには、ssh の config ファイルに Compression オプションが存在しなければなりません。

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

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

最初に新しいサーバーを追加する必要があります。それをするのは 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 を押すと、閲覧バッファーに入って、表示されているどのグループにでも入ることができるはずです。

サーバー変数
------

変数を (バックエンドと 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"))

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

サーバーと選択方法
---------

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

使用不可能なサーバー
----------

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

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

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

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

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)。

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

ニュースの取得
=======

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

NNTP
----

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

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

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

以下の変数は仮想 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 に接続したときに毎回ビープ音を鳴らさせたい (beep) のであれば、次のようにすることができます:

          (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-server-hook
     このフックは NNTP サーバーに接続する最後の一歩として実行されます。

nntp-buggy-select
     あなたの選択の一連の作業が故障がちであるときにこれを 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 行を取得することになります。この変数は XOVER 要求がどれくらい大きな二つの連続した記事群の間のへだたり (gap) まで分割されないで送られるかを決定します。ネットワークが速い場合は、この変数を本当に小さな数値に設定するとおそらく取得が遅くなるということに注意して下さい。この変数が nil であると、 nntp は要求を分割しません。ディフォルトは 5 です。

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

nntp-warn-about-losing-connection
     この変数が nil でないと、サーバーが接続を閉じたときに少し雑音がたてられます。

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

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

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-read-timeout
     Nntp が出力が終了したことを確認するために待つべき時間です。値を短くすれば反応が速くなりますが CPU を食います。ディフォルトは 0.1 秒です。サーバーに遅い回線で接続している場合は (そして Emacs が CPU パワーを食うのを望まなければ)、これを例えば 1 にしても構いません。

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

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

nntp-open-network-stream
     これはディフォルトで、単純に遠隔システムのポートなどに接続します。

nntp-open-tls-stream
     安全な チャンネルを使ってサーバーに接続します。これを使うためには GNUTLS (http://www.gnu.org/software/gnutls/) をインストールしておかなければなりません。それからサーバーを次のように定義します:

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

nntp-open-ssl-stream
     安全な チャンネルを使ってサーバーに接続します。これを使うためには OpenSSL (http://www.openssl.org) または SSLeay (ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL) をインストールしておかなければなりません。それからサーバーを次のように定義します:

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

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

     Emacs のセッション全体をラップして、ディフォルトのメソッドを使うというのは、良い考えではありません。

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

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

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

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

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

     nntp-via-rlogin-command-switches
          nntp-via-rlogin-command のコマンドのスイッチとして使われる文字列のリストです。ディフォルトは nil です。もし ssh を nntp-via-rlogin-command の値として使うならば、データ接続を圧縮するために ("-C") を使うことができます。あるいは、もし中間のホストで telnet コマンドが疑似端末を必要とするならば、これを ("-t" "-e" "none") または ("-C" "-t" "-e" "none") にして下さい。

     nntp-end-of-line の値を \n に変更する必要があるであろうことに注意して下さい (see Common Variables)。

nntp-open-via-rlogin-and-netcat
     本質的には同じことなのですが、中間のホストから本当の NNTP サーバーに接続するために、telnet の代わりに netcat (http://netcat.sourceforge.net/) を使います。

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

     nntp-via-netcat-command
          中間のホストから本当の NNTP サーバーに接続するために使われるコマンドです。ディフォルトは nc です。代わりに connect (http://www.imasy.or.jp/~gotoh/ssh/connect.html) のような、他のコマンドを使うこともできます。

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

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

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

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 Common Variables)。

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

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

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

共通の変数
.....

以下の変数は、すべての、またはいくつかのあらかじめ用意されている関数の動作に影響を及ぼします。設定されていなければ、すべての関数が影響されます。

nntp-pre-command
     素の接続用の関数 (nntp-open-network-stream、nntp-open-tls-stream および nntp-open-ssl-stream だけだと思う) ではないものを通して接続するときに使うコマンドラッパーです。例えばあなたは SOCKS ラッパーを割り当てるでしょう。

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-telnet-command
     telnet を通して NNTP サーバーと接続するときに使うコマンドです。これは中間のホストと接続するためのものでは ありません。これは単に本当の NNTP サーバーと接続するためのものです。ディフォルトは telnet です。

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

NNTP marks
..........

Gnus は NNTP サーバー用の印 (marks) を印ファイルに保存します。印ファイルはあるグループで設定した印を記録し、それぞれのファイルは、対応するサーバーのそれぞれに対して専用です。印ファイルは、ニュースサーバーに似ている古典的な階層で ~/News/marks (nntp-marks-directory) に保存されます。例えば news.gmane.org サーバーにおける gmane.discuss グループのための印ファイルは ~/News/marks/news.gmane.org/gmane/discuss/.marks に保存されます。

印ファイルは役に立ちます。~/News/marks ディレクトリーは (rsync、 scp または他の何かを使って) Gnus を走らせる別のホストにコピーすることができ、どの記事を読んで印を付けたかをそちらで再現します。 ~/News/marks のデータは、~/.newsrc.eld にある同じものよりも優先されます。

印ファイルは、それぞれのサーバーごとに非常に特化されることに注意して下さい。Gnus は記事番号を記憶するので、両方のホストで同じサーバーを使っていないと、ものごとは壊れてしまうでしょう (大抵のサーバーは他のどんなサーバーとも同じ記事番号を使いません)。しかし、あるホストでサーバー A、B、C を使い、別のホストでサーバー A、D、E を使う場合には、A のための印ファイルを同じにすることができ、二つのホスト間でそのサーバーは同期します。

NNTP 印の使用は性能の劣化を招き、Gnus をのろく感じさせる可能性があります。そういう場合は nntp-marks-is-evil 変数を t に設定してみて下さい。すると、印は ~/.newsrc.eld (だけ) に格納されるでしょう。

関連する変数:

nntp-marks-is-evil
     非-nil だったら、このバックエンドは印ファイルを無視します。ディフォルトは nil です。

nntp-marks-directory
     NNTP グループの印が格納されるディレクトリーです。

ニューススプール
--------

ローカルスプールから外部グループを購読することは非常に簡単で、役に立ちます。たとえば、非常に大きな記事があるグループ---例えば alt.binaries.pictures.furniture を読む速度が速くなります。

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

もしローカルスプールにつなぐことが可能なら、おそらくそれを基本選択方法として使うべきでしょう (see Finding the News)。それは普通は 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
     グループ記述ファイルの名前です。

nnspool-history-file
     ニュース履歴ファイルの名前です。

nnspool-active-times-file
     現状日付ファイルへの名前です。

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

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

メール取得
=====

ニュースリーダーでメールを読む---それは明白に超自然的なことではないのですか? いや、もちろんできます。

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

あなたが伝統的なメールリーダから Gnus に乗り換えることを決断したならば、あなたはいろいろなカルチャーショックを受けることでしょう。

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

Gnus はふつう同じ手法ですべてのグループを扱います。あなたはあるグループを選んで新しい/未読の記事を読む、そして読んだ記事は既読としてマークされる。あなたが目にするのは (あなたが意図的に尋ねなければ) それだけです。これってとてもニュースリーダ的でしょ。

あなたは記事を消すために特別な操作はしません。

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

そうではありません。古い記事はいろんな仕組みによって expire されるのです。ニュース記事はニュースの管理人 (が管理しているサーバー) によって expire の処理が制御され、メールの expire の処理はあなたが制御します。メールの expire については Expiring Mail を参照して下さい。

しばらくメールとニュースの両方を使ってみれば、記事の取り扱いについて配送の機構が行なうことはわずかであることに気が付きます。

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

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

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

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

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

脅かすわけではないのですが、はっきりさせておきたいのは、あなたに記事についての新しいやり方を修得して欲しいということです。あなたが Gnus のやり方を受け入れてくれた暁には、きっとあなたは Gnus が好きになること請け合いです。

(少くとも、私が Gnus に入れた、Emacs のサブリミナル脳味噌洗濯関数を売ってくれた人はそれを保証しています。あなたも同化します。あなたは Gnus を愛します。あなたは 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 でメールを読むために充分であるはずです。マニュアルのこの部分の他の項を熟読する必要があるかもしれませんが。特に Choosing a Mail Back End と Expiring Mail を。

メールの分割
------

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

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

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

     ("list.\\1" "From:.* \\(.*\\)-list@majordomo.com")

この場合、挿入されるテキストを小文字にすべきかどうかを nnmail-split-lowercase-expanded が制御します。See Fancy Mail Splitting.

二番目の要素は関数であることもできます。その場合は、それは法則の最初の要素を引数として、ヘッダーに範囲を狭めて (narrowed to headers) 呼ばれます。それは、メールがそのグループに属すると考えるのであれば、nil でない値を帰す必要があります。

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

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

すべてのメールバックエンドは、入って来た貧乏で純粋なヘッダーを乱暴に扱っても良いことに注意して下さい。それらはすべて Lines ヘッダーを追加します。いくつかは X-Gnus-Group ヘッダーを加えます。たいていのものは Unix の mbox の From<SPACE> 行を何か別の名前に変えます。

メールバックエンドはすべてクロスポストの機能を提供しています。いくつかの正規表現が合致すると、メールはすべてのグループに ``クロスポスト'' されます。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 Mail Group Commands) を使うことができます。

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

(訳注: オリジナルの Gnus とは仕様が微妙に異なることに注意して下さい) ディフォルトでは分割コードは MIME エンコードされたヘッダーをデコードするので、非-ASCII 文字列に合致させることができます。変数 nnmail-mail-splitting-charset が MIME 文字セット (mime-charset) であったらそれ、MIME 文字セットではない非-nil な値だったらそのときの default-mime-charset の値で、 (MIME エンコードされたものではない) 非-ASCII ビットパターンもデコードします。この動作は nnmail-mail-splitting-decodes を nil にすることによって完全に止めることができ、生のヘッダーのデータを元に記事に合致させたい場合には有効でしょう。

ディフォルトでは入ってくるすべてのメッセージに対して分割が働きます。もし mail-sources 変数 (see Mail Source Specifiers) に directory の項を設定しても、しかし、ディフォルトでは分割は 起こりません。変数 nnmail-resplit-incoming を非-nil な値に設定することによって、この場合でも分割を起こさせることができます。(この変数は他の種類の項目に対しては効果がありません。)

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

Mail Sources
------------

いろんなところからメールを取得することができます---メールスプール、 POP メールサーバー、procmail ディレクトリー、maildir などが例としてあります。

メールソース指示子
.........

メールソース指示子 に メールソース (see Fetching Mail) を設定することで、Gnus にメールを取得する方法を教えることができます。

これは例です:

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

御覧の通り、メールソース指示子はリストで、最初の要素は メールソースの型、その次は任意の数の キーワード となります。明示的に指定されていないキーワードはディフォルト値になります。

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

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
          #  flu@iki.fi

          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 Splitting Mail)。

     キーワード:

     :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 キーワードと同じです。これは実行される関数であることもできます。

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

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

     :authentication
          これは password かシンボル apop で、どの認証方式を使うかを決めるもののどちらかです。ディフォルト値は password です。

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

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

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

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

     :program と :function キーワードが指定されていないと、 pop3-movemail が使用されます。pop3-movemail を使う場合、 pop3-leave-mail-on-server が非-nil だったら、メールは取得後でも POP サーバーに残されます。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 でのみでサポートされている mailbox 形式で、特別のディレクトリーのそれぞれのファイルが正確に 1 メールとなっています。

     キーワード:

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

     :subdirs
          Maildir のサブディレクトリーです。ディフォルト値は ("new" "cur") です。

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

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

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

          (maildir :path "/user@remotehost.org:~/Maildir/"
                   :subdirs ("new"))

imap
     IMAP サーバーからメールを取得します。何らかの理由で IMAP を意図されたようなネットワーク上でメールを読むプロトコルとして扱いたくないときは、Gnus では POP サーバーと同様に扱うことができ、与えられた IMAP メールボックスから記事を取得します。詳しくは IMAP を参照して下さい。

     Kerberos, GSSAPI, TLS/SSL および STARTTLS のための外部プログラムとライブラリが必要であることに留意して下さい。See 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

          有効な format 指示子は以下の通りです。

          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")

webmail
     http://www.hotmail.com/, http://webmail.netscape.com/, http://www.netaddress.com/, http://www.yahoo.com/ などのウェブメールサーバーからメールを取得します。

     注: ウェブメールはクッキーに大きく依存します。url "4.0pre.46" を使う場合は "one-line-cookie" パッチを当てる必要があります。

     警告: メールが失われるかもしれません。無保証です。

     キーワード:

     :subtype
          ウェブメールサーバーの型です。ディフォルト値は hotmail です。他の候補は netscape, netaddress, my-deja です。

     :user
          ウェブメールサーバーの利用者名です。ディフォルト値はログイン名です。

     :password
          ウェブメールサーバーのパスワードです。指定しない場合は、利用者に入力を促します。

     :dontexpunge
          nil でなかったら、未読の記事だけを取得して、それらをごみ箱のフォルダーに移動しません。

     ウェブメールのソースの例です:

          (webmail :subtype 'hotmail
                   :user "user-name"
                   :password "secret")

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

     キーワード:

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

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

          あなたが unplugged であっても 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 の値もまた、それらの既定値になります。

それぞれの型のメールソースのためのキーワードのリストについては、上記を参照して下さい。

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

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

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-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
     すべての新しいメールファイルはこのファイルモードになります。ディフォルト値は 384 です。

mail-source-movemail-program
     非-nil だったら新着メールの取り込むためのプログラムの名前。 nil だったら EXEC-DIRECTORY にある movemail。

メールの取得
......

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

この変数 (と旧式の nnmail-spool-file) が 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 があなたのメールを移動しても本当にあまり驚いてはいけません。

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

これらの変数は (たいていの場合) すべての違ったメールバックエンドに関連します。

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 511)))

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

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 Fancy Mail Splitting) を関数 nnmail-split-fancy-with-parent とともに使っている場合に役立つでしょう。

特級メール分割
-------

比較的単純な標準のメール分割指定の方法ではあなたの望むことができない場合、 nnmail-split-methods を nnmail-split-fancy に設定することができます。それから変数 nnmail-split-fancy で遊ぶことができます。

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

     ;; メールデーモン (mailer deamon) は普通のグループにはクロスポスト
     ;; されません。警告は本当のエラーとは違ったグループに入れられます。
     (| ("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
     もし分割が文字列であると、それはグループ名としてみなされます。普通の正規表現の合致がなされます。例は下の方を見て下さい。

(FIELD VALUE [- RESTRICT [...] ] SPLIT)
     もし分割がリストで、最初の要素が文字列であり、ヘッダー FIELD (正規表現) が VALUE (これも正規表現) を含んでいる場合、メッセージを SPLIT で指定されたところに蓄積します。RESTRICT (また他の正規表現) が FIELD の後で、合致した VALUE の最後の前のいくつかの文字列に合致したら、SPLIT は無視されます。RESTRICT の閉包のどれもが合致しなければ SPLIT が実行されます。

(| 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 Splitting in IMAP)。

(! FUNC SPLIT)
     分割がリストで、最初の要素が ! であると SPLIT が実行され、 FUNC は SPLIT の結果を引数として呼ばれます。FUNC は分割を返すべきです。

nil
     もし分割が nil であれば、それは無視されます。

これらの分割で、FILELD は完全なフィールド名に合致しなければなりません。VALUE は基礎モード (fundamental mode) 構文テーブル (syntax table) に従って完全に合致しなければなりません。正規表現でフィールド名か語の部分に合致させるために .* を使うことができます。言い換えれば、すべての VALUE は \< と \> の対で囲まれます。

FIELD と VALUE は Lisp シンボル (symbol) であることもでき、その場合それらは 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")

この例では、debian-foo@lists.debian.org に送られたメールは mail.debian.foo という風になります。

もし文字列が要素 \& を含んでいると、代わりに前で合致した文字列が使われます。同様に、要素 \\1 から \\9 まではグループ付け 1 から 9 までで合致した文字列で代替されます。

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

nnmail-split-fancy-match-partial-words は、特級分割で部分的な語が合致するかどうかを制御します。

通常 nnmail-split-fancy で与えられる正規表現は、暗に語の区切りを表す \<...\> 印で囲まれています。この変数が真であると、それらは何によっても暗に囲まれません。

     (any "joe" "joemail")

この例で、通常 joedavis@foo.org から来たメッセージは joemail に格納されません。しかし、 nnmail-split-fancy-match-partial-words を t に設定すると合致が起きます。要するに、語を区切る条件が削除され、代わりに合致がより grep らしくなるのです。

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

この機能を利用するためには、まず変数 nnmail-treat-duplicates および nnmail-cache-accepted-message-ids の値を非-codenil に設定する必要があります。それができたら 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'' グループに入ってしまうでしょう。

グループメール分割
---------

たーくさんのメーリングリストを購読しているけれど、手でメール分割規則を維持したくないときは、グループメール分割というものがあなたのためにあります。グループパラメーターかグループカスタマイズで 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 に設定することができ、その場合はグループは gnus-group-split に無視されます。

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

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

     nnml:mail.bar:
     ((to-address . "bar@femail.com")
      (split-regexp . ".*@femail\\.com"))
     nnml:mail.foo:
     ((to-list . "foo@nowhere.gov")
      (extra-aliases "foo@localhost" "foo-redist@home")
      (split-exclude "bugs-foo" "rambling-foo")
      (admin-address . "foo-request@nowhere.gov"))
     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 がどれかの選択されたグループ空文字列に合致すると、全捕獲分割は行なわれません。そうでない場合、split-spec が catch-all に設定されているグループでは、それが 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 はその値に設定されます。

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

古いメールを取り込む
----------

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

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

例を挙げましょう: nnml (see Mail Spool) を使ってメールを読んでいて、nnmail-split-methods を満足できる値に設定しています。古い Unix mbox ファイルが重要だけれど古いメールで満たされています。あなたはそれを nnml グループに移動したいと思っています。

方法です:

 1. グループバッファーに行きます。

 2. G f と打って、mbox ファイルから nndoc グループを作成するように促されたときに mbox のファイル名前を与えます (see Foreign Groups)。

 3. SPACE を打って、新しく作られたグループに入ります。

 4. M P b を打って、グループバッファーのすべての記事に実行印を付けます (see Setting Process Marks)。

 5. B r を打ってすべてのプロセス印の付いた再スプールし、促されたときに nnml と答えます (see Mail Group Commands)。

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

メールの期限切れ消去
----------

伝統的なメールリーダーは、何か、既読の印を付けると記事を削除する傾向があります。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 などの印が付けられた記事も期限切れ消去可能であると解釈されます。

Auto-expire または total-expire は、いつ使用されるべきですか? メーリングリストを購読しているほとんどの人々は、それぞれのリストをそれ自身のグループに分割し、それらのグループに対して auto-expire または total-expire を有効にします。(see Splitting Mail, それぞれのリストのそれ自身のグループへの分割についてのさらなる情報。)

Auto-expire または total-expire のどちらが良いですか? それは答えにくいです。概して言えば、たぶん auto-expire が速いでしょう。auto-expire の別の利点はより多くのマークを使える - 再び読むことになっている (be supposed to stick around の意訳) 記事については、今までどおり可視 (tick)、保留 (dormant) または既読 (read) の中から選ぶことができる - ということです。しかし total-expire では dormant と ticked からしか選べません。 total-expire の利点は、適応スコア付け (see Adaptive Scoring) で良好に働くことです。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 命令が自動的に記事を期限切れ消去可能にするのでは無いということにも気を付けて下さい---半自動の、自動期限切れ消去可能グループで記事を既読に印付けることだけが記事を期限切れ消去可能にします。

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

自動期限切れ消去を実行する他の方法は、グループのグループパラメーターとして、要素 auto-expirable を持つことです。

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

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

Gnus は記事がどのグループに属しているかに基づいて、それがどのくらい生存するかを成功に設定する関数も提供しています。mail.private グループは期限を 1ヶ月に、mail.junk グループでは期限を 1 日に、その他のものには期限を 6 日間にするには:

     (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 Group Parameters)。

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

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

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

Gnus には変数 nnmail-fancy-expiry-targets に従ってメールを期限切れ消去するための関数 nnmail-fancy-expiry-target があります。これは例です:

      (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 でなければ、グループが自動期限切れ消去が使用されるようになっていても、利用者の印付け命令は記事に期限切れ消去可能の印を付けません。

メール洗濯
-----

メイラー (mailer) やリストサーバー (list server) は本当に本当に馬鹿げたことをすることで悪名高いです。``わぁ、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
     このフックはそれぞれのヘッダーに範囲を狭められて (narrowed) 呼ばれます。ヘッダーをきれいにするときに使うことができます。使うことのできる関数は:

     nnmail-remove-leading-whitespace
          ヘッダーにそれが良く見えるように ``有用な'' リストサーバーが前の方に付け加えた空白を無くします。あぁぁ。

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

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

          例えば、(idm) と nagnagnag 同一識別子を取り除きたいのなら:

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

          これは gnus-list-identifiers で非破壊的に行なうこともできます。 See Article Hiding.

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

     nnmail-fix-eudora-headers
          Eudora は壊れた References ヘッダーを作成しますが、 In-Reply-To ヘッダーにはちゃんとしたものを入れます。この関数は References ヘッダーを取り除きます。

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

     article-de-quoted-unreadable
          Quoted Readable エンコードをデコードします。

重複
--

いくつかのメーリングリストのメンバーなら、時々同じメールを二つ受け取ることがあります。これはとてもうるさく感じることもあるので、nnmail はそれが発見するかもしれない重複を調べて扱います。これをするために、古い Message-ID を保存します---nnmail-messagge-id-cache-file に。これはディフォルトでは ~/.nnmail-cache です。それに保存される最大数の Message-ID は変数 nnmail-message-id-cache-length に制御され、それはディフォルトで 1000 です。(ですから、 1000 Message-ID が溜められます。) これが恐ろしいと思ったなら、 nnmail-treat-duplicates を warn (ディフォルトではそのようになっていますが) に設定することができ、そうすれば、nnmail は重複メールを消去しません。その代わりに、メールの先頭にこれは違ったメッセージの重複であるという警告を挿入します。

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

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

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

     (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 を使って、考える限りたくさんの侮辱を送ることができます。その楽しさを考えてみて下さい! その人はそれらを決してみることはありません! わぉ!

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

メールバックエンドを使い始めると、それらにはあなたがそれらでメールを読みたいと思っていると仮定するといううるさい癖があります。これはもっともでないことではないかもしれませんが、あなたの望むことではないかもしれません。

もし mail-sources と nnmail-spool-file を nil に設定すると、どのバックエンドも入ってくるメールを読もうと試みることはなく、望むことの手助けになるでしょう。

例えば、nnml でメールを読むことに非常に満足していて、古い Rmail ファイルが nnbabyl で隠されているのをさっと見たいだけなら、これは余分でしょう。すべてのバックエンドは バックエンド- get-new-mail という変数を持っています。もし nnbabyl のメール読み込みを使用不可にしたいのであれば、グループの仮想サーバーを nnbabyl-get-new-mail を nil に設定するように編集します。

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

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

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

標準の Gnus では六つの違ったメールバックエンドがあり、個別にさらなるバックエンドを使用可能です。ほとんどの人が使うメールバックエンドは (それがたぶん最速だから) nnml です (see Mail Spool)。

Unix メールボックス
............

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

仮想サーバーの設定:

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

nnmbox-activate-file
     メールボックスのアクティブファイルの名前。既定値は ~/.mbox-active です。

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

Rmail Babyl
...........

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

仮想サーバーの設定:

nnbabyl-mbox-file
     Rmail mbox ファイルの名前。既定値は ~/RMAIL です。

nnbabyl-active-file
     rmail box のためのアクティブファイルの名前。既定値は ~/.rmail-active です。

nnbabyl-get-new-mail
     nil でなければ、nnbabyl は入ってくるメールを読み込みます。既定値は t です。

メールスプール
.......

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

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

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

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

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

印ファイル (訳注: marks file) が使われると (それがディフォルトですが)、 nnml サーバーは tar などを使ってバックアップしたり、後であなたが付けた印がすべて保たれた状態で Gnus に戻す (本来の nnml サーバーによって追加する) ことができる特質を持つようになります。グループの印はそれぞれの nnml グループのディレクトリー内の、通常 .marks ファイル (nnml-marks-file-name を参照) に格納されます。また、個々の nnml グループについてもバックアップすることが可能で、(バックアップを nnml ディレクトリーに戻した後で) G m キーを使ってそのグループを元に戻します。

もし何らかの理由によって .marks ファイルがおかしくなっていると思ったときは、単にそれら全部を消してしまうことができます。Gnus は次回起動するときに、それらを正しく再作成するでしょう。

仮想サーバーの設定:

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

nnml-active-file
     nnml サーバーのためのアクティブファイル。既定値は ~/Mail/active です。

nnml-newsgroups-file
     nnml グループ記述ファイル。See Newsgroups File Format. 既定値は ~/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-marks-is-evil
     非-nil であると、このバックエンドはいかなる 印 ファイルも無視します。ディフォルトは nil です。

nnml-marks-file-name
     印 ファイルの名前です。ディフォルトは .marks です。

nnml-use-compressed-files
     非-nil だったら nnml はメッセージファイルを圧縮します。ただし auto-compression-mode が有効になっていなければなりません (see Compressed Files (The Emacs Editor))。

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

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

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 です。

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 は、そのサーバーのニュースグループとして Gnus に現れ、シンボリックリンクのファイル名がそのグループの名前になります。ディレクトリーにある . で始まるどんなファイル名も無視されます。ディレクトリーは最初に Gnus を起動したときとグループバッファーで g をタイプしたときはいつでも走査され、どれかの maildir が削除または追加されたときに nnmaildir は通知します。

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

target-prefix
     これは Lisp 式でなければなりません。eval で処理された後で、 expand-file-name によって新しい maildir が生成されるディレクトリーの名前を獲得します。式はサーバーが開通したときだけ 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 に設定することができます。この場合は、名前が target-prefix で始まる directory で見つかるどの maildir も、グループとは見なされません (が、それらを指し示すシンボリックリンクがグループになります)。

     特別な場合として target-prefix が "" (ディフォルト) だったら、グループを作るときに、directory において対応するシンボリックリンクを持たない maildir が作成されます。そのようなグループに対しては、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 自体において新着メールを走査した後で、このサーバーは nnmail-split-methods か nnmail-split-fancy による mail-sources から、従来の Gnus の方法でメールを取り込みます。ディフォルト値は nil です。

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

グループパラメーター
..........

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

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

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

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

read-only
     これが t に設定されていると、nnmaildir はその記事をこのグループで読み出し専用として扱います。この意味は、記事は 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 が無い記事の数に少々の余分を加えたもの) です。

記事の識別
.....

記事はそれぞれの maildir の cur/ ディレクトリーに格納されます。各々の記事には uniq:info のような名前が付けられます。ここで uniq はコロンを含みません。nnmaildir は :info の部分を保持しますが無視します。(他の maildir リーダーは一般に印を格納するためにこの部分を使います。) uniq の部分は記事をユニークに識別し、 maildir の .nnmaildir/ サブディレクトリーの色々な場所に記事に関連した情報を格納するために使われます。概略バッファーで記事を要求した後で、記事の完全なパス名が nnmaildir-article-file-name 変数から得られます。

NOV データ
.......

uniq によって識別される記事は、その NOV データ (概略バッファーの行を生成するために使われる) を .nnmaildir/nov/uniq に格納します。nnmaildir-generate-nov-databases 関数はありません。(その必要はあまりありません。記事の NOV データは記事か nnmail-extra-headers が変化したときに自動的に更新されます。) 対応する NOV ファイルをただ消すことによって単一の記事の NOV データの生成を nnmaildir に強制することはできます。しかし ご用心。これは nnmaildir がこの記事に新しい記事番号を割り振らせ、seen 印、エージェント、およびキャッシュにとって面倒なことになります。

記事の印
....

.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 は変更を捉えてくれずに、それらを元に戻してしまうかもしれません。

メールフォルダー
........

nnfolder はそれぞれのメールグループを違ったファイルに蓄蔵するバックエンドです。それぞれのファイルは標準の Un*x mbox 様式です。 nnfolder は記事番号と到着日を記録しておくための追加のヘッダーを加えます。

印ファイル (訳注: marks file) が使われると (それがディフォルトですが)、 nnfolder サーバーは tar などを使ってバックアップしたり、後であなたが付けた印がすべて保たれた状態で Gnus に戻す (本来の nnfolder サーバーによって追加する) ことができる特質を持つようになります。グループの印は nnfolder ディレクトリー内の、mbox ファイルに通常 .mrk (nnfolder-marks-file-name を参照) が付加された名前のファイルに格納されます。また、個々の nnfolder グループについてもバックアップすることが可能で、(バックアップを nnfolder ディレクトリーに戻した後で) G m キーを使ってそのグループを元に戻します。

仮想サーバーの設定:

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

nnfolder-active-file
     アクティブファイルの名前。既定値は ~/Mail/active です。

nnfolder-newgroups-file
     グループ記述ファイルの名前。See Newsgroups File Format. 既定値は ~/Mail/newsgroups" です。

nnfolder-get-new-mail
     nil でなければ、nnfolder は入ってくるメールを読み込みます。既定値は t です。

nnfolder-save-buffer-hook
     フォルダーを保存する前に実行されるフックです。nnfolder バッファーに対してさえも Emacs は通常のバックアップの変名をすることに注意して下さい。この機能を無効にしたいのであれば、.emacs ファイルで次のようなことをすることができます:

          (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-marks-is-evil
     非-nil であると、このバックエンドはいかなる 印 ファイルをも無視します。ディフォルトは nil です。

nnfolder-marks-file-suffix
     印 ファイルの拡張子です。ディフォルトは .mrk です。

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

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

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

まず、用語として、バックエンド (back end) は低次の接続方法のための普通の語です---もし望むなら、透過的であり、それは何かを成し遂げるものです。そのこころは、メールはどこからか来なければならず、適切なバックエンドの選択は、メールを Gnus のすぐ近くに取得するために要求される、というものです。

同じ概念が Usenet 自身にも存在します。記事への接触は今日では、普通は NNTP でなされますが、昔々の憂鬱な深夜の時代は、皆は記事が存在するマシン (今日では NNTP サーバーと呼ぶもの) でリーダーを動かし、リーダーからの接続は、直接記事のディレクトリースプールに踏み込むというものでした。それでも、たまたまサーバー (もしくは、NFS でスプールが読めるような場合) にいるような場合は、これらの方法を選ぶために nntp や nnspool バックエンドのどちらかを選ぶことができました。

メールバックエンドを選択することのゴールは、元の形式を扱うのに適した方法と、将来使用するために便利な形式にメールを残すことの両方を同時に表現することです。それぞれには良い点と悪い点がいくつかあります:

nnmbox

     UNIX システムは歴史的に単一の、非常に一般的な、うまく定義された形式を持っています。すべてのメッセージは単一の スプールファイル に到着し、正規表現 ^From_ に合致する行で区切られています。(私の _ の記号の使用はスペースを意味するためで、この例ではこれは RFC で指定されている From: ヘッダーで無いことを明らかにするためです。) Emacs は、それに Gnus も、歴史的に Unix 環境から広まりましたので、元の mailbox 形式をあまりぐちゃぐちゃにしないというのは、最も簡素な方法です。ですから、このバックエンドを選ぶと、本当のスプールからメールを取得して、Gnus の好むディレクトリーにメールを移動するための Gnus の主な活動は、単に、実行過程で何も (評価できる) 変更をせずに複製することです。それは Gnus の環境の使用可能範囲にメールを移動する ``最も愚かな''方法です。これは定められた場所に移動するのを速くしますが、Gnus がどこに何があるかを調べるときは、解析が遅くなります。

nnbabyl

     むかしむかし、TOPS と呼ばれるオペレーティングシステムや、似たようなものを実行している DEC-10 と DEC-20 というものがあり、普通の (唯一の?) メールを読む環境は Babyl と呼ばれるものでした。そのシステムに着いたメールがどのような形式になっていたかは知りませんが、Babyl はメールが変換される、それ用の内部形式を持っており、主に、Babyl 特有のヘッダーと状態ビットをファイルのそれぞれのメッセージの先頭に加えることをしていました。 Rmail は Emacs の最初のメールリーダーで、Richard Stallman によって書かれ、 Stallman はその TOPS/Babyl 環境の出身であるため、Rmail をすでに存在していたメールファイルの一族を理解する様に書きました。Gnus は (この問題に関しては VM も) この形式をサポートし続けています。それは、そのメーラー特有のヘッダー/ビットというものがなかなか質が良いと考えられているからです。 Rmail 自身ももちろんまだ存在していて、まだ Stallman によって維持されています。

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

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 は意味的には ``nnml にアクティブファイルと overview のないもの'' と等価です。これは議論のあるところですが、最悪の選択です。というのは、個々のファイルの作成の遅さが、グループで何が新しいかを知るときの解析のための使用の遅さが結び付くからです。

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ノードの割り当てがどれほどたくさんあるかを調べて下さい。) そのために遅くなったり多くの場所を取ってしまうようならば、 ReiserFS (http://www.namesys.com/) や他の非ブロック構造のファイルシステムへの転換を検討して下さい。

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

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

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

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

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

Browsing the Web
================

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

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

それで---ウェブブラウザーが掲示板を読むのに適していないのなら、どうして代わりに Gnus を使わないのでしょう?

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

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

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

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

メールの保存
------

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

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

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

個々の nnml, nnfolder または nnmaildir のグループを、印を保持しつつ保存することもできます。nnml か nnmaildir では、そのグループのディレクトリーにあるすべてのファイルをコピーします。 nnfolder では、基本のフォルダーファイル (FOO) と印ファイル (FOO.mrk) の両方をコピーする必要があります。グループを元に戻すのは、グループバッファーで G m キーを使います。その最後の手順によって、Gnus は新しいディレクトリーができたことを知ります。 nnmaildir は自動的に新しいディレクトリーを知るので、その場合 G m は不要です。

ウェブ検索
-----

それは、なんというか、Usenet から文字列に合致する記事を検索するのはとても素晴らしいんだけど、その、あのウェブブラウザーってやつを使って、そんでもって、宣伝を読ませられるっていうのは、その、なんというか、ほんとうに 不様ね というか、それで、Gnus ではブラウザーを使わずに、その、超かっこよく それができる、ってことです。

nnweb バックエンドは、強力な検索エンジンに対して簡単なインターフェースを提供します。nnweb グループを作成し、検索パターンを入力し、そしてそのグループに入って他の普通のグループのように記事を読みます。グループバッファー (see Foreign Groups) の G w 命令によってお手軽にこれができます。

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

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

nnweb を使うには、url と w3 パッケージをインストールしておかなくてななりません。

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

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 形式文字列。

Slashdot
--------

Slashdot (http://slashdot.org/) は人気のあるニュースサイトで、ニュース記事の後に活発な議論がなされています。nnslashdot では便利な方法でこの会議室を読むことができます。

ここから読むための一番簡単な方法は以下のようなものを ~/.gnus.el ファイルに入れることです。

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

これは Gnus に nnslashdot バックエンドに新しいコメントとグループを尋ねるようにします。F 命令はそれぞれの新しいニュース記事を新しい Gnus のグループとして購読し、これらのグループに入ることでコメントを読むことができます。(ディフォルトの購読方法では、新しいグループをゾンビとして購読することに注意して下さい。他の方法も使えます (see Subscription Methods)。

もしあなたが古い nnslashdot グループを削除したいのならば、 G DEL が最も手軽な道具です (see Foreign Groups)。

nnslashdot コメントにフォローアップ (または新しいコメントの投稿) をするときは、少し HTML に変換されます。特に、>  で引用されたテキストはその代わりに blockquote で引用され、署名にはそれぞれの行の最後に br が追加されます。それ以外は、メッセージバッファーに直接 HTML を書くことができます。Slashdot はいくつか HTML を選別することに気を付けて下さい。

以下の変数で振る舞いを変えることができます:

nnslashdot-threaded
     nnslashdot がグループをスレッドで表示するかどうか。ディフォルト値は t です。スレッドを表示できるためには、nnslashdot はグループに入る際にそのすべてのコメントを取得する必要があります。スレッド表示が要求されていないと、nnslashdot は利用者が欲しいコメントだけを取得します。スレッドの方がきれいですが、スレッド無し表示より、ずっとずっと遅くなります。

nnslashdot-login-name
     投稿時に使うログイン名です。

nnslashdot-password
     投稿時に使うパスワードです。

nnslashdot-directory
     nnslashdot がファイルを保存する場所です。ディフォルト値は ~/News/slashdot/ です。

nnslashdot-active-url
     ニュース記事とコメントを取得するために使われる URL の文字列です。ディフォルト値は http://slashdot.org/search.pl?section=&min=%d です。

nnslashdot-comments-url
     コメントを取得するために使用される URL 文字列です。

nnslashdot-article-url
     ニュース記事を取得するために使われる URL 文字列です。ディフォルト値は http://slashdot.org/article.pl?sid=%s&mode=nocomment です。

nnslashdot-threshold
     スコアのしきい値です。ディフォルト値は -1 です。

nnslashdot-group-number
     最新の 10 に加えて更新を続ける古いグループの数です。ディフォルト値は 0 です。

Ultimate
--------

The Ultimate Bulletin Board (http://www.ultimatebb.com/) はおそらく一番良く使われているウェブ掲示板システムでしょう。とても整然として良い界面で、Gnus がグループを最新の状態に保っておくために情報を得ることが可能です。

nnultimate を始めるための一番簡単な方法はグループバッファーで以下のようなものをすることです: B nnultimate RET http://www.tcj.com/messboard.ubbcgi/ RET。(興味のある会議室の URL (Ultimate.cgi 等を最後に含んでいないもの) に変えて下さい。Ultimate ウェブサイトにはたくさん挙げられています。) それからサーバーバッファーで興味のあるグループを購読し、グループバッファーからそれらを読んで下さい。

以下の nnutimate 変数を変更可能です:

nnultimate-directory
     nnultimate がファイルを保存するディレクトリーです。ディフォルト値は ~/News/ultimate/ です。

Web Archive
-----------

メーリングリストの中には例えば、 http://www.egroups.com/ や http://www.mail-archive.com/ のようにウェブサーバーにしかアーカイブが無いものもあります。とても整然として良い界面で、Gnus がグループを最新の状態に保っておくために情報を得ることが可能です。

nnwarchive を始めるための一番簡単な方法はグループバッファーで以下のようなものをすることです: M-x gnus-group-make-warchive-group RET AN_EGROUP RET egroups RET www.egroups.com RET YOUR@EMAIL.ADDRESS RET。(AN_EGROUP を購読しているメーリングリストに、YOUR@EMAILADDRESS を電子メールアドレスに置き換えて下さい。) または B nnwarchive RET mail-archive RET でバックエンドをブラウズして下さい。

以下の nnwarchive 変数を変えることが可能です:

nnwarchive-directory
     nnwarchive がファイルを保存するディレクトリーです。ディフォルト値は ~/News/warchive です。

nnwarchive-login
     ウェブサーバーでのアカウント名です。

nnwarchive-passwd
     ウェブサーバーでのアカウントのパスワードです。

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 でエンコードされます。それが nil であると、Emacs では coding system はディフォルトで default-file-name-coding-system の値になります。あなたが XEmacs を使っていて、非-ASCII グループ名を使いたければ、 nnmail-pathname-coding-system 変数の値を適切に設定しなければなりません。

あなたの講読目録を 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-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 "<RET>") 'browse-nnrss-url))
     (add-to-list 'nnmail-extra-headers nnrss-url-field)

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 の記事バッファーで HTML リンクを叩けば、browse-url を使ってそのリンクを参照するようになるでしょう。

IMAP
====

IMAP はメール (もしくは、ニュース、もしくは ...) を読むためのネットワークプロトコルです。現代風の NNTP と考えて下さい。 IMAP サーバーへの接続はニュースサーバーへの接続と非常に似ていて、そのサーバーのネットワークアドレスを指定するだけになっています。

IMAP には二つの特質があります。一つは、 IMAP は POP でできることは全部できる、それゆえ POP++ のようにも見えるということ。二つ目は、 IMAP は NNTP がニュースを貯蔵するプロトコルであるように、メールを貯蔵するプロトコルであるということです。しかしながら IMAP は NNTP より多くの機能を提供します。ニュースは読むだけですが、メールは読み書きができます。

IMAP を POP++ のように使いたいときは、 mail-sources に imap を登録して下さい。これによって Gnus は IMAP サーバーからメールを取り込んで、ローカルディスクに貯蔵します。ここではその使い方の説明はしませんから、 Mail Sources を参照して下さい。

IMAP をメールを貯蔵するプロトコルとして使いたいときは、 gnus-secondary-select-methods に nnimap を登録して下さい。これによって Gnus は IMAP サーバーに貯蔵されているメールを操作するようになります。これがここで説明する使い方です。

いくつかの IMAP サーバーを ~/.gnus.el で設定すると、たぶん以下のようなものになるでしょう。(注: TLS/SSL では外部プログラムとライブラリが必要です。以下を参照して下さい。)

     (setq gnus-secondary-select-methods
           '((nnimap "simpleserver") ; 普通の設定
             ; SSH ポートをフォワードしたサーバー:
             (nnimap "dolk"
                     (nnimap-address "localhost")
                     (nnimap-server-port 1430))
             ; ローカルホストで運転している UW サーバー:
             (nnimap "barbar"
                     (nnimap-server-port 143)
                     (nnimap-address "localhost")
                     (nnimap-list-pattern ("INBOX" "mail/*")))
             ; 匿名で使える cyrus の公衆サーバー:
             (nnimap "cyrus.andrew.cmu.edu"
                     (nnimap-authenticator anonymous)
                     (nnimap-list-pattern "archive.*")
                     (nnimap-stream network))
             ; 標準ではないポートの SSL サーバー:
             (nnimap "vic20"
                     (nnimap-address "vic20.somewhere.com")
                     (nnimap-server-port 9930)
                     (nnimap-stream ssl))))

新しいサーバーを定義した後で、U のような Gnus の通常のコマンドをグループバッファーで使う (see Subscription Commands) か、またはサーバーバッファー (see Server Buffer) を介して、そのサーバーのグループを講読することができます。

以下の変数は仮想 nnimap サーバーを作成するために使うことができます。

nnimap-address

     遠隔 IMAP サーバーのアドレスです。指定されていない場合は仮想サーバーのものになります。

nnimap-server-port
     接続を試みるサーバーのポートです。ディフォルトはポート 143、または TLS/SSL では 993 です。

     これは整数でなければなりません。以下はサーバー指定の例です。

          (nnimap "mail.server.com"
                  (nnimap-server-port 4711))

nnimap-list-pattern
     使用可能なメールボックスを制限するための文字列かリストです。これは、サーバーに非常に多くのメールボックスがあるけれど、興味のあるものは少しだけであるときに使用します。サーバーにはホームディレクトリーを IMAP 経由で出すものもあるので、その場合はおそらくメールボックスを ~/Mail/* に制限したいでしょう。

     文字列は REFERENCE と上の文字列との cons であることもできます。どの REFERENCE が使用されるかはサーバー特有ですが、ワシントン大学のサーバーでは、メールボックスと連結されたディレクトリーです。

     以下はサーバー指定の例です。

          (nnimap "mail.server.com"
                  (nnimap-list-pattern ("INBOX" "Mail/*" "alt.sex.*"
                                         ("~friend/Mail/" . "list/*"))))

nnimap-stream
     サーバーに接続するときに使われるストリームの型です。ディフォルトでは nnimap は TLS/SSL を除く以下のすべてを自動的に検知してそれを使います。(TLS/SSL を使う IMAP は STARTTLS で置き換えられています。これは自動検出できますが、まだ広範囲に配備されていません。)

     以下はサーバー指定の例です。

          (nnimap "mail.server.com"
                  (nnimap-stream ssl))

     nnimap-stream の値はシンボルでなければならないことに注意して下さい!

       * gssapi: GSSAPI (普通は Kerberos 5) を使います。gsasl または imtest プログラムが必要です。

       * kerberos4: Kerberos 4 を使います。imtest プログラムが必要です。

       * starttls: STARTTLS (TLS/SSL に類似) を使います。外部ライブラリ starttls.el と starttls プログラムが必要です。

       * tls: TLS を使います。GNUTLS (gnutls-cli プログラム) が必要です。

       * ssl: SSL を使います。OpenSSL (openssl プログラム) か SSLeay (s_client) が必要です。

       * shell: シェル命令を使って IMAP 接続を開始します。

       * network: 生の、TCP/IP のネットワーク接続です。

     imtest プログラムは Cyrus IMAPD に含まれています。もしあなたが 2.0.14 未満の Cyrus IMAPD に含まれている imtest (バージョン 1.5.x と 1.6.x) を使っているなら、 imap-process-connection-type をいじり回して、 imap.el が imtest と通信するときにパイプではなくて pty を使うようにさせる必要があります。そうするとあなたは IMAP コマンドの行の長さの制限に悩まされるでしょう。それはメールボックスにたくさんの記事があるときに Gnus を無期限にハングさせてしまうかもしれません。変数 imap-kerberos4-program は imtest プログラムに渡すパタメータを含みます。

     TLS 接続では GNUTLS 由来の gnutls-cli プログラムが必要です。これは http://www.gnu.org/software/gnutls/ から手に入れることができます。

     このパラメーターは、副シェルで GSSAPI 認証による IMAP 接続を起動するためのコマンド行のリストを指定します。これらは接続が確立するまで、またはリストが使い尽くされるまで、順ぐりに試されます。ディフォルトでは、 http://www.gnu.org/software/gsasl/ にある GNU SASL による gsasl と、Cyrus IMAPD による imtest プログラム (imap-kerberos4-program 参照) が試されます。

     SSL 接続のための OpenSSL プログラムは http://www.openssl.org/ から入手できます。OpenSSL は以前は SSLeay として知られていたもので、nnimap はそれもサポートします。しかし、SSLeay の最新版である 0.9.x には重大なバグがあるため使えません。以前の版、特に SSLeay 0.8.x は使えることがわかっています。変数 imap-ssl-program は OpenSSL/SSLeay に渡すパタメータを含みます。

     IMAP 接続に shell ストリームを使う場合、変数 imap-shell-program は何のプログラムを呼ぶかを指定します。

nnimap-authenticator

     サーバーに接続するために使われる認証です。ディフォルトでは nnimap はサーバーが使用可能な一番安全な認証を使用します。

     以下はサーバー指定の例です。

          (nnimap "mail.server.com"
                  (nnimap-authenticator anonymous))

     nnimap-authenticator の値はシンボルでなければならないことに注意して下さい!

       * gssapi: GSSAPI (普通は Kerberos 5) 認証です。外部プログラム gsasl または imtest が必要です。

       * kerberos4: Kerberos 4 による認証です。外部プログラム imtest が必要です。

       * digest-md5: DIGEST-MD5 で暗号化された 利用者名/パスワード です。外部ライブラリ digest-md5.el が必要です。

       * cram-md5: CRAM-MD5 で暗号化された 利用者名/パスワード です。

       * login: LOGIN 経由での生の 利用者名/パスワード です。

       * anonymous: 電子メールアドレスをパスワードとして与え、 ``anonymous'' としてログインします。

nnimap-expunge-on-close

     パルメニデスと違って、IMAP の設計者達は、存在していないものが実際には存在していると決めました。もっと詳しく説明すると、 IMAP は実際には記事を消去しない、記事に Deleted という印を付ける概念があり、これ (えっと、Deleted という印を付けることです) が nnimap が Gnus で記事を消去するときにすることです (B DEL などで)。(訳注: パルメニデスは紀元前 5 世紀のギリシアの Elea 派の哲学者)

     記事を Deleted フラグで印を付けたときには本当は消去されていないので、実際に消去するための方法が必要となります。循環しているように感じますか?

     伝統的に、nnimap はメールボックスを閉じるときに Deleted という印の付いたすべての記事を消去してきましたが、今はサーバー変数により設定可能です。

     選択肢は:

     always
          これがディフォルトの振舞いで、メールボックスを閉じるときに ``Deleted'' と印の付いた記事を消去します。

     never
          決して記事を消去しません。現在は、消去の印が付いた記事を nnimap で表示する方法はありませんが、他の IMAP クライアントはではできるかもしれません。手で EXPUNGE コマンドを発行したいときは see Expunging mailboxes.

     ask
          メールボックスを閉じるときに、nnimap が消去された記事を削除するかどうかを尋ねます。

nnimap-importantize-dormant

     非-nil (ディフォルト) だったら、他の IMAP クライアントのために保留記事を印付きとしても印を付けます。Gnus の内部では、保留記事は元々すでに保留記事としてのみ印が付けられています。これは、他の IMAP クライアントにおける保留記事を、あたかも印付きのようにきわ立たせます。(別の言い方をすると、Gnus は二つの印を付け、 IMAP はたった一つだということです。)

     たぶんこれをいじりまわすのは、あなたが利用者単位の保留フラグを付けようとするだけの理由によるでしょう。こんな感じで:

          (setcdr (assq 'dormant nnimap-mark-to-flag-alist)
                  (format "gnus-dormant-%s" (user-login-name)))
          (setcdr (assq 'dormant nnimap-mark-to-predicate-alist)
                  (format "KEYWORD gnus-dormant-%s" (user-login-name)))

     この場合、あなたは利用者単位の保留フラグを、他の利用者に印付きとして見られたくないと思っています。

nnimap-expunge-search-string

     この変数には、期限切れ消去するのが望ましい記事を探すときにサーバーに送った IMAP の検索コマンドが入っています。ディフォルトは "UID %s NOT SINCE %s" で、ここで最初の %s は UID で置き換えられ、二番目の %s は日付で置き換えられます。

     たぶん使いものになる別の値は "UID %s NOT SENTSINCE %s" で、 nnimap に記事の内部的な日付の代わりに Date: を使うようにさせます。さらなる情報や使うことができる文字列については、RFC 2060 のセクション 6.4.4 を見て下さい。

nnimap-authinfo-file

     サーバーにログインするために使う認証情報 (authinfo) を含むファイルです。その形式は (ほとんど) ftp の ~/.netrc ファイルと同じです。厳密な定義は、変数 nntp-authinfo-file を見て下さい。そして NNTP も見て下さい。IMAP サーバー用の .authinfo 行の例です:

          machine students.uio.no login larsi password geheimnis port imap

     安全な IMAP で使われる実際のポート番号は port 993 ですが、 nnimap-stream として tls または ssl を使う場合、それは port imap または port 143 でなければならないことに注意して下さい。便宜上 Gnus は port imap の同義語として port imaps を受け入れます。

nnimap-need-unselect-to-notice-new-mail

     新着メールを探す前にメールボックスを未選択にします。何らかの状況の元で、幾らかのサーバーが、これを必要とするようです。Courier 1.7.1 はそうだという報告がありました。

IMAP での分割
---------

分割は Gnus の利用者が何年もの間愛してきたもので、今や残りの世界も追いつこうとしています。はい、想像して下さい、IMAP サーバーの中にサーバー側で分割できるものはあまり多くなく、しかもそれらは標準でないプロトコルを使っているようです。これは、Gnus の IMAP サポートは自分自身で分割をしなければならないということです。

そして実際にします。

(ついでに言えば、みんなが夢見ていたのでしょうね。その結果 Sieve は市場占有率を増して、いくつもの IMAP サーバーによってサポートされるようになりました。幸いに Gnus もそれをサポートします。See Sieve Commands.)

関連する変数は三つです:

nnimap-split-crosspost

     nil でなければ、いくつかの分割方法がメールと合致したときにクロスポストをします。nil ならば、nnimap-split-rule で最初に見つかったものが使われます。

     Nnmail で対応するもの: nnmail-crosspost.

nnimap-split-inbox

     分割の元となる IMAP のメールボックスの名前を指定した文字列か文字列のリストです。ディフォルト値は nil で、分割は使用しないようになっています!

          (setq nnimap-split-inbox
                '("INBOX" ("~/friend/Mail" . "lists/*") "lists.imap"))

     Nnmail に対応するものはありません。

nnimap-split-rule

     nnimap-split-inbox で見つかった新しいメールはこの変数に従って分割されます。

     この変数はリストのリストから成ります。副リストの最初の要素は IMAP のメールボックスで、二つめの要素の正規表現に合致した記事の移動先を指定します。わかりましたか? いいえ、私もわかりません。例が必要です。

          (setq nnimap-split-rule
                '(("INBOX.nnimap"
                   "^Sender: owner-nnimap@vic20.globalcom.se")
                  ("INBOX.junk"    "^Subject:.*MAKE MONEY")
                  ("INBOX.private" "")))

     これは nnimap メーリングリストからのすべての記事をメールボックス INBOX.nnimap に入れ、Subject: 行に MAKE MONEY のあるすべての記事を INBOX.junk に入れ、その他すべてのものを INBOX.private に入れます。

     最初の文字列は、replace-match で合致したテキストから副表現を挿入するときに使用されるのと同じような、\\1 形式を含むことができます。例えば:

          ("INBOX.lists.\\1"     "^Sender: owner-\\([a-z-]+\\)@")

     最初の要素をシンボル junk にして、合致するメッセージを単に消すべきであることを表すこともできます。気を付けて使って下さい。

     二つ目の要素は関数であることもできます。その場合は、記事のヘッダーがあるバッファーで、その規則の最初の要素を引数として呼ばれます。メールがそのグループに属すると考える場合は、nil でない値を返す必要があります。

     Nnmail の利用者は最後の正規表現はすべての記事に合致するように空でなくてはならないことを覚えているかもしれません (上の例のように)。これは nnimap では必要ではありません。正規表現のどれにも合致しない記事は inbox から移動されません。(inbox に未読記事を大量に置いておくと、分割のコードは新しいメールを取得するときにそれらすべてを調べるので、実行速度に影響する可能性があります。)

     これらの規則は連想リストの最初から終りに向かって実行されます。クロスポストが使用可能になっていないかぎり、最初に合致した規則が ``勝ち'' ます。クロスポストをしている場合は、すべての合致した規則が ``勝ち'' ます。

     この変数はその値として関数を持つこともできます。その関数は記事のヘッダーの部分に範囲が狭められた状態で呼ばれ、記事の移動先だと思うグループを返すものでなければなりません。nnimap-split-fancy を参照して下さい。

     分割コードは必要ならメールボックスを作成します。

     異なる仮想サーバー毎に違う分割の規則を使ったり、それどころか同じサーバーの異なる inbox 毎に違う分割の規則を使うことができるようにするために、この変数の構文は以下のように拡張されています。

          (setq nnimap-split-rule
                '(("my1server"    (".*"    (("ding"    "ding@gnus.org")
                                            ("junk"    "From:.*Simon")))
                  ("my2server"    ("INBOX" nnimap-split-fancy))
                  ("my[34]server" (".*"    (("private" "To:.*Simon")
                                            ("junk"    my-junk-func)))))

     仮想サーバー名は実際には正規表現なので、同じ規則をいくつかのサーバーに適用できるでしょう。この例ではサーバー my3server と my4server が同じ規則を使います。同様に inbox 文字列も正規表現です。上記の分割の規則の実例は、関数、またはグループの正規表現かグループの関数、の両方です。

     Nnmail で対応するもの: nnmail-split-methods.

nnimap-split-predicate

     この述語に合致する nnimap-split-inbox にあるメールは分割されます。これは文字列で既定値は UNSEEN UNDELETED です。

     もしあなたが inbox にあるメールを読むために別の IMAP クライアントを使っているが、購読度に関わらずにすべての記事を Gnus に分割させたいならば、これは役に立つかもしれません。その場合は UNDELETED に変えれば良いでしょう。

nnimap-split-fancy

     もしあなたが特級分割を使いたいならば、nnimap-split-rule の値を nnmail-split-fancy に設定することができます。 See Fancy Mail Splitting.

     しかし nnmail と nnimap とで異なる特級分割方式を持つようにするには、 nnimap-split-rule の値を nnimap-split-fancy に設定して、 nnimap 特有の特級分割方式を nnimap-split-fancy に定義して下さい。

     例:

          (setq nnimap-split-rule 'nnimap-split-fancy
                nnimap-split-fancy ...)

     Nnmail で対応するもの: nnmail-split-fancy.

nnimap-split-download-body

     分割しているときにすべての記事をダウンロードするには非-nil に設定して下さい。これは普通は必要ではなく、ものごとを相当に遅くしてしまうでしょう。記事を分割するために本文を分析する高度な関数を使いたい場合には、必要かもしれません。

IMAP での期限切れ消去
-------------

nnimap は完全な nnmail 由来のバックエンドではありませんが、たいていの期限切れ消去 (see Expiring Mail) の標準機能をサポートします。IMAP の分割 (see Splitting in IMAP) では nnmail の変数を複製しない (例えば NNIMAP-EXPIRY-WAIT を生成しない) 点が違うのですが、nnmail の変数を流用します。以下は nnimap の期限切れ消去処理で使われる変数です。

期限切れ消去の印がどのように適切に IMAP サーバーに記録されるかについてもここで言及しておきましょう。期限切れ消去の印は imap クライアント特有の印である gnus-expire に変換され、メッセージに記録されます。これは、他のクライアントはメッセージのクライアント特有のフラグを見るかもしれないのに対して、Gnus はたぶん gnus-expire の印を適切に扱い理解するだけであることを意味します。またこれはサーバーが、クライアント特有のフラグのメッセージへの恒久的な保存をサポートしなければならないことも意味します。幸いに、たいていはサポートします。

nnmail-expiry-wait

nnmail-expiry-wait-function

     これらの変数は完全にサポートされています。期限切れ消去の値は、数、シンボルの immediate または never です。

nnmail-expiry-target

     この変数はサポートされていて、内部的にはこれを扱う nnmail 関数を呼ぶことによって実装されています。もし行き先が同じサーバーの IMAP グループだったら、記事は追加される代わりにコピーされる (アップロードし直される) という最適化も含みます。

IMAP の ACL を編集する。
-----------------

ACL は Access Control List (使用制限一覧) の略です。IMAP では ACL は他の利用者によるあなたのメールボックスの使用を制限 (もしくは許可) するために使われています。IMAP サーバーすべてにこの機能があるわけではなく、無いサーバーでこれらの関数を使うとエラーが発生します。

メールボックスへの ACL を編集するためには、 G l (gnus-group-edit-nnimap-acl) を入力します。そうすると、詳しい指示とともに ACL 編集ウィンドウが現れます。

使用の例:

  * メーリングリストのメールボックスで ``anyone'' に ``lrs'' 許可 (lookup, read, seen/unseen フラグの保持) を与えることで、同じサーバーの他の利用者がそれを購読することなく読むことができます。

  * 少なくとも Cyrus のサーバーにおいては、``plussing'' が動作するために (つまり、user+mail@domain が INBOX.mailbox という IMAP のメールボックスになる)、利用者 ``anyone'' に投稿 ("p") の許可を与える必要があります。

メールボックスの削除
----------

nnimap-expunge-on-close に never を設定していれば、メールボックスのすべての消去された記事を手動で削除する必要があるでしょう。 G x がまさにこのことをします。

現時点では、消去された記事を表示する方法はありません。ただ消去できるだけです。

名前空間に関する注意
----------

IMAP プロトコルには名前空間 (namespaces) と呼ばれる概念があり、以下の RFC2060 の文書で記述されています。

     5.1.2.  メールボックス名前空間命名規則

        習慣により "#" で始まっているすべてのメールボックス名の最初の階層要素
        は、残りの名前の "名前空間" を示している。これは、それぞれ独自の名前
        空間を持つ異なるメールボックス保管の間での、曖昧さを取り除くことを可
        能にする。

           例えば USENET ニュースグループへのアクセスを提供する実装は、USENET
           ニュースグループ名前空間を他のメールボックスから分離するために、
           "#news" 名前空間を用いてもよい。こうして comp.mail.misc ニュースグ
           ループは "#news.comp.mail.misc" というメールボックス名を持ち、名前
           "comp.mail.misc" は別のオブジェクト (例えば、利用者の個人メールボッ
           クス) を指すことはありうる。

     (訳註: http://kame.zit.to/~obata/imap/rfc/rfc2060ja.txt より転載)

ここには Gnus における IMAP の実装に対する関係を保証する文書が無いのですが、いくつかのサーバーは Gnus のメールボックスの名前の使い方では動作しないやり方で名前空間接頭引数を使っています。

具体的には、ワシントン大学の IMAP サーバーは #driver.mbx/read-mail のようなメールボックス名を使っていて、それは CREATE と APPEND コマンドでだけ有効です。メールボックスが作られた後 (またはメッセージがメールボックスに追加された後) では、それは名前空間接頭引数を付けずにアクセス、すなわち read-mail されなければなりません。Gnus は利用者が CREATE と APPEND コマンドだけで入力したメールボックス名を保証できないので、絶対に名前空間接頭引数が付いたメールボックス名を Gnus で使ってはいけません。

#driver.*/ 接頭引数についてのさらなる使い方の情報は UoW IMAPD の文書を見て下さい。それらは強力な工具なので、どんな効果があるかが確かな場合だけ使って下さい。

IMAP のデバッグ
----------

IMAP は NNTP や POP3 よりもっと複雑なプロトコルです。実装上のバグが無いとは言い切れないので、私たちは、すぐにそれらを直すために最善を尽くします。あなたが奇妙な振る舞いに出会ったとしたら、サーバーか Gnus のどちらかにバグがある可能性があります。

あなたが一般的なネットワーク・プロトコルに精通しているならば、Gnus とサーバーの間でやりとりされるプロトコル・ダンプを読むことによって、おそらくいくつかの手掛かりを抽出することができるでしょう。精通していなくても、プロトコル・ダンプを IMAP に関するバグ報告に含めれば、その問題の解決にとって重要なデータで私たちを助けます。したがって、Gnus の IMAP バグを報告するときに、プロトコル・ダンプを含めることを強く奨励します。

プロトコル・ダンプは、それを有効にしているとたくさんのデータを生成するので、ディフォルトでは無効になっています。有効にするには、以下のように imap-log を設定して下さい:

     (setq imap-log t)

これは imap.el パッケージに、サーバーとのやりとりを何でも記録させます。その記録は *imap-log* というバッファーに格納されます。ときとして BAD という札が付けられる、エラーメッセージを探して下さい。でも、バグを提出するときは、すべてのデータを含めるようにして下さい。

その他のグループ源
=========

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

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

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

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

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

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

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

なんでもグループ
--------

(一つのスプール風ディレクトリーと解釈できる) nndir バックエンドから nneething までは、ほんのすぐそこです。それはいかなるディレクトリーでもニュースグループに見せかけてしまう、というものです。不思議です、でも真実です。

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
     対応表ファイルの名前。

文書グループ
------

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

babyl
     Babyl (Rmail) 形式のメールボックス。

mbox
     標準 Unix mbox ファイル。

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

news
     いくつかのニュース記事が連結された一つのファイル。

rnews
     rnews のバッチ転送形式。

forward
     転送された記事。

nsmail
     Netscape のメールボックス。

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

standard-digest
     標準 (RFC 1153) まとめ送り形式。

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

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

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 が助けになります。例えばあなたがメールを古い RMAIL で持っていて、それをあなたの新しい nnml グループに分配したいとします。あなたはそのファイルを nndoc を使って開いて (グループバッファーで G f 命令を使う (see Foreign Groups))、バッファー内の全記事にプロセス印を付け (例えば 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 です。

文書サーバーの内部
.........

nndoc で認識される新しい文書種別を追加することは難しくありません。その文書がどのように見えるのかを寄せ集めて、その文書種別を認識する述語関数を書き、そして nndoc に繋げるだけです。

まず、これが文書種別定義の例です。

     (mmdf
      (article-begin .  "^\^A\^A\^A\^A\n")
      (body-end .  "^\^A\^A\^A\^A\n"))

この定義は単に、唯一の名前 (name) とそれに続く正規表現と仮想変数設定の列からなります。以下がこれに使える変数です---変数の数に圧倒されないで下さい。ほとんどの文書種別はごくわずかの設定で定義できます。

first-article
     これがあれば、nndoc はこの正規表現に合致する何かが見つかるまで、すべてのテキストを読み飛ばします。合致する前のすべてのテキストは完全に無視されます。

article-begin
     この設定はすべての文書種別定義において必ずなくてはなりません。これは各記事の始まりがどのように見えるかを指定します。

head-begin-function
     これがある場合、これは記事の先頭にポイントを移動させる関数でなくてはなりません。

nndoc-head-begin
     これがある場合、これは記事のヘッダーに合致する正規表現でなくてはなりません。

nndoc-head-end
     これは記事のヘッダーの最後に合致しなくてはなりません。これのディフォルト値は ^$---空行です。

body-begin-function
     これがある場合、この関数は記事のボディーの開始位置にポイントを移動させる関数でなくてはなりません。

body-begin
     これは記事のボディーの開始位置に合致しなくてはなりません。これのディフォルト値は ^\n です。

body-end-function
     これがある場合、この関数は記事のボディーの最後の位置にポイントを移動させる関数でなくてはなりません。

body-end
     これがあれば、記事のボディーの最後に合致しなくてはなりません。

file-end
     これがある場合、これはファイルの最後に合致しなくてはなりません。この正規表現の後ろのテキストはすべて、完全に無視されます。

このように、これらの変数を使って nndoc は文書ファイルを、それぞれヘッダーとボディーを持った記事の連なりとして解剖することができます。しかし、すべての文書種別がすべてこのようなニュース風になってるわけではないので、さらにいくつかの変数---ヘッダーやボディーを Gnus の趣味に合うように変形させる変数が必要になります。

prepare-body-function
     これがあれば、この関数は記事が要求されたときに呼び出されます。これはボディーの開始位置のポイントとともに呼び出され、文書の内容の一部がエンコードされている場合に有用です。

article-transform-function
     これがあれば、この関数は記事が要求されたときに呼び出されます。これは、記事のヘッダーとボディーの両方により広範囲な変形を行なうために使われるものです。

generate-head-function
     これがあれば、この関数は Gnus が理解できるヘッダーを生成するために呼び出されます。これは記事番号をパラメーターとして呼び出され、問題の記事のきれいなヘッダーを生成することを求められます。これはすべての記事のヘッダーが要求されるときに呼び出されます。

私が作った中で最も複雑な例---標準まとめ送り形式を見てみましょう。

     (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 は正しい値の中でもっとも低い数値です。

SOUP
----

PC の世界の人々はよく、``オフライン'' ニュースリーダについて話をしています。これはリーダとニュース配送を合体させた、実在するモンスターです。内蔵モデムプログラム付きでね。きゃはは!

もちろん、我らが Unix キチガイの人間供は uucp だとか nntpd のようなものを使い、神の領域たるメール、ニュースの配送を正しく設定するのです。そして僕たちはただ普通のニュースリーダを使います。

しかし、あなたがとても遅いモデムを持っていてこれらを正しく設定することに興味が無ければ、脳みそに楽をさせる方をするのも時には便利です。

SOUP と呼ばれるファイル形式はニュースとメールをサーバーから家のマシンへと転送し、それをまた戻すために開発されました。ちょっと面倒くさいかもしれないけどね。

はじめにいくつか用語を。

server
     これは外の世界に繋がっていて、あなたがニュースとメールを送受信するマシンです。

home machine
     これはあなたが実際に読んだり返事を書いたりしたいマシンです。これは普通、他の世界といかなる形でも接続されていません。

packet
     メッセージと命令を含んだもの。パケットには二種類あります。

     message packets
          これはサーバーで作られるパケットで、普通はあなたが読むためのたくさんのメッセージが含まれています。これらはディフォルトでは SoupoutX.tgz という名前です。ここで X は数字です。

     response packets
          (返信パケット) このパケットは自宅マシンで作られるパケットで、普通はあなたの書いた返事が含まれています。これらはディフォルトでは SoupinX.tgz という名前です。ここで X は数字です。

 1. まず SOUP パケットを作るためにサーバーにログインします。 SOUP のための専用のブツ (awk プログラムのような) を使っても良いし、Gnus の SOUP 命令を使ってパケットを作っても良いです (O s あるいは G s b そして G s p)

     (see SOUP Commands)。

 2. パケットを自宅に転送します。電車で、船で、自動車で、あるいはモデムで、何でもいいです。

 3. パケットをあなたのホームディレクトリーに置きます。

 4. Gnus をあなたの自宅マシンでかっ飛ばして、nnsoup バックエンドを基本サーバーあるいは二次サーバーとして使用します。

 5. 記事やメールを読んで必要なやつに返事を書いてフォローアップ記事を書きます (see SOUP Replies)。

 6. G s r 命令を実行して、これらの返事を SOUP パケットに梱包します。

 7. このパケットをサーバーに転送します。

 8. Gnus から G s s 命令を使ってこのパケットからメールを出します。

 9. あとはこれを死ぬまで続けます。

つまり基本的に二者分割システムができたことになります---nnsoup を読むために、Gnus を SOUP パケットの梱包と送出に使います。

SOUP 命令
.......

これらの命令は SOUP パケットの作成と操作を行なうものです。

G s b
     現在のグループのすべての未読記事を梱包する (gnus-group-brew-soup)。このコマンドはプロセス/接頭引数の習慣に従います。

G s w
     すべての SOUP データファイルを保存します (gnus-soup-save-areas)。

G s s
     返信パケットからすべての返信を送出する (gnus-soup-send-replies)。

G s p
     すべてのファイルを  SOUP パケットに梱包する (gnus-soup-pack-packet)。

G s r
     すべての返信を返信パケットに梱包する (nnsoup-pack-replies)。

O s
     この概略モード命令は、現在の記事を SOUP パケットに追加します (gnus-soup-add-article)。これはプロセス/接頭引数の習慣に従います (see Process/Prefix)。

Gnus がこれらの実体をどこに置くかをカスタマイズするいくつかの変数があります。

gnus-soup-directory
     SOUP パケットを作成中に Gnus が中間ファイルを保存するディレクトリーです。ディフォルト値は ~/SoupBrew/ です。

gnus-soup-replies-directory
     返信パケット送信中に Gnus が使用する一時ディレクトリーです。 ~/SoupBrew/SoupReplies/ がディフォルト値です。

gnus-soup-prefix-file
     Gnus が最後に使った接頭引数を保存するファイル名です。ディフォルト値は gnus-prefix です。

gnus-soup-packer
     SOUP パケットを梱包する命令文字列の形式です。ディフォルト値は tar cf - %s | gzip > $HOME/Soupout%d.tgz です。

gnus-soup-unpacker
     SOUP パケットを取り出す命令文字列の形式です。ディフォルト値は gunzip -c %s | tar xvf - です。

gnus-soup-packet-directory
     Gnus が返信パケットを探しに行く場所です。ディフォルト値は ~/ です。

gnus-soup-packet-regexp
     gnus-soup-packet-directory 内の SOUP パケットに合致する正規表現です。

SOUP グループ
.........

nnsoup は SOUP パケットを読むためのバックエンドです。これは入ってきたパケットを読み、それを取り出して、あなたが暇なときに読むディレクトリーに展開します。

これらはこの振る舞いをカスタマイズできる変数です。

nnsoup-tmp-directory
     nnsoup が SOUP パケットを取り出すとき、このディレクトリー内で行ないます (ディフォルト値は /tmp/)。

nnsoup-directory
     そして nnsoup がそれぞれのメッセージと索引ファイルをこのディレクトリーに移動させます。ディフォルト値は ~/SOUP/ です。

nnsoup-replies-directory
     すべての返信は、返信パケットに梱包される前にこのディレクトリーに格納されます。ディフォルト値は ~/SOUP/replies/ です。

nnsoup-replies-format-type
     返信パケットの SOUP 形式です。ディフォルト値は ?n (rnews) で、この変数には触るべきではないと私は思います。たぶん文書に明記すべきでさえなかったね。ちぇっ! もう手遅れか。

nnsoup-replies-index-type
     返信パケットの索引の種類です。ディフォルト値は ?n で、意味は ``なし'' です。これもいじるんじゃないよ!

nnsoup-active-file
     nnsoup がたくさんの情報を格納する場所です。これは nntp の意味での ``アクティブファイル'' ではなく、Emacs Lisp のファイルです。このファイルを無くしてしまったり、何か壊してしまったら、あなたは死にます。ディフォルト値は ~/SOUP/active です。

nnsoup-packer
     返信 SOUP パケットを梱包する命令文字列の形式です。ディフォルト値は tar cf - %s | gzip > $HOME/Soupin%d.tgz です。

nnsoup-unpacker
     入ってくる SOUP パケットを取り出すための命令文字列の形式です。ディフォルト値は gunzip -c %s | tar xvf - です。

nnsoup-packet-directory
     入ってきたパケットを nnsoup が探す場所です。ディフォルト値は ~/ です。

nnsoup-packet-regexp
     入ってきた SOUP パケットに合致する正規表現です。ディフォルト値は Soupout です。

nnsoup-always-save
     nil 以外であれば、メッセージを投稿した後に返信バッファーを保存する。

SOUP 返信
.......

単に nnsoup を使うだけでは、SOUP 返信パケット中のあなたの投稿とメールの送信が、魔法のように自動的に終了するわけではありません。それを起こすにはもうちょっと働かなくてはいけません。

nnsoup-set-variables 命令は、あなたのすべてのフォローアップ記事と返信を SOUP システムに確実に終了させるように、適切な変数を設定します。

特別に、これが実際に行なわれることです。

     (setq message-send-news-function 'nnsoup-request-post)
     (setq message-send-mail-function 'nnsoup-request-mail)

それだけです、ほんとに。もし SOUP システムにニュースだけを入れたかったら、最初の行だけを使って下さい。もしメールだけを SOUP させたかったら、二番目を使って下さい。

メールからニュースへのゲートウェイ
-----------------

もしあなたのローカルの nntp サーバーが、何らかの理由で投稿を許可していなければ、数あるメールからニュースへのゲートウェイを使って投稿することができます。nngateway バックエンドはこのインターフェースを提供します。

このバックエンドからは何も読み出せないことに注意して下さい---これは投稿するためだけに使われます。

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

nngateway-address
     これがメール・ニュースゲートウェイのアドレスです。

nngateway-header-transformation
     ニュースヘッダーは、メール・ニュースゲートウェイが受け付けられるように、奇妙な形に変形しておかなくてはならない時があります。この変数はどんな変形処理が呼び出されるべきかを示しており、ディフォルト値は nngateway-simple-header-transformation になっています。この関数は変形するヘッダーに領域制限 (narrow) されて呼び出され、一個の引数---ゲートウェイのアドレスを与えられます。

     ディフォルト値の関数は、単に新しい To ヘッダーを Newsgroups ヘッダーとゲートウェイアドレスをもとに挿入します。例えば、以下のような Newsgroups ヘッダー

          Newsgroups: alt.religion.emacs

     を持つ記事には、次のような To ヘッダーが挿入されます。

          To: alt-religion-emacs@GATEWAY

     以下の既製関数が存在します:

     nngateway-simple-header-transformaton
          NEWSGROUP@nngateway-address のような To ヘッダーを作ります。

     nngateway-mail2news-header-transformation
          nngateway-address のような To ヘッダーを作ります。

          ここに例があります。

               (setq gnus-post-method
                     '(nngateway
                       "mail2news@replay.com"
                       (nngateway-header-transformation
                        nngateway-mail2news-header-transformation)))

つまり、これを使うには、こんな風にするだけです。

     (setq gnus-post-method '(nngateway "GATEWAY.ADDRESS"))

合併グループ
======

Gnus は、すべてのグループの種類を混合して、大きなグループに合併させることができます。

仮想グループ
------

nnvirtual グループ (nnvirtual group) は実は他のグループの集合以上の何物でもありません。

例えば、もし小さなグループをたくさん読むのが嫌になってきたら、それらを一つの大きなグループに入れて、嫌になるくらい巨大で手に負えないグループを読むことができます。これがコンピューターの楽しみだね!

選択方法として 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 Selecting a Group)。

なお、ここで一つだけ制限があります---仮想グループに含まれるグループはすべて生きている (すなわち、購読または非購読の) 状態でなくてはなりません。削除あるいはゾンビグループは nnvirtual グループの構成グループになることはできません。

nnvirtual-always-rescan が nil 以外であれば、 nnvirtual は仮想グループに入ったとき常に、未読記事を走査します。この変数が nil (これがディフォルト) であって、仮想グループを作成した後に構成グループ内の記事を読んだ場合は、その構成グループで読まれた記事は、仮想グループに入ったときに表示されるでしょう。もし共通の構成グループを持つ二つの仮想グループがある場合にもこの影響があります。その場合はこの変数を t にした方が良いです。あるいは仮想グループに入る時に、毎回そのグループの上で M-g を叩いても良いです---これはほぼ同様の効果があります。

nnvirtual はメールとニュースの両方のグループを構成グループとすることができます。nnvirtual グループの記事に返答するときは、 nnvirtual は記事の出所の構成グループのバックエンドにそれがニュースのバックエンドであるかメールのバックエンドであるかを尋ねなければなりません。しかし、^ をしたときには、普通は構成バックエンドがこれを知る確かな方法はなく、その場合は、nnvirtual は Gnus に記事はニュースでないバックエンドから来たと告げることになります。(安全のために。)

このような場合は、メッセージバッファーでの C-c C-n が応答しようとしている記事から Newsgroups 行を抜き出して挿入します。

nnvirtual グループは、構成グループから記事と印以外は継承しません。例えばグループパラメーターもそうなのですが、それらは継承されません。

Kiboze グループ
-----------

Kiboze する、とは、``ニューススプール全部 (あるいはその一部) から grep すること'' と OED (オックスフォード大辞典) によって定義されています。nnkiboze はこれをあなたのために行なってくれるバックエンドです。嬉しいね! これでどんな NNTP サーバーでも、役に立たない要求で止まってしまうまで酷使することができるね。ああ、なんて幸せなんだ!

kiboze グループを作成するには、グループバッファーで G k 命令を使います。

nnkiboze 方法におけるアドレス欄は、nnvirtual と同様に、 nnkiboze に ``含めたい'' グループに合致する正規表現です。ここが nnkiboze と nnvirtual バックエンドの最も類似している点です。

この構成グループを列挙する正規表現に加えて、nnkiboze グループには、グループ内のどの記事を含めるかを決めるスコアファイルがなくてはなりません (see Scoring)。

あなたの欲しい nnkiboze グループを作成した後には、 M-x nnkiboze-generate-groups を実行しなければなりません。この命令は時間がかかります。とってもかかります。すごく、すごーくかかります。 Gnus はその nnkiboze グループの一部となるべき記事があるかどうかを調べるために、全部の構成グループの全部の記事に対してヘッダーを取得し、それらすべてに対してスコア処理を実行しなくてはならないのです。

構成グループの数を抑えるように、限定した正規表現を使って下さい。さもないと、あなたのところのシステム管理者を怒らせてしまって、NNTP サーバーからあなたを追い出して二度と入れないようにしてしまうかもしれません。不慣れな人がよくやることです。

nnkiboze の構成グループは生きている必要はありません---死んでても良いし、外部グループでも構いません。無制限です。

nnkiboze グループの生成によって、二つのファイル nnkiboze-directory 内に作成されます。これのディフォルト値は ~/News/kiboze/ です。一方のファイルはそのグループの全記事の NOV ヘッダー行を含んでいて、もう一方は構成記事を見つけるためにどのグループが検索されたかの情報を格納する、.newsrc の補助ファイルです。

nnkiboze グループ内の既読となった記事は、その記事の NOV 行が NOV ファイルから削除されます。

電子メールによる日程管理
============

この項では nndiary という特別なメール・バックエンドと、その仲間の gnus-diary ライブラリについて説明します。それが「特別」なのは、 Gnus でメールを読むための標準の選択肢の一つであるつもりは無いからです。それ (標準の選択肢) については Choosing a Mail Back End を参照して下さい。代わりに、特別な方法であなたのメールのいくつかを扱う、すなわちこれはリマインダ (予定を思い出させるもの) として使われます。

典型的な筋書きは、こうです。

  * あなたはアンディ・マクドウェルかブルース・ウィリス (あなたの好みに合わせて、どちらかを選んで下さい) と、一ヶ月後にデートの約束をしました。それを忘れるわけにはいきません。

  * そこで、自分宛てにリマインダのメッセージを (実際のところ、毎日一通) 送ります。

  * あなたはそれをすっかり忘れて、受け取った新しいメールをいつもどおりに読み続けます。

  * デートの日が近付いてくると、グループバッファーで g をタイプしたときに、ときどきあなたの予定を思い出させるために、あたかも新着で未読のように、メッセージが再びポップアップするでしょう。

  * これを含んでいる「新しい」メッセージを読んで下さい、そして、再びあなたが過ごす夜を夢見て下さい。

  * いったんデートが終わると (実際にはディナーのすぐ後で寝入ってしまったとしても)、期限切れ消去の印が付いていれば、メッセージは自動的に消去されます。

Gnus Diary バックエンドは、(常に取り消されることが無い) 定期的な予定を、几帳面な人たちと同じように扱う能力を持っていて、本当のメール・バックエンドのように動作し、いろんなやり方で設定することができます。このすべてが、以下の各項で説明されます。

NNDiary バックエンド
--------------

nndiary は nnml (see Mail Spool) にとてもよく似ているバックエンドです。現にそれは nnml と nndraft を合わせたものに見えるでしょう。nnml をご存知ならば、あなたはすでに nndiary がメッセージを格納する仕組み (一通あたり一つのファイル、一グループあたり一つのディレクトリー) に精通しています。

何はさておき、nndiary をちゃんと動作させるには、一つの要件があります: Gnus のグループの日付の機能を使わ なければ なりません。それがどういうふうに行なわれるかは Group Timestamp を見て下さい。

日程メッセージ
.......

七つの特別なヘッダーが必須であること以外、nndiary のメッセージは普通のものです。それらのヘッダーは X-Diary-<something> の様式で表され、<something> の部分は Minute, Hour, Dom, Month, Year, Time-Zone および Dow のうちの一つです。Dom は「日 (Day of Month)」を、 Dow は「曜日 (Day ofWeek)」を意味します。これらのヘッダーは crontab の仕様のように働いて、予定日を定義します。

  * Time-Zone のもの以外のすべてのヘッダーについて、ヘッダーの値は星印 (可能なすべての値を意味します) かコンマで区切られたフィールドのリストです。

  * フィールドは整数か範囲です。

  * 範囲とは、ダッシュ (-) で区切られた二つの整数です。

  * 可能な値は、それぞれ Minute には 0--59、Hour には 0--23、 Dom には 1--31、Month には 1--12、Year には 1971 より大きい値、そして Dow には 0--6 (0 が日曜日) です。

  * 特別な場合として、Dom または Dow における星印は「可能なすべての値」ではなく、「もう一方のフィールドだけを使う」意味になります。両方とも星印にした場合は、どちらを使っても同じ結果になることに注意して下さい。

  * Time-Zone ヘッダーは、値を一つしか持てない (例えば GMT) 点で特別です。星印は「可能なすべての値」ではなく (それは意味をなさないので)、「現在のローカルなタイムゾーン」を意味します。ここではたいてい星印を使うでしょう。しかし、利用できるタイムゾーンの値については、変数 nndiary-headers を見て下さい。

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: *

NNDiary を動かす
............

nndiary には二つの動作モードがあります。一つはディフォルトの「伝統型 (traditional)」、もう一つは「自律型 (autonomous)」です。伝統型のモードでは、nndiary はそれ自身が新着メールを取得することはありません。日程メッセージとして扱うために、メールを基本のメール・バックエンドから nndiary グループに、移動 (B m) またはコピー (B c) しなければなりません。自律型のモードでは、nndiary はそれ自身のメールを取ってきて、基本のメール・バックエンドとは独立してそれを扱います。

本質的に Gnus は、同時に複数の「マスター」メール・バックエンドを許容するようには設計されていなことに、注意すべきです。しかし nndiary では、これは意味をなします。あなたは本当に、日程メッセージを日程グループに直接送って、それらを受け取りたいのです。そこで nndiary は、まさに「二番目の第一メール・バックエンド」をサポートします (私が知っている限り、それはこの機能を提供する唯一のバックエンドです)。しかしながら制約があって (いつの日にか解消することを願いますが)、自律型のモードでは再スプールができません。

自律型のモードで nndiary を使うためには、いくつかのことをやってもらわなければなりません:

  * 新着メールを nndiary が自分で取り込めるようにします。以下の行を gnusrc ファイルに記入して下さい:

          (setq nndiary-get-new-mail t)

  * 日程メッセージ (X-Diary-* ヘッダーを含んでいる) が、Gnus がそれらを処理する 前 に専用のフォルダーに分配されるように、準備を行なわなければなりません。繰り返しますが、Gnus が複数の第一メール・バックエンドを適切に扱うことが (まだ ?) できないので、これが必要です。別々のソースからそれらのメッセージを取り込むことによって、この欠点はある程度補われます。

     日程ファイルを ~/.nndiary (これがディフォルトの nndiary のメールソース・ファイルです) に格納するための procmailrc の項の例です:

          :0 HD :
          * ^X-Diary
          .nndiary

いったんこれを実施したら、日程メールの取り込みと分割の処理に影響する、以下の二つのオプションをカスタマイズする必要があるでしょう:

 -- Variable: nndiary-mail-sources
     標準の mail-sources 変数の、日程用に特化した代替品です。同じシンタックスを使い、ディフォルト値は (file :path "~/.nndiary") です。

 -- Variable: nndiary-split-methods
     標準の nnmail-split-methods 変数の、日程用に特化した代替品です。同じシンタックスを使います。

最終的には gnus-secondary-select-methods に、恒久的な nndiary 仮想サーバー ((nndiary "diary") が行なうべきであるようなもの) を追加しても良いでしょう。

うまくいけば、Gnus を再起動すると、ほとんどすべて (nndiary.el の TODO の項を参照) が期待通りに (自律型のモードでは、g や M-g をグループバッファーでタイプすれば新しい日程メールをも取り込んで、日程用に特化した規則に従ってそれらを分割するし、 F は新しい日程グループを見つけてくれる、など) 動作するでしょう。

NNDiary のカスタマイズ
...............

さあ nndiary が立ち上がって動作しています。それをカスタマイズするときが来ました。カスタマイズするためのグループは nndiary です (へえー)。どのオプションをカスタマイズし倒したいかを見つけるために、それに目を通して下さい。あなたが変更したいのは、おそらく以下のたった二つの変数でしょう:

 -- Variable: nndiary-reminders
     予定を思い出させてもらいたい時刻のリスト (例えば三週間前、それから二日前、それから一時間前、そしてそのとき) です。「思い出させてもらう」の意味は、新着メールを取り込んだときに、日程メッセージが真新しく未読になって、ポップアップすることであることを思い出して下さい。

 -- Variable: nndiary-week-starts-on-monday
     読んで字の如し。さもなくば日曜日が仮定されます (それがディフォルトです)。

Gnus Diary ライブラリ
----------------

nndiary を手作業で使うの (ヘッダーを手で書く、とか) は、いささかうんざりします。幸い nndiary の上位階層に書かれた gnus-diary というライブラリがあって、たくさんの便利なことをやってくれます。

それを使うためには、以下の行を gnusrc ファイルに加えて下さい:

     (require 'gnus-diary)

さらに、どんな gnus-user-format-function-[d|D] (see Summary Buffer Lines) も、使ってはいけません。gnus-diary はそれらの両方を提供します (あなたがそれらを使っていたら、すみません)。

日程の概略行仕様
........

標準の概略行仕様 (通常 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 Diary Group Parameters)。あなたはしかし、以下のユーザー・オプション群で提供される概略行仕様を、カスタマイズすることができます:

 -- Variable: gnus-diary-summary-line-format
     日程グループで使う概略行仕様を定義します (see Summary Buffer Lines)。 gnus-diary はそれを、日程グループのパラメーターを自動で更新するために使います。

 -- Variable: gnus-diary-time-format
     日程の概略バッファーに日付を表示するための書法仕様を定義します。これは利用者定義の書法仕様 D で使われます。詳細は変数の説明文を見て下さい。

 -- Variable: gnus-diary-delay-format-function
     日程の概略バッファーに遅延 (残り時間) を表示するための整形関数を定義します。これは利用者定義の書法仕様 d で使われます。現在は英語とフランス語のための組み込み関数があり、自分で定義することもできます。詳細は変数の説明文を見て下さい。

日程記事の並べ替え
.........

gnus-diary は並べ替えのための関数 (see Sorting the Summary Buffer) として gnus-summary-sort-by-schedule、 gnus-thread-sort-by-schedule および gnus-article-sort-by-schedule を提供します。これらの関数によって、最も近い予定から最も遠い方まで、日程の概略バッファーを整理することができます。

gnus-diary は自動的に、概略バッファーの「並べ替え (sort)」メニューに gnus-summary-sort-by-schedule を組み込み、他の二つを第一次の (ゆえにディフォルトの) 並べ替え関数として、グループパラメーター (see Diary Group Parameters) に登録します。

日程ヘッダーの生成
.........

gnus-diary は、X-Diary-* ヘッダーの取り扱いを補佐するために、gnus-diary-check-message という関数を提供します。この関数は、すべての必要な日程ヘッダーが確実に現在のメッセージに含まれるようにして、必要ならば値を入力するか修正することを要求します。

記事を日程グループに移動またはコピーすると自動的にそれを発動するように、この関数は nndiary バックエンドのフックとして組み入れられています。それはさらに、通常のメールを日程用のものに変換する操作を簡単にするために、 message-mode と article-edit-mode において C-c D c キーとして設定もされています。

接頭引数を伴ってこの関数を呼ぶと、それらがあるか、正しいかどうかとは無関係に、日程ヘッダーの入力を強制します。そうやって、例えばすでに正しく設定されたメッセージの日程を、とても簡単に変更することができます。

日程グループのパラメーター
.............

新しい日程グループを作るか、またはそれを開くと、gnus-diary は自動的にグループパラメーターを検査し、必要なら概略行仕様を日程用に特化した値に設定し、日程用の並べ替え関数を組み込み、さらにそのグループの投稿様式 (posting-style) に種々の X-Diary-* ヘッダーを加えます。そして、日程メッセージを送るのは、より簡単です。メッセージを用意するために、日程グループで C-u a か C-u m を使うことによって、これらのヘッダーが自動的に挿入されるので (まだ適切な値で満たされていませんが)。

送信するべきか、しないべきか
--------------

さて、以上の説明を読んでくれたものとして、以下は nndiary でメールを送信することに関する、二つの最後の注意事項です:

  * nndiary は 本当の メール・バックエンドです。本当にあなたは本当の日程メッセージを本当に送ります。これは、日程メッセージを送ることによって、誰にでも (彼らが Gnus と nndiary を使っているのならば) 予定を伝えることができることをも意味します。

  * しかしながら nndiary は request-post メソッドを持ってもいるので、日程グループで C-u m の代わりに C-u a を使うことによって、メッセージを実際に送信するのではなく、そのグループにローカルに格納することもできます。これは個人的な予定のためには、とても手ごろです。

Gnus の切り離し
==========

いにしえの時代 (およそ 1988 年2月頃)、人々はニュースリーダーを、大きなマシンの上でネットワークに永続的に接続して走らせていました。ニュースの配送はニュースサーバーによって取り扱われ、すべてのニュースリーダーがすべきことは、ニュースを読むことであったのです。信じられないかもしれませんが。

今日では、多くの人々は自宅でニュースやメールを読み、ネットワークに接続するためにモデムの類を使います。電話代の請求書が莫大なものに上らないように、すべてのニュースとメールを吸い上げ、電話を切り、数時間掛けて読み、そして送りたい返信をすべて送信する、という手段を持つことは良いことでありましょう。あとはこの手順を繰り返すのです。

もちろん、これを行なうためにニュースサーバーを使うこともできます。私は inn を slurp, pop, sendmail と一緒にここ数年使ってきましたが、しかしこれは退屈な仕事です。もしあるマシン上でニュースを読む人があなたしかいなければ、ニュースサーバーの機能をニュースリーダーに任せるようにすることは理にかなっています。

Gnus を ``オフライン'' のニュースリーダーとして仕立てるのは極めて簡単です。実際、エージェントは今やディフォルトで有効になっている (see gnus-agent) ので、あなたは何も設定する必要が無いのです。

もちろん、これをオフラインニュースリーダーとして使うには、いくつか新しい命令を覚えなくてはなりません。

エージェントの基礎
---------

まず、いくつかの用語を片付けておきましょう。

ネットワークとの通信が切れているとき (そしてエージェントがそれを知らされているとき)、Gnus エージェントは切り離されている (unplugged) と言います。ネットワークの通信が復活し (そして Gnus がそれを知れば)、エージェントは差し込まれている (plugged) と言います。

ローカル (local) マシンとは、あなたが触っているマシンで、ネットワークに継続的に接続されているものではありません。

ダウンロード (downloading) とはネットワークから何かをあなたのローカルマシンに取ってくることを意味します。アップロード (uploading) はその逆をすることです。

ご存知のように Gnus はあなたがドジを踏むすべての機会を提供します。それを柔軟性と言う人もいます。さらに Gnus は大いにカスタマイズ可能で、それは利用者が、Gnus がどのように動作するかについて発言権を持っていることを意味します。他のニュースリーダーは有無を言わずあなたにドジを踏ませるかもしれませんが、Gnus ではあなたに選択権があります!

Gnus は実際には plugged または unplugged のどちらの状態にもありません。もっと正確に言えば、サーバーごとにそれぞれの状態を持ちます。これは、いくつかのサーバーが接続できないときに、他のサーバーは接続できることを意味します。さらに、 Agent によっていくつかのサーバーをすべて無視することができます (その意味は、それらがいつも plugged になっているのと似ているということです)。

Agent を切り離しても、なぜ Gnus がネットに接続しているのかがいぶかしく思われたとき、行なうべき次のステップはサーバーがすべてエージェント化されているかどうかを観察することです。エージェント化されていないサーバーがあったら、あなたは犯人を見つけたのです。

もう一つの状態は offline です。サーバーはときどき到達可能ではなくなります。Gnus がこのことを知ると、そのサーバーを offline の状態に切り換えても良いかどうかを尋ねます。はい、と答えたならば、(offline に戻して良いかと Gnus が尋ねた場合以外は) サーバーは多少 unplugged だったときのように振る舞います。

エージェントを使った典型的な Gnus の対話操作を見てみましょう。

  * Gnus を gnus-unplugged で起動します。これは Gnus エージェントを切り離されている状態で起動します。この状態では、すでに取得しているニュース記事はすべて読むことができます。

  * そして、新しいニュースが到着しているかどうかを調べることにします。あなたは (PPP か何かを使って) あなたのマシンをネットワークに接続し、Gnus を差し込むために J j を叩き、そして普通は新着メールを検査するために g を使います。Gnus エージェントが切り離されている (unplugged) ときの新着メールの検査については Mail Source Specifiers を参照して下さい。

  * そして、その場ですぐに新しいニュースを読むこともできるし、ニュースをローカルマシンにダウンロードすることもできます。後者を実行したければ、 g を押して新着メールを検査してから J s で全グループから適切な記事をすべて取得します。(Gnus にどの記事をダウンロードしたいかを指定するには Agent Categories を参照して下さい。)

  * 記事を取得した後は J j を押して、Gnus を再び切り離し状態にさせ、 PPP 関係 (など) を閉じます。そうしてニュースをオフラインで読むことができます。

  * そして第二ステップに戻ります。

以下にエージェントを初めて (かそこらに) 使うときに必要ないくつかの作業を示します。

  * どのサーバーをエージェントで面倒を見るかを決めます。もしメールバックエンドがあれば、それをエージェントに面倒を見させるのはおそらく無意味でしょう。サーバーバッファーに移動し (グループバッファーで ^)、エージェントに扱って欲しいサーバー (複数可) で J a を押す (see Server Agent Commands) か、またはエージェントに扱って欲しくないのに自動的に追加されたサーバーで J r を押します。ディフォルトでは gnus-select-method と gnus-secondary-select-methods にあるすべての nntp と nnimap サーバーがエージェント化されます。

  * ダウンロード方針を決定します。あなたの方針を実装するためにエージェント分類、トピックパラメーター、グループパラメーターのどれを使うかをいったん決めてしまえば、これはかなり簡単です。あなたが Gnus の初心者ならば、たぶん分類で始めるのが最良でしょう、see Agent Categories.

     トピックパラメーター (see Topic Parameters) とエージェント分類 (see Agent Categories) の両方は、多数のグループに適用する方針の設定を用意しています。どれを使うかは完全にあなたの責任です。両方を混ぜて使う場合は、トピックパラメーターは分類を無効にすることを考慮に入れなければならないでしょう。あなたの方針にそぐわない少数のグループがあるのならば、それらの設定を変更するためにグループパラメーター (see Group Parameters) を使うことができます。

  * ええと...、以上です。

エージェント分類
--------

ニュース配送機構とニュースリーダーを統合する一つの大きな理由は、どの記事をダウンロードするかについて、より良い制御を可能とすることです。莫大な量の記事をダウンロードしてもあまり意味はなく、それらを読んでもあまり面白くないことが分かるだけです。何をダウンロードするかの選択はもっと慎重であるべきであり、その記事が面白いと分かった時点で、ダウンロードするための印を手動で付けるべきなのです。

何をダウンロードするかを制御するためのより有効な方法の一つは、分類 (category) を作成して、そしてその分類にいくつか (あるいは全部) のグループを割り当てることです。他の分類に属さないグループは ディフォルト の分類に属します。Gnus は分類の作成と管理のための独自のバッファーを持っています。

もしそうしたければ、グループパラメーター (see Group Parameters) とトピックパラメーター (see Topic Parameters) を、エージェントを制御する代替手段に使うことができます。実際に違うのは、グループとトピックパラメーターが何でもかんでも (kitchen sink) 含むのに対して、分類はエージェントに特化している (したがってあまり学ばなくても良い) ということだけです。

エージェントパラメーターは複数の違う場所で設定することができるので、どのソースが信用できるかを決めるための規則を設けました。この規則は、パラメーターのソースが次の順序で調べられることを定めます: グループパラメーター、トピックパラメーター、エージェント分類、そして最後はカスタマイズできる変数群です。したがって、広い範囲で動作を起こさせるためにこれらのソースをすべて混合することができます。どこに設定を置いたのかを忘れてしまったからといって、私を責めないで下さいよ。

分類の文法
.....

分類は、名前、その分類に属するグループのリスト、およびカスタマイズ可能な変数よりも優先される多くの任意なパラメーターから成ります。エージェントパラメーターの完全なリストを以下に示します。

agent-cat-name
     分類の名前。

agent-groups
     この分類にあるグループのリスト。

agent-predicate
     (通常) どの記事をダウンロードするのが適当かという大まかな輪郭を与える述語。そして

agent-score-file
     (通常) どの記事をダウンロードするかを決めるときのよりきめの細かいスコア規則。(このダウンロードスコア (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-length-when-short
     gnus-agent-short-article よりも優先される整数。

agent-length-when-long
     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 and Xref.

述語と同様、グループに関して ダウンロードスコア規則 の指定の使用は、そこのすべてのグループに適用可能なら分類の定義、グループに特有ならグループパラメーター、のどちらかにできます。

両方の場所で、ダウンロードスコア規則 は以下の三つの形式を取ることができます:

 1. スコア規則

     上で書かれているように、スコア付けキーワードの一部分しか使えないことを除けば、これは普通の Gnus スコアファイルの構文と同じです。

     例:

       * 分類指定

               (("from"
                      ("Lars Ingebrigtsen" 1000000 nil s))
               ("lines"
                      (500 -100 nil <)))

       * グループ/トピックパラメーター指定

               (agent-score ("from"
                                  ("Lars Ingebrigtsen" 1000000 nil s))
                            ("lines"
                                  (500 -100 nil <)))

          また、ここで一番外の括弧が省略されていることに注意して下さい。

 2. エージェントスコアファイル

     これらのスコアファイルは上で述べられている使用可能なスコア付けキーワード のみ である必要があります。

     例:

       * 分類指定

               ("~/News/agent.SCORE")

          もしくは、たぶん

               ("~/News/agent.SCORE" "~/News/agent.group.SCORE")

       * グループパラメーター指定

               (agent-score "~/News/agent.SCORE")

          上の様に、追加のスコアファイルを指定することができます。また括弧について言わなければいけませんか?

 3. 普通 のスコアファイルの使用

     一つのグループで二つのスコア規則を維持したくなく、グループの望みの ダウンロード の基準が 読む 基準と同じなら、エージェントに何をダウンロードするかを決める際に 普通 のスコアファイルを参照するようにすることができます。

     分類定義か、グループパラメーターのこれらの指示はエージェントにグループに適用可能なすべてのスコアファイルを読ませ、スコア付けキーワードの使用可能な部分集合に無いものを 選別して抜き取ります。

       * 分類指定

               file

       * グループパラメーター指定

               (agent-score . file)

分類バッファー
.......

通常はすべての分類は分類バッファーから管理します。(グループバッファーから 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)。

分類変数
....

gnus-category-mode-hook
     分類バッファーで実行するフック。

gnus-category-line-format
     分類バッファーの行様式 (see Formatting Variables)。有効な要素は、

     c
          分類の名前。

     g
          分類に属するグループの数。

gnus-category-mode-line-format
     分類モード行の様式 (see Mode Line Formatting)。

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 に設定することができます。その場合、選択されたグループでの期限切れ消去を有効にしなければなりません。

エージェント命令
--------

すべての Gnus エージェント命令は J サブマップにあります。 J j (gnus-agent-toggle-plugged) 命令はすべてのモードで動作し、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 Drafts.

J a
     現在のグループをエージェント分類に追加します (gnus-agent-add-group)。この命令はプロセス/接頭引数の習慣を理解します (see Process/Prefix)。

J r
     現在のグループを、もし存在していれば、その分類から消去します (gnus-agent-remove-group)。この命令はプロセス/接頭引数の習慣を理解します。(see Process/Prefix)。

J Y
     リモートサーバーが unplugged のときに変更されたフラグがあれば同期させます。

概略エージェント命令
..........

J #
     記事にダウンロードするように印を付ける (gnus-agent-mark-article)。

J M-#
     記事からダウンロードする印を消去する (gnus-agent-unmark-article)。

@
     記事をダウンロードするかどうかを切り替える (gnus-agent-toggle-mark)。ディフォルトではダウンロードの印は %。

J c
     キャッシュされていない、ダウンロードされていない、またはダウンロードできないすべての記事を既読にする (gnus-agent-catchup)。

J S
     このグループのすべての望ましい記事 (see Agent Categories) をダウンロードする。(gnus-agent-fetch-group)。

J s
     このグループのすべてのプロセス印が付いた記事をダウンロードする。 (gnus-agent-fetch-series)。

J u
     現在のグループのダウンロード可能な記事を、すべてダウンロードする (gnus-agent-summary-fetch-group)。

サーバーエージェント命令
............

J a
     現在のサーバーを、Gnus エージェントで扱われるサーバーの一覧に追加する (gnus-agent-add-server)。

J r
     現在のサーバーを、Gnus エージェントで扱われるサーバーの一覧から削除する (gnus-agent-remove-server)。

エージェントの視覚効果
-----------

オフライン (unplugged) のときに概略を開いた場合に、Gnus が現在エージェントに格納されているヘッダーよりも多くの記事があることを、そのグループの active (訳注: 何番から何番までの記事があるかを示す管理情報) の範囲から知っている場合、表題が [Undownloaded article #####] のようになっているいくつかの記事を見るかもしれません。それらは見当たらないヘッダーのための穴埋め (placeholders) です。印 (mark) を設定することはともかく、それらの穴埋めの一つでできることは多くはありません。最終的に Gnus がグループのヘッダーを取って来る機会を得たときに、それらの穴埋めは実際のヘッダーで自動的に置き換えられるでしょう。気になるならば、それらの穴埋めを読み飛ばすために、概略バッファーの動作を操作することができます (gnus-auto-goto-ignores 参照)。

すべての人にとって明白かもしれませんが、オフラインのときに利用できるのは、以前に差し込まれていた間 (plugged) にエージェントに取り込まれたヘッダーと記事だけです。言い換えると「差し込まれていた間に取り込むことを忘れると、オフラインのセッションを満足できるものにするには足りない」ということです。この理由のために、エージェントは概略バッファーに二つの視覚効果を加えます。これらの効果は、オフラインのときにどの記事が利用できるかをいつも知らせるために、ダウンロードの状態を表示します。

第一の視覚効果は %O 仕様です。この指示子を含めるために gnus-summary-line-format をカスタマイズすると、記事のダウンロードの状態を示す単一の文字が加わるでしょう。エージェントかキャッシュのどちらかに取り込まれた記事は、gnus-downloaded-mark (ディフォルトは +) を表示します。それら以外のすべての記事は gnus-undownloaded-mark (ディフォルトは -) を表示します。エージェント化されていないグループを開くと、空白 ( ) が表示されます。

第二の視覚効果はダウンロードされていないことを示すフェースです。多くの Gnus の利用者に好感と嫌悪をもたらすであろう、記事のスコアを三段階 (low, normal, high) で表示するフェースがあります。問題は、フェースの選択が条件検査とフェース名のリスト (gnus-summary-highlight 参照) で制御されることです。それぞれの条件は、それがリストの中に現れる順に検査されるので、後の条件よりも前の条件が優先されます。これが意味するすべては、ダウンロードされていない記事に可視記事 (ticked) の印を付けても、その記事は可視記事のフェースではなくて、ダウンロードされていない記事のフェースで表示し続けられるということです。

(記事を読むたびに同じ記事をダウンロードしないようにするため、または接続時間を最小にするために) エージェントをキャッシュとして使う場合は、ダウンロードされていない記事のフェースはおそらく良い考えのように思えるでしょう。ダウンロードされた記事に対してすべての仕事 (印を付ける、読む、削除する) を行なえば、いつも通常のフェースが現れるからです。NOV をキャッシュすることによってオンライン性能を改善するためにエージェントを使っている利用者にとって、ダウンロードされていない記事のフェースが見えるかもしれないことは、まったくぞっとするほどいやなことでしょう。それらのどの記事もエージェントに取り込まれていないので、ダウンロードされていない記事のフェースのために、すべての普通のフェースが目立たなくなってしまうでしょう。

ダウンロードされていない記事のフェースを使いたい場合は、 agent-enable-undownloaded-faces グループパラメーターを t に設定して、ダウンロードされていない記事のフェースを有効にしなければなりません。このパラメーターは他のすべてのエージェントパラメーターと同様に、エージェント分類 (see Agent Categories)、グループトピック (see Topic Parameters)、あるいは個々のグループ (see Group Parameters) に対して設定することができます。

エージェントを使うすべての利用者に共通した一つの問題は、それがディスクの容量をいかに速く使い尽くすことができるかです。あなたが多くのグループでエージェントを使用している場合、事実上ディスク容量を回復することはさらに困難です。一つの解は gnus-group-line-format にある %F 形式です。この形式は、エージェントとキャッシュの両方で取得した記事によって占められる実際のディスク容量を表示します。どのグループが最も多い容量を使うかを知ることによって、利用者は記事を「エージェント期限切れ消去」する場合に、どこに努力を集中するべきかがわかります。

キャッシュとしてのエージェント
---------------

Gnus が plugged であるときに、すでにエージェントに格納されているヘッダーや記事をダウンロードするのは効率的ではありません。そこで Gnus は通常ヘッダーを一回だけダウンロードしてエージェントに格納します。 plugged か unplugged にかかわらず、それらのヘッダーは後に概略バッファーを生成するときに使われます。ディフォルトでは記事は (それは潜在的にディスク空間を浪費するであろうから) エージェントにキャッシュされませんが、すでにエージェントにダウンロードした記事があるならば、Gnus はサーバーから再び記事をダウンロードせずに、手元に格納されたコピーを使います。

あなたがそう望むのであれば、plugged な期間は常にヘッダーと記事をダウンロードするように、エージェント (gnus-agent-cache 参照 Agent Variables) を設定することができます。Gnus はほとんど確かにもっと遅くなりますが、サーバーとの同期は保たれます。nntp か nnimap バックエンドを使っている場合は、たぶんこの最後の点は意味をなさないでしょう。

エージェント期限切れ消去
------------

エージェントバックエンド nnagent は期限切れ消去を扱いません。ええと、少なくとも他のバックエンドのようにそれを扱いません。その代わりに、特別な gnus-agent-expire と gnus-agent-expire-group 命令が gnus-agent-expire-days の日数よりも古い既読記事をすべて消去します。これらはあなたがディスク容量を使い切りそうだと思ったときにいつでも実行することができます。どちらも特に速くもなく効率的でもなく、それらの一つをいったん始めてしまったら (C-g やその他で) 中断することもあまり良いことではありません。

例えば gnus-request-expire-articles のような他の関数は、エージェントをグループに同期させるために gnus-agent-expire を実行するかもしれないことに注意して下さい。

エージェントパラメーター agent-enable-expiration は、選択したグループでの期限切れ消去を抑制するために使われるかもしれません。

gnus-agent-expire-all が nil でなければ、エージェントの期限切れ消去コマンド群はすべての記事---未読、既読、可視、保留記事を消去します。もし nil (これがディフォルト値) であれば、既読記事のみが消去の対象となり、未読、可視、保留記事はさらに無期限に保持します。

期限切れ消去されているはずなのに残っている記事を見つけたならば、たぶんいくつかの Gnus エージェントファイルが壊れています。 gnus-agent-regenerate と gnus-agent-regenerate-group は、起こりうる問題を修復するための特別なコマンドです。

エージェントを作り直す
-----------

nnagent によって使われるローカルのデータ構造は、ある例外的な条件によっておかしくなってしまうかもしれません。これが起こると、 nnagent の機能性が下がるかもしれないし、失敗しさえするかもしれません。この問題の解決策は、内部の矛盾をすべて削除することによって、ローカルのデータ構造を修復することです。

例えば、記事をエージェントにダウンロードしている間にサーバーへの接続が切れてしまう場合、ローカルのデータ構造は接続が切れる前に記事が首尾良くダウンロードされたかどうかを知りません。gnus-agent-regenerate または gnus-agent-regenerate-group を実行すると、そのような記事を二回ダウンロードしなくても済むようにデータ構造を更新します。

gnus-agent-regenerate コマンドは、すべてのエージェント化されたグループで gnus-agent-regenerate-group を実行します。どのバッファー上でも gnus-agent-regenerate を実行することができますが、最初にすべての概略バッファーを閉じることを強く勧めます。

gnus-agent-regenerate-group コマンドは、ローカルの NOV (ヘッダー) データベースを修復するために、個々の記事のローカルなコピーを使います。その後それは、どの記事がローカルに格納されるかを裏付けるための内部データ構造を更新します。引数を与えると、エージェントの中の記事に未読の印を付けます。

エージェントを IMAP で使う方法
------------------

エージェントは nnimap を含む Gnus のどんなバックエンドでも動作します。しかし NNTP と IMAP にはいくつかの概念の違いがあるので、この項では Gnus エージェントを IMAP の unplugged なモードのクライアントとして円滑に使えるようにするための、いくつかの情報を提供します。

心に留めておく最初のことは、すべてのフラグ (read, ticked など) は nntp の場合における .newsrc ではなくて IMAP サーバーに保持されるということです。したがって、Gnus は unplugged のときのフラグの変化を覚えておいて、再び接続したときにそれらのフラグを同期させる必要があります。

Gnus はエージェントの元で nnimap グループを読むとき、フラグの変化に絶えず注意しています。あなたが再び接続したとき、Gnus はあなたが何らかのフラグを変更したかどうかを調べて、あなたがそれらをサーバーと同期させたいかどうかを尋ねます。この挙動は gnus-agent-synchronize-flags でカスタマイズすることができます。

もし gnus-agent-synchronize-flags が nil だったら、エージェントは自動的にフラグを同期させることはしません。もしそれがディフォルト値の ask だったら、エージェントはあなたが再接続したときにあなたが何らかの変更を行なっていたかどうかを調べて、それらを同期させたいかどうかを尋ねます。もしそれら以外の値だった場合は、すべてのフラグは自動的に同期させられます。

もしあなたが、再接続したときに自動でフラグを同期させたくないなら、手動でそれを行なうこともできます。これにはグループバッファーの J Y キーに割り当てられた gnus-agent-synchronize-flags コマンドを使います。

あなたが、unplugged のときの IMAP クライアントに期待するであろういくつかの機能は、現在のエージェントには盛り込まれていません。それらは以下の通りです。

  * unplugged のときの nnimap グループへのコピーと移動。

  * unplugged のときの nnimap グループの作成と削除。

技術的注釈: すべてのローカルなフラグを一度にサーバーに ``押し込む'' 同期はできませんが、利用者が一つずつフラグを更新することは可能です。したがって、あなたが記事の一つのフラグをセットして、そのグループを抜け出てから再度そのグループを選択してそのフラグを消せば、あなたが ``同期'' の操作を行なったときに、そのフラグはセットされてサーバーからは削除されます。 "The queued flag" に関する動作は、エージェントディレクトリーにあるサーバー毎の flags ファイルの中で見つかるでしょう。それらはあなたがフラグを同期させたときに空になります。

差出用メッセージ
--------

ディフォルトで、Gnus が切り離されているとき、すべての差出用メッセージ (メールとニュースの両方) は下書きグループ ``queue'' (see Drafts) に格納されます。投稿した後でも、ここでそのメッセージを見たり編集するのは意のままです。

送出するメールが queue される (順番待ちになる) 状況を制御することは可能です (gnus-agent-queue-mail, Agent Variables 参照)。Gnus が切り離されている場合、ニュースは常に queue されるだけです。

メッセージを送信するために、下書きグループから、そこで使える特別な命令を使って送ることも、グループバッファー内で J S を使って、下書きグループ内のすべての送信可能なメッセージ送信することもできます。ニュースの投稿は Gnus が差し込まれているときだけできますが、メールはいつでも送信することができます。

切り離されているときにメールの送信ができず、かつ切り離されているときにうっかり J S を叩いてしまうことが心配ならば、Gnus にあなたの行動を確認させることができます (gnus-agent-prompt-send-queue, Agent Variables 参照)。

エージェント変数
--------

gnus-agent
     エージェントが有効になっているかどうか。ディフォルトは t です。最初に有効にされると、いくつかのバックエンドをエージェント化するために、エージェントは gnus-agent-auto-agentize-methods を使います。サーバーバッファーでエージェントのコマンドを使うことによって、どのバックエンドをエージェント化するかを変更することができます。

     サーバーバッファーに入るには、グループバッファーで ^ (gnus-group-enter-server-mode) を使って下さい。

gnus-agent-directory
     Gnus エージェントがファイルを格納する場所です。ディフォルト値は ~/News/agent/ です。

gnus-agent-handle-level
     この変数の値より高いレベル (see Group Levels) のグループは、エージェントからは無視されます。ディフォルト値は 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-consider-all-articles
     gnus-agent-consider-all-articles が非-nil だったら、エージェントはすべての記事について、それらをダウンロードする必要があるかどうかをエージェントの述語に決定させます。nil だった場合、それがディフォルトですが、エージェントは未読の記事をダウンロードするかどうかだけを述語に決定させます。これを有効にするには、後でエージェントが期限切れ消去する記事を何度も繰り返しダウンロードしないように、エージェントの期限切れ消去の設定 (see Category Variables) を見直す必要もあるかもしれません。

gnus-agent-max-fetch-size
     エージェントは、取得した記事を個々のファイルに入れるための解析を行なう前に、それらを一時的なバッファーへ取り込みます。最大のバッファーサイズを超過しないようにするために、記事がすべて取得されるまで、エージェントは取得と解析を交互に行ないます。gnus-agent-max-fetch-size は、繰り返しがどれくらい頻繁に起きるかを制御するための、サイズの限界を規定します。大きな値は性能を改善します。小さな値は、万が一取得している間に接続が切れた場合に、遅れ時間を最小にします (グループの状態を更新するために gnus-agent-regenerate-group を実行する必要があるかもしれません。でも、接続が切れる前に解析されたすべての記事は、unplugged の期間に利用することができるでしょう。)。繰り返しに遭遇することは珍しいので、ディフォルトは 10M です

gnus-server-unopen-status
     たぶんエージェント変数ではないがエージェントに密接に関連するこの変数は、 Gnus がサーバーに接続できなときに何が起きたかを物語ります。エージェントが活性化されると、ディフォルトの nil では、利用者がサーバーとの接続を絶つかエージェントを unplug にするかを Gnus に尋ねさせます。エージェントが不活性化されると、Gnus はいつも単にサーバーとの接続を絶ちます。この変数の他の選択肢には denied と offline があり、エージェントが使われる場合は後者だけが有効です。

gnus-auto-goto-ignores
     大抵の人は、エージェント変数ではないが密接に関連するもう一つの変数をここで探すでしょう。この変数は、ダウンロードされていない (ヘッダーだけがエージェントに格納された)、そして取り込まれていない (記事もヘッダーも格納されていない) 記事をどう操作するかを概略バッファーに伝えます。

     正当な値は nil (どの記事も操作する)、 undownloaded (unplugged な期間の操作は取り込まれていない記事を無視すること)、always-undownloaded (操作は取り込まれていない記事を常に無視すること)、unfetched (操作はヘッダーが取り込まれていない記事を無視すること) です。(訳注: うーむ Kevin さんは何を言ってるんだ?)

gnus-agent-queue-mail
     gnus-agent-queue-mail を always にすると、Gnus はメールをいきなり送信してしまうのではなく、常に queue (順番待ち) に入れます。 t だったら Gnus は切り離されているときだけメールを queue に入れます。nil だったら queue に入れません。ディフォルトは t です。

gnus-agent-prompt-send-queue
     gnus-agent-prompt-send-queue が非-nil だったら、切り離されているのにもかかわらず J S を叩いた場合に、Gnus は本当にそれを行なっても良いかどうかを確認します。ディフォルトは nil です。

gnus-agent-auto-agentize-methods
     あなたが以前にエージェントを使ったことが無い (もっと技術的には、 ~/News/agent/lib/servers が無い場合)、Gnus はほんの少数のサーバーを自動的にエージェント化します。この変数はどのバックエンドを自動でエージェント化すべきかを制御します。一般に、エージェント化は遠隔バックエンドだけに有用です。自動のエージェント化は、サーバーに対して J a を実行するのと同じ効果があります (see Server Agent Commands)。もしファイルが存在するならば、それらを追加したり削除するためにサーバーを手動で操作しなければなりません。この変数は最初に Gnus を起動したときだけ適用されます。ディフォルトは (nntp nnimap) です。

設定例
---

もしあなたがこのマニュアルを読みたくなくて、ごく標準的な設定がされているとするなら、あなたの ~/.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 で削除グループをすべて画面から消去します。(A k で削除グループはすべて戻ってきます。)

さて、ここでその場でグループを読むこともできるし、あるいは J s 命令で記事をダウンロードすることもできます。あとはこのマニュアルの残りを読んで、その他の何百億の項目からカスタマイズしたいことを見つけ出して下さい。

一括エージェント処理
----------

Gnus エージェントに記事を取得させるのは (そしてあなたの書いた何かのメッセージを投稿するのは)、いったんものごとを正しく設定してしまえば非常に簡単です。以下のシェルスクリプトは必要なことをすべてやってくれるでしょう。

以下の呪文をコマンドラインで使うことによって、完全なバッチコマンドを走らせることができます:

     #!/bin/sh
     emacs -batch -l ~/.emacs -l ~/.gnus.el gnus-agent-batch >/dev/null 2>&1

エージェントの問題点
----------

Gnus エージェントは、よくある他のオフラインニュースリーダーのようには動作しません。これらは想像的な人からの良くある質問です:

接続されているときに記事を読んだら、それは Agent に入るのですか?

     いいえ。この動作を望むのならば gnus-select-article-hook に関数 gnus-agent-fetch-selected-article を加えて下さい。

接続されているときに記事を読んで、Agent に記事が存在している場合、
     もう一回ダウンロードされるのですか?

     いいえ、ただし gnus-agent-cache が nil でなかったら、ですが。

要約すると、Gnus が切り離されているときはローカルに保存された記事を見るだけです。接続されているときは ISP と話し、かつローカルに持っている記事も使うかもしれません。

スコア
***

他の人々は 削除ファイル を使いますが、ここ Gnus タワーは削除よりもスコアの方を好むので、他と格闘するよりは切り替えることにしました。それらは完全に違うことをするので、真っ直ぐに座って注意を払って下さい!

すべての記事はスコアのディフォルト値を持っており (gnus-summary-default-score)、これはディフォルトで 0 です。このスコアは対話的や、スコアファイル (score file) の方法により、上げられたり下げられたりします。gnus-summary-mark-below よりも低いスコアの記事には既読の印が付きます。

Gnus は概略バッファーを作成する前に、現在のグループに適用されるどんな スコアファイル も読み込みます。

現在の記事に基づいてスコアの登録を挿入するいくつかの命令が概略バッファーにあります。例えば、Gnus に特定の表題の記事のスコアを下げたり上げたりするように求めることができます。

二種類のスコア項目があります: 永続と一時的です。一時的スコア項目は自分自身で期限がくると削除する登録です。例えば、一週間以上使われていないどんな登録も、スコアファイルの大きさを小さくするために、静かに削除されます。

概略スコア命令
=======

スコア項目を変更するスコア命令は実際に本当のスコアファイルを修正するわけではありません。それはあまりに非効率です。Gnus は以前にロードされたスコアファイルのキャッシュを保持しており、その一つは 現在のスコアファイル連想リスト (current score file alist) と考えられています。スコア命令は単純にこのリストに登録を挿入して、グループから出ると、このリストは保存されます。

現在 (current) のスコアファイルは、実際にそのようなスコアファイルが存在していない場合でも、ディフォルトでグループのローカルスコアファイルになっています。スコア命令を何か他のスコアファイル (例、all.SCORE) に挿入したいなら、まずこのスコアファイルを現在のものにしなければなりません。

一般的なスコア命令は実際にはスコアファイルを変更しません:

V s
     現在の記事のスコアを設定します (gnus-summary-set-score)。

V S
     現在の記事のスコアを表示します (gnus-summary-current-score)。

V t
     現在の記事に使われているすべてのスコア法則 (score rule) を表示します (gnus-score-find-trace)。*Score Trace* バッファーで、e をタイプして現在行のスコア法則に対応するスコアファイルを編集することができ、f ではスコアファイルのフォーマット (gnus-score-pretty-print) と編集を行なうことができます。

V w
     スコアに使われている語のリストを表示します (gnus-score-find-favourite-words)。

V R
     現在の概略でスコア過程を実行します (gnus-summay-rescore)。これは Gnus の後ろでいろいろとスコアファイルで遊んで、それの効果を見たいときに役立つかもしれません。

V c
     違ったスコアファイルを現在のものにします (gnus-score-change-score-file)。

V e
     現在のスコアファイルを編集します (gnus-score-edit-current-scores)。 gnus-score-mode バッファーに移動することになるでしょう (see Score File Editing)。

V f
     スコアファイルを編集して、このスコアファイルを現在のものにします (gnus-score-edit-file)。

V F
     現在のスコアキャッシュを書き込みます (gnus-score-flush-cache)。これはスコアファイルを編集した後に役に立ちます。

V C
     視覚的で嬉しい方法でスコアファイルをカスタマイズします (gnus-score-customize)。

これらの命令の残りはローカルスコアファイルを修正します。

V m
     スコアの入力を促進し、それよりも低いスコアのすべての記事に既読の印を付けます (gnus-score-set-mark-below)。

V x
     スコアの入力を促進し、そのスコアより低いすべての記事を削除するためのスコア法則を現在のスコアファイルに付け加えます (gnus-score-set-expunge-below)。

実際にスコア項目をするためのキー打ち込みは非常に規則正しい法則に従うので、それらの命令すべてを表に上げる必要はありません。(たーくさんあります。)

 1. 最初のキーはスコアを増やすための I (i の大文字) か、スコアを下げるための L です。

 2. 二番目のキーはどのヘッダーにスコアをしたいかを表します。以下のキーが使用可能です:

     a
          著者 (author) の名前にスコアを付けます。

     s
          表題 (subject) の行にスコアを付けます。

     x
          Xref 行にスコアを付けます---すなわち、クロスポスト行です。

     r
          References 行にスコアを付けます。

     d
          日付 (date) にスコアを付けます。

     l
          行数 (number of lines) にスコアを付けます。

     i
          Messsage-ID ヘッダーにスコアを付けます。

     e
          ``追加'' のヘッダー (すなわち、(gnus-extra-headers に設定されていて、NNTP サーバーが overview にそれらの情報を記録している) にスコアを付けます。

     f
          フォローアップ (followup) にスコアを付けます---これは著者名との合致をし、この著者へのフォローアップにスコアを加えます。(このキーを使うことによって ADAPT ファイルが生成されます。)

     b
          記事の本文にスコアを付けます。

     h
          ヘッダーにスコアを付けます。

     t
          スレッドにスコアを付けます。(このキーを使うことによって ADAPT ファイルが生成されます。)

 3. 三番目のキーは合致する型です。どの合致の型が有効かはどのヘッダーにスコアを付けようとしているかに依ります。

     文字列 (strings)

          e
               正確な (exact) 合致です。

          s
               文字列の一部の (substring) 合致です。

          f
               大雑把な (fuzzy) 合致です (see Fuzzy Matching)。

          r
               正規表現 (regexp) の合致です。

     日付 (date)

          b
               日付の前 (before) です。

          a
               日付の後 (after) です。

          n
               その日付です。

     数値 (number)

          <
               数値より小さいものです。

          =
               数値と等しいものです。

          >
               数値より大きいものです。

 4. 四つめで通常は最後のキーです。これが一時的 (すなわち期限切れ消去) のスコア項目か、永続的な (すなわち期限切れ消去でない) スコア項目であるかということ、もしくはすぐになされるべきか、スコアファイルに追加することはしないかということを指定します。

     t
          一時的な (temporary) スコア項目です。

     p
          永続的な (permanent) スコア項目です。

     i
          即座の (immediate) スコア付けです。

 5. もし `e' (追加の (extra)) ヘッダーでスコア付けを行なっていると、どの名前のヘッダーで行なうかを尋ねられます。これは gnus-extra-headers にある名前でなければなりません。TAB による補完ができます。

ですから、現在の著者に正確な合致で永続的にスコアを増やしたいとしましょう: I a e p。表題に基づいてスコアを下げたくて、文字列の部分の合致を使い、一時的なスコア項目をしたいのであれば: L s s t。非常に簡単です。

ものごとを複雑にするのは、短縮打鍵が存在するからです。二番目か三番目の文字に大文字を使うと、Gnus は残る一つか二つの打鍵にディフォルト値を使います。ディフォルト値は ``文字列の一部'' と ``一時的'' です。ですから、 I A は I a s t と同じで、I a R は I a r t と同じです。

これらの関数は数値接頭引数と、シンボル接頭引数を受け付けます (see Symbolic Prefixes)。数値接頭引数はどのくらい記事のスコアを下げる (もしくは上げる) かを指定します。シンボル接頭引数 a は命令が現在のスコアファイルではなく all.SCORE ファイルを使うことを指定します。

gnus-score-mimic-keymap はこれらの命令がキーマップであるかのように振る舞うかどうかを指定します。

グループスコア命令
=========

残念ながら、まだたくさんはありません。

W e
     すべてのグループに適用される all.SCORE ファイルを編集します。ポップアップする gnus-score-mode のバッファーに入ります (see Score File Editing)。

W f
     Gnus は何度もスコア連想リストを読み込むのを避けるために、それのキャッシュを保持しています。この命令はキャッシュを書き出します (gnus-score-flush-cache)。

以下のようなことをすることによって、コマンド行からスコア付けをすることができます。

     & emacs -batch -l ~/.emacs -l ~/.gnus.el -f gnus-batch-score

スコア変数
=====

gnus-use-scoring
     nil であれば、Gnus はスコアファイルを調べず、一般的に、スコア関連の仕事をまったくしません。これはディフォルトで t です。

gnus-kill-killed
     この変数が nil であれば、Gnus はすでに削除過程を実行された記事に決してスコアファイルを適用しません。これはたくさんの時間を節約するでしょうが、もし削除ファイルをグループに適用しているときに、削除ファイルを変更し、もっと多くの記事を削除するためにそれを再実行しても、それは動作しないということになります。それをするためにはこの変数を t に実行しなければなりません。(これはディフォルトで t です。)

gnus-kill-files-directory
     すべての削除とスコアのファイルはこのディレクトリーに蓄積され、それはディフォルトでは環境変数 SAVEDIR によって初期化されます。ディフォルト値は ~/News/ です。

gnus-score-file-suffix
     スコアファイルにたどり着くためにグループ名に加える接尾語です (ディフォルト値は SCORE です)。

gnus-score-uncacheable-files
     すべてのスコアファイルは普通はスコアファイルの過剰読み込みを避けるためにキャッシュされます。しかし、これによりあなたの Emacs が大きく肥大化するのであれば、再び必要とされないようなスコアファイルを除去するためにこの正規表現を使うことができます。all.SCORE のキャッシュを止めるのは悪い考えですが、comp.infosystems.www.authoring.misc.ADAPT をキャッシュしないのは良い考えでしょう。実際のところ、この変数のディフォルト値は ADAPT$ で、適応スコアファイルはキャッシュされません。

gnus-save-score
     もし本当に複雑なスコアファイルを持っていて、たくさんの一括スコアをするのであれば、この変数を t に設定すると良いかもしれません。これは Gnus にスコアを .newsrc.eld ファイルに保存するようにさせます。

     これを t に設定しなければ、手動スコア (V s (gnus-summary-set-score) で設定されたようなもの) はグループ移動時に保存されません。

gnus-score-interactive-default-score
     すべての対話的スコア上げ/下げ命令によって使われる上げ/下げするスコアです。ディフォルトは 1000 で、過剰だと思うかもしれませんが、これは適応スコア付けをする余地の存在することを確実にするためです。手で登録されたデータを適応スコアでの小さな変更で上書きされたくはありません。

gnus-summary-default-score
     記事のスコアのディフォルト値で、ディフォルトでは 0 になっています。

gnus-summary-expunge-below
     この変数より低いスコアを持つ記事は概略の行に表示されません。ディフォルト値は nil で、これはどの記事も隠されないということです。この変数は各概略バッファーに固有で、gnus-summary-mode-hook によって設定されるべきです。

gnus-score-over-mark
     ディフォルトのスコアより大きなスコアを持つ記事に対して (三桁目に) 使われる印です。ディフォルト値は + です。

gnus-score-below-mark
     ディフォルトのスコアより小さなスコアを持つ記事に対して (三桁目に) 使われる印です。ディフォルト値は - です。

gnus-score-find-score-files-function
     現在のグループのスコアファイルを見つけるために使われる関数です。この関数はグループ名を引数として呼ばれます。

     使用可能な既定関数は:

     gnus-score-find-single
          グループ自身のスコアファイルだけを適用します。

     gnus-score-find-bnews
          bnews 構文を使って、すべての合致するスコアファイルを適用します。これがディフォルトです。例えば、現在のグループが gnu.emacs.gnus ならば、 gnu.all.SCORE, not.alt.SCORE と gnu.all.SCORE がすべて適用されます。要するに、スコアファイル名の all が .* に変換され、それから正規表現の合致がなされます。

          これは、すべてのグループに適用したいスコア項目がいくつかある場合は、それらの登録を all.SCORE ファイルに入れるということです。

          Gnus は一般的なスコアファイルを特定のスコアファイル向けのものより前に適用しようと試みますが、スコアファイルはほとんど無作為の順番で適用されます。これはスコアファイル名の要素の数を調べることによってなされます--- all 要素を取り除いて。

     gnus-score-find-hierarchical
          すべての親グループからのすべてのスコアファイルを適用します。これは all.SCORE のようなスコアファイルを持つことはできないけれど、 SCORE, comp.SCORE と comp.emacs.SCORE を、それぞれのサーバーに対して持つことができるということです。

     この変数は関数のリストであることもできます。その場合は、これらのすべての関数がグループ名を引数として呼ばれ、スコアファイルの返されたすべてのリストが適用されます。これらの関数は直接スコア連想リストのリストのリストを返すこともできます。その場合は、それらのファイルでないスコア連想リストを返す関数は、返される最後のスコアファイルがローカルスコアファイルであることを確実にするために、おそらく ``本当の'' スコアファイル関数よりも前に置かれるべきでしょう。ふぅ。

     例えば、サーバーを特定しない全体スコアファイルを使って、親グループに準じたスコア付けを行なうならば、次の値を使えば良いでしょう。

          (list (lambda (group) ("all.SCORE"))
                'gnus-score-find-hierarchical)

gnus-score-expiry-days
     この変数は使われていないスコアファイル登録が期限切れ消去されるまでどのくらいの日が経つべきかを指定します。この変数が nil であると、スコアファイル登録は削除されません。ディフォルト値は 7 です。

gnus-update-score-entry-dates
     この変数が nil でないと、一時的に合致したスコア項目は日付が更新されます。(これは Gnus が期限切れ消去を操作している方法です---すべての合致しない登録は古くなりすぎ、合致する登録を新鮮で若いままです。) しかし、この変数を nil に設定すると、合致する登録でさえも古くなり、あの嫌な死神と直面することになるでしょう。

gnus-score-after-write-file-function
     そこでちょうど書かれたスコアファイルの名前と共に呼ばれる関数です。

gnus-score-thread-simplify
     この変数が nil でないと、記事表題はスレッドと同じ方法で表題スコアのために単純化されます---現在の gnus-simplify-subject-functions の値によって。スコア項目が 文字列部分 か 正確な 合致を使っていると、合致もこの方法で単純化されます。

スコアファイル様式
=========

スコアファイルは普通は単純な様式のものだけを含む emacs-lisp ファイルです。無頓着な利用者はこれを編集しないで下さい。すべては概略バッファーから変更されるでしょう。

とにかく、それを自分でいじってみたくなったのなら、例があります:

     (("from"
       ("Lars Ingebrigtsen" -10000)
       ("Per Abrahamsen")
       ("larsi\\|lmi" -50000 nil R))
      ("subject"
       ("Ding is Badd" nil 728373))
      ("xref"
       ("alt.politics" -1000 728372 s))
      ("lines"
       (2 -100 nil <))
      (mark 0)
      (expunge -1000)
      (mark-and-expunge -10)
      (read-only nil)
      (orphan -10)
      (adapt t)
      (files "/hom/larsi/News/gnu.SCORE")
      (exclude-files "all.SCORE")
      (local (gnus-newsgroup-auto-expire t)
             (gnus-summary-make-false-root empty))
      (eval (ding)))

この例はたいていのスコアファイルの要素を説明しています。違った方法については、Advanced Scoring を見て下さい。

これは Lisp コードのように見えますが、実際はここにあるものは何も 評価 (eval) されません。しかし、Lisp リーダーがこの様式を読み込むのに使われるので、意味的に有効でないとしても、文法的には有効です。

この連想リストでは六つのキーを使うことができます。

文字列 (STRING)
     もしキーが文字列であると、それは合致が実行されるヘッダーの名前です。スコアはこれらの八つのヘッダーだけに実行されます: From, Subject, References, Message-ID, Xref, Lines, Chars および Date です。これらのヘッダーに加えて、記事全体を取得して記事のより大きな部分で Gnus に合致を求めさせる三つの文字列があります: Body は記事の本文で合致を求め、 Head は記事のヘッダーで合致を求め、All は記事全体で合致を求めます。これら最後の三つのキーを使うことは、グループに入るときに速度を かなり 遅くすることに気を付けて下さい。スコアを付けることのできる最後の ``ヘッダー'' は Followup です。これらのスコア項目は、それに合致する記事へのすべてのフォローアップのための新しいスコア項目が付け加えられます。

     このキーに続くのは任意の数のスコア項目で、それぞれのスコア項目は一つから四つまでの要素を持ちます。

      1. 最初の要素は 合致要素 です。たいていのヘッダーではこれは文字列ですが、Lines と Chars ヘッダーではこれは整数でなければなりません。

      2. もし二番目の要素が存在するなら、それは数値であるべきです---スコア要素。この数値は負の無限大から正の無限大までの間の整数であるべきです。もし合致が成功すれば、この数値が記事のスコアに加えられます。もしこの要素が存在していなければ、数値 gnus-score-interactive-default-score が代わりに使われます。ディフォルト値は 1000 です。

      3. もし三番目の要素が存在していると、それは数値であるべきです---日付要素 です。この日付は最後にこのスコア項目が合致した時刻を示し、これはスコア項目の期限切れ消去機構の機能のために使われます。この要素が存在していなければ、スコア項目は永続します。日付は紀元前 1年12月31日から経過した日にちの数で表されます。

      4. もし四番目の要素が存在していると、それはシンボルであるべきです---型要素 です。この要素はこのスコア項目が記事に合致するかどうかを調べるのにどの関数が使われるべきであるかを指定します。

          From, Subject, References, Xref, Message-ID
               たいていのヘッダーの型に対して、r と R (正規表現) (regexp) や、s と S (文字列の一部) (substring) 型、 e と E (正確な合致) (exact match)、 w (語の合致) (word match) 型が存在します。もしこの要素が存在しないと、Gnus は文字列の一部の合致が用いられるべきであるとみなします。 R, S, E は合致が大文字と小文字を区別する方法で行なわれるという点で他のものと異なります。すべてのこれらの一文字型は本当は regexp, exact, word 型の短縮形で、もしそうしたいと思えばこちらを代わりに使うことができます。

          Extra
               標準の overview ヘッダーの文字列と同様、gnus-extra-headers を使っていると、それらのヘッダーの値にスコアを付けることができます。この場合スコア項目の 5 番目の要素がスコアを付けるヘッダーの名前になります。 NNTP サーバーが overview に NNTP-Posting-Host を記録しているならば、all.SCORE ファイルの以下の登録は、単一のホストから spam の攻撃がある場合に有効です。

                    ("111.222.333.444" -1000 nil s
                     "NNTP-Posting-Host")

          Lines, Chars
               これらの二つのヘッダーは違った合致の型を使います: <, >, =, >=, <= です。

               これらの述語はもし

                    (PREDICATE HEADER MATCH)

               の評価が nil でないと、真となります。例えば、上級合致 ("lines" 4 <) (see Advanced Scoring) は結果として以下の式になります。

                    (< header-value 4)

               もしくは他の方法にしましょう: < を Lines で 4 を合致として使っているときは、記事が 4 行よりも少ないときにスコアが追加されます。(混乱して、反対ではないかと考え易いです。でも、そうではないのです。私が思うに。)

               合致が Lines でなされていると、いくつかのバックエンド (nndir のようなもの) は Lines ヘッダーを作成しないためにすべての記事が 0 行であるとして扱われることに気を付けて下さい。これはもし少しの行しかない記事のスコアを下げているのなら、変な結果が起こり得ることになります。

          Date
               Date (日付) ヘッダーには三つのなんとなくばかげている合致の型があります: before, at, after です。私は本当にこれが役立つような機会を想像できないのですが、この関数を提供しないのもなんとなくばかげています。そうした場合のためにあるのです。いつ必要になるかは誰にもわかりません。転ばぬ先の杖。短気は損気。本をカバーで判断しては行けません。初めてのデートでエッチしてはいけません。(しかし、私は少なくとも一人、引用しますが、``この関数は欠かせないものであることがわかった'' と言った人がいると聞いています。)

               (訳注: 原典の "Once burnt, twice shy" を "短気は損気" としましたが、もっと適切な訳があればお知らせ下さい。)

               もっと役立つ合致の型は 正規表現 です。それによって日付文字列に正規表現を用いて合致させることができます。日付はまず ISO8601 短縮様式 (compact format) に標準化されます---YYYYMMDDTHHMMSS です。例えば、もしすべての年の 4月1日 に投稿されたすべての記事にが治させたいのであれば、 ....0401......... を合致文字列として使うことができます。(日付は元々の標準時で保存されているので、その記事が投稿されたところで 4月1日 に投稿された記事に合致することに注意して下さい。標準時は一家にとって非常に有益な楽しみでしょう?)

          Head, Body, All
               これらの三つの合致のキーは From ヘッダー (など) と同じ合致の型を使います。

          Followup
               この合致のキーは少し特別で、それは From ヘッダーに合致し、合致した記事だけでなくその記事へのすべてのフォローアップのスコアにも影響します。これはたとえば、あなた自身の記事へのフォローアップのスコアを増やしたり、良く知られた問題児へのフォローアップ記事のスコアを下げたりするのに使われます。From ヘッダーが使うのと同じ型の合致を使います。(この合致キーを使うと、ADAPT ファイルを作ることになります。)

          Thread
               この合致キーは Followup 合致キーと同じ行に動作します。 Message-ID X で始まっているスレッド (または副スレッド) にスコアを付けたいのであれば、thread 合致を付け加えます。これは Reference ヘッダーに X を持つそれぞれの記事に新しい thread 合致を追加します。(これらの新しい thread 合致はこれらの合致する記事の Message-ID を使います。) これはスレッドのいくつかの記事が完全な References ヘッダーを持っていなかったとしても、スレッド全体のスコアを上げ/下げできることを保証します。これを使うと、スレッドの記事に決定的でないスコアが付くかもしれないということに注意して下さい。(この合致キーを使うと、ADAPT ファイルを作ることになります。)

mark
     この登録の値は数値であるべきです。この数値より低いスコアの記事には既読の印が付きます。

expunge
     この登録の値は数値であるべきです。この数値より低いスコアの記事は概略バッファーから削除されます。

mark-and-expunge
     この登録の値は数値であるべきです。この数値より低いスコアの記事には既読の印が付き、概略バッファーから削除されます。

thread-mark-and-expunge
     この登録の値は数値であるべきです。スコアの総計がこの数値より低いスレッドには既読の印が付き、概略バッファーから削除されます。 gnus-thread-score-function はスレッドのスコアの総計をどのように計算するかを指定します。

files
     この登録の値は任意の数のファイル名であるべきです。これらのファイルもスコアファイルであるとみなされ、これがされたのと同じような方法で読み込まれます。

exclude-files
     この登録の手がかりは任意の数のファイル名であるべきです。これらのファイルは何らかの理由で普通は読み込まれるようになっていたとしても、読み込まれません。

eval
     この登録の値は 評価 されます。この要素は全体的スコアファイルを扱っているときは無視されます。

read-only
     読み込み専用スコアファイルは更新されたり保存されたりしません。全体的スコアファイルはこのアトムを使用するべきです (see Global Score Files)。 (注意: 全体的 はここでは本当に 全体的 という意味です。個人的なすべてのグループに適用するスコアファイルのことではありません。)

orphan
     この登録の値は数値であるべきです。親記事を持たない記事はスコアにこの数値が加えられます。comp.lang.c のような量の多いニュースグループを追いかけているとして下さい。おそらく二、三のスレッドと新しいスレッドだけを追いたいでしょう。

     以下の三つのスコアファイル登録によってそれをすることができます:

                  (orphan -500)
                  (mark-and-expunge -100)

     最初にこのグループに入ったときは、新しいスレッドだけを見ます。それからおもしろいと思ったスレッドのスコアを上げ (I T もしくは I S によって)、残りを無視 (C y) します。次にグループに入ったときは、おもしろいスレッドの新しい記事とまったく新しいスレッドを見ることになります。

     すなわち---orphan (孤児) スコアアトムは普通のスコア法則では発見できない興味深いスレッドが少し存在しする量の多いグループのためにあります。

adapt
     この登録は適応スコアを制御します。もしこれが t であると、ディフォルトの適応スコア法則が使われます。もしこれが ignore であると、このグループには適応スコアは実行されません。もしリストであると、そのリストは適応スコア法則として用いられます。もしそれが存在しないか、 t や ignore でない他のものであれば、ディフォルトの適応スコア法則が使われます。たいていのグループに適応スコアを使いたいのであれば、 gnus-use-adaptive-scorint を t に設定し、(adapt ignore) を適応スコアをしたくないグループに挿入するでしょう。少しのグループでだけ適応スコアを行ないたいのであれば、 gnus-use-adaptive-scoring を nil に設定し、 (adaptive t) をそれを行ないたいグループのスコアファイルに挿入するでしょう。

adaptive-file
     すべての適応スコア項目はこの登録によって名づけられたファイルに入ります。それはグループに入るときにも適用されます。このアトムは多くのグループに同じ適応スコアファイルを用いることによって、複数のグループに一度に適応スコアを付けたいときに便利でしょう。

local
     この登録の値は (VAR VALUE) 対のリストであるべきです。それぞれの VAR は現在の概略バッファーのバッファー固有になり、指定された値 (value) に設定されます。これは便利な、もし少し変だとしても、フックをあまり好まないいくつかのグループで変数を設定する方法です。 VALUE は評価されないことに注意して下さい。

スコアファイル編集
=========

普通はすべてのスコア命令を概略バッファーから発行しますが、手でそれらを編集したい気に駆られるかもしれないので、それのためのモードを提供しています。

それは単純に少しカスタマイズされた emacs-lisp モードで、以下の追加の命令が存在します:

C-c C-c
     あなたが行なった変更を保存して概略バッファーに戻ります (gnus-score-edit-done)。

C-c C-d
     現在の日付を数値様式で挿入します (gnus-score-edit-insert-date)。もしこれがどのようなものであろうと考えているのであれば、これは本当に日の数値です。

C-c C-p
     適応スコアファイルは整えられていない流儀で保存されます。もしこれらのファイルの内の一つを読みたいと思っているのであれば、まず 素敵な表示 をしたいでしょう。この命令 (gnus-score-pretty-print) があなたのためにそれをします。

このモードを使うためには M-x gnus-score-mode と打って下さい。

gnus-score-menu-hook がスコアモードバッファーで実行されます。

概略バッファーでは、V f、V e および V t のような命令でスコアファイルの編集を始めることができます。

適応性スコア
======

これらのスコア付けはあなたを憂鬱にさせてしまうかもしれないので、Gnus にはこれらをすべて自動的に---まるで魔法でも使ったように作成する方法があります。いやむしろ、人工無能によって、という方が正確かな。

記事を読んだとき、あるいは記事に既読の印を付けたとき、記事を削除したときに、その印を残しておいて下さい。グループから出るときに Gnus は、それらの印の辺りを嗅ぎ回り、何の印を見つけたかに依存してスコア要素を追加します。この機能は gnus-use-adaptive-scoring を t か (line) に設定することで有効になります。もしスコアを、表題に現れる個別の単語をもとに適応させたければ、この変数を (word) に設定して下さい。両方の適応方法を使いたければ、この変数を (wordline) に設定して下さい。

gnus-default-adaptive-score-alist 変数をカスタマイズすることで、スコア付けの処理を完全に制御できます。例えば、このような感じになります。

     (setq gnus-default-adaptive-score-alist
           '((gnus-unread-mark)
             (gnus-ticked-mark (from 4))
             (gnus-dormant-mark (from 5))
             (gnus-del-mark (from -4) (subject -1))
             (gnus-read-mark (from 4) (subject 2))
             (gnus-expirable-mark (from -1) (subject -1))
             (gnus-killed-mark (from -1) (subject -3))
             (gnus-kill-file-mark)
             (gnus-ancient-mark)
             (gnus-low-score-mark)
             (gnus-catchup-mark (from -1) (subject -1))))

見てお分かりのように、この連想リストの各要素は、キーとして印 (変数名かもしくは ``本当の'' 印---つまり文字) を持ちます。このキーの後には任意の数のヘッダー/スコアの組が続きます。もしそのキーの後にヘッダー/スコアの組が一つもなければ、そのキーが記事の印としてついている記事に対しては適応性スコアは実行されません。例えば上記の例では、gnus-unread-mark がついている記事は適応性スコアの登録項目にはなりません。

各記事はただ一つの印しか持ち得ないので、それぞれの記事にはこれらの規則のうちただ一つしか適用されません。

gnus-del-mark を例に取りましょう---この連想リストでの意味は、この印 (すなわち e の印) がついている記事はすべて、From ヘッダーをもとに -4 下げられ Subject で -1 下げられるスコア項目が追加されます。これをあなたの偏見に合わせて変更して下さい。

もし 10 個の記事に同じ subject で gnus-del-mark の印がついていたとすると、この印に対する規則は十回適用されます。それはつまり、その subject は -1 の十倍のスコアを得ます。その値は、私が大きく誤解していないかぎり、-10 のはずです。

もし自動期限切れ消去 (メール) グループ (see Expiring Mail) があれば、既読記事にはすべて E 印が付けられます。これはおそらく、適応性スコア付けをちょっとばかり不可能にするので、自動期限切れ消去と適応性スコアは一緒にはうまくやっていけません。

スコアを付けられるヘッダーには from, subject, message-id, references, xref, lines, chars, date があります。さらに followup にもスコア付けできます。これは現在の記事の Message-ID を使用して References ヘッダーに合致、すなわちこれに続いたスレッドに合致する適応性スコア項目を作成します。

この機構を使うならば、ときどき記事を既読にしてしまう小さな変更を避けるために、スコアファイルの mark アトムを何か小さい値---ことによれば -300 くらいに設定しておいた方が良いです。

適応性スコアを一週間かそこら使ってくると、Gnus はそれ相応に調教され、あなたが何も言わなくても、あなたの好きな投稿者を強調し、あまり好きではない投稿者を消去するようになるはずです。

どのグループにおいて適応性スコアを作動させるかは、スコアファイル (see Score File Format) を使うことによって制御できます。またこれを使って、違ったグループに対して違った規則を使うようにもできます。

適応性スコア項目は、グループ名に gnus-adaptive-file-suffix を付加した名前のファイルに入れられます。ディフォルト値は ADAPT です。

適応性スコアファイルは巨大になり得るし、人の手で編集されることは想定されていません。gnus-adaptive-pretty-print が nil (ディフォルト) であると、それらのファイルは人に読めるような形式では書かれません。

適応性スコアを行なうときは、部分文字列一致やファジーな一致を行なった方が、おそらくほとんどの場合において良い結果が得られるでしょう。しかし、ヘッダーの一致した部分が短い場合、意図に反するような動作をする可能性が大きくなるので、gnus-score-exact-adapt-limit より短い長さしか一致しない場合は完全一致が行なわれます。この変数が nil であれば、この問題が起こらないように常に完全一致が行なわれます。

上で述べたように、個別の単語に対してもヘッダー全体に対しても適応を行なうことができます。単語に対して適応を行なった場合、 gnus-default-adaptive-word-score-alist 変数によって、各単語に対してある印へどんなスコアを与えるかを指定します。

     (setq gnus-default-adaptive-word-score-alist
           `((,gnus-read-mark . 30)
             (,gnus-catchup-mark . -10)
             (,gnus-killed-mark . -20)
             (,gnus-del-mark . -15)))

これがディフォルト値です。単語に対する適応を有効にすると gnus-read-mark の印のついた記事の表題に現れるすべての単語が、スコアに 30 点追加するというスコア規則を生み出します。

gnus-default-ignored-adaptive-words のリストに現れる単語は無視されます。無視したい単語を追加したいときは、この変数ではなく gnus-ignored-adaptive-words リストの方を使って下さい。

短い単語では適応性スコアを作動させるべきではないと思う人もいるでしょう。もしそうなら gnus-adaptive-word-length-limit に整数を設定することができ、この数値より短い単語は無視されます。この変数のディフォルト値は nil です。

スコア付けが終了したとき、gnus-adaptive-word-syntax-table の文法表がその影響を受けます。これは標準の文法表と似ていますが、単語の構成要素とならない文字の数も考慮します。

もし gnus-adaptive-word-minimum に数値が設定されていると、単語適応性スコア付け処理において、記事のスコアがこの数値よりも小さくなることはありません。ディフォルト値は nil です。

gnus-acaptive-word-no-group-words が t に設定されていると、 Gnus はグループ名のすべての語について、単語適応性スコアをしません。ほとんどの表題が emacs という語を含んでいる comp.editor.emacs のようなグループで便利です。

この機構をしばらく使ってみた後には、あなたがどんな単語が好きでどんな単語が嫌いかを、この規則を通して診断する利用者精神分析命令 gnus-psychoanalyze-user を書いてみると良いかもしれません。いや、良くないかな。

単語適応性スコア付けは非常に実験的なものであって、今後変更されるであろうということは心に留めておいて下さい。第一印象では、これは現状ではまったく使い物にならないように思えます。これをもっと使えるようにするためには、 (より厳密な統計的手法を巻き添えにして) さらなる作業が必要となるでしょう。

ホームスコアファイル
==========

新しいスコアファイル登録項目が入れられるスコアファイルは、ホームスコアファイル home score file と呼ばれます。これは通常 (ディフォルトで) そのグループ用のスコアファイルになります。例えば、gnu.emacs.gnus 用のホームスコアファイルは gnu.emacs.gnus.SCORE となるわけです。

しかしながら、これはあなたのお望みではないかもしれません。たくさんのグループ間で共通のホームスコアファイルを共有すると便利なときが多いでしょう---例えばすべての emacs グループで同じホームスコアファイルを使うこともできます。

これを制御する変数が gnus-home-score-file です。これは以下の値を取り得ます。

 1. 文字列。この場合このファイルがすべてのグループでホームスコアファイルとして使用されます。

 2. 関数。この関数の結果がホームスコアファイルとして使用されます。この関数はグループの名前を引数として呼び出されます。

 3. リスト。このリストの要素は以下の値を取り得ます。

      1. (REGEXP FILE-NAME)。REGEXP がグループ名に合致すれば、FILE-NAME がホームスコアファイルとして使用されます。

      2. 関数。この関数が nil 以外を返せば、その戻り値がホームスコアファイルとして使用されます。

      3. 文字列。この文字列をホームスコアファイルとして使用します。

     このリストの中から合致するものを、最初から後ろの方に向かって探していきます。

というわけで、単に一個のスコアファイルを使いたい場合は、以下のようにすればできます。

     (setq gnus-home-score-file
           "my-total-score-file.SCORE")

もし全 gnu グループに対して gnu.SCORE を、全 rec グループに対して rec.SCORE (等々) を使いたければ、このようにできます。

     (setq gnus-home-score-file
           'gnus-hierarchial-home-score-file)

これは便利なようにあらかじめ提供されている関数です。多の関数は以下の以下のものを含みます。

gnus-current-home-scre-file
     ``現在の'' 標準スコアファイルを返します。これはスコア命令にスコアファイルの ``最内部'' 合致への登録を加えるようにします。

もし emacs グループ用のスコアファイルと、それとは別の comp グループ用のスコアファイルを使い、他の全部のグループではそれぞれ独自のスコアファイルを使いたいのであれば、

     (setq gnus-home-score-file
           ;; 正規表現 "\\.emacs" に合致するすべてのグループ
           '(("\\.emacs" "emacs.SCORE")
             ;; すべての comp グループを単一のスコアファイルで
             ("^comp" "comp.SCORE")))

gnus-home-adapt-file は gnus-home-score-file とまったく同じように動作しますが、これは代わりに何をホーム適用スコアファイルにするかを指定します。新しい適用ファイル登録項目はすべて、この変数で指定されるファイルに入れられます。値には同じ文法が許されます。

gnus-home-score-file と gnus-home-adapt-file の使用に加えて、グループパラメーター (see Group Parameters) とトピックパラメーター (see Topic Parameters) を使ってほぼ同様のことができます。グループ、トピックパラメーターはこの変数よりも優先されます。

自分自身へのフォローアップ
=============

Gnus は現在のバッファーから Message-ID ヘッダーを見つけ出すために二つの命令を提供しています。そして Gnus は、他の記事における References ヘッダー中にこの Message-ID を使っている得点を、スコア規則として追加します。これは実質的に、その記事へ返答した記事で、現在のバッファーにあるものすべてに対してスコアを増加させます。これはあなたの言ったことに対してみんなが答えてくれたとき、すぐにそれに目を向けたいときにとても便利ですね。

gnus-score-followup-article
     これはあなた自身の記事に直接フォローアップした記事にスコアを加算します。

gnus-score-followup-thread
     これはあなたの記事より ``下'' のスレッドに現れる記事すべてに対してスコアを加算します。

これら二つの関数は、基本的にはどちらも message-sent-hook のようなフックの中で使うためのものです。例えばこのように:

     (add-hook 'message-sent-hook 'gnus-score-followup-thread)

あなたの自分の Message-ID をじっくりと眺めてみると、はじめの二、三文字は常に同じであることに気が付くでしょう。以下の二つは私のものです。

     <x6u3u47icf.fsf@eyesore.no>
     <x6sp9o7ibw.fsf@eyesore.no>

つまりこのマシン上での ``私の'' の識別は x6 であるということです。これは使えます---以下の規則は私自身へのフォローアップすべてに対してスコアを増加させるでしょう。

     ("references"
      ("<x6[0-9a-z]+\\.fsf\\(_-_\\)?@.*eyesore\\.no>"
       1000 nil r))

``あなたの'' が最初の二文字になるか最初の三文字になるかはシステムに依存します。

他のヘッダーにスコアを付ける
==============

Gnus が ``伝統的'' なヘッダー ---From, Subject など---にスコアを付けるのはとても速いです。ですが、他のヘッダーにスコアを付けるには head のスコアのための規則を書く必要があり、それは合致を探すために Gnus が毎回バックエンドから単独の記事を取り寄せなければならないことを意味します。これは大きなグループでは長い時間がかかります。

さて、ニュースグループではなくてメールグループでこれを行なうのはさほど大変ではなく、そのためのすぐれた手段が用意されています。このマニュアルの To From Newsgroups の項ではこの機構がどう働くかが詳しく説明されていますが、ここでは nnml で To と Cc ヘッダーにスコアを付ける方法の調理の例を挙げましょう。

以下を ~/.gnus.el ファイルに置いて下さい。

     (setq gnus-extra-headers '(To Cc Newsgroups Keywords)
           nnmail-extra-headers gnus-extra-headers)

Gnus を再起動して、M-x nnml-generate-nov-databases コマンドで nnml の overview ファイルを作り直します。もしあなたがたくさんのメールを持っていると、これには長い時間がかかります。

そして I e s p To RET <your name> RET のようにすると、あなたは To と Cc ヘッダーに ``extra headers'' としてスコアを付けることができます。

わかったかな? 簡単だよね。

スコア付けの奥義
========

クロスポスト
     クロスポストのスコアを低くしたければ、合致させるべき行は Xref ヘッダーです。

          ("xref" (" talk.politics.misc:" -1000))

複数のクロスポスト
     ある数、例えば三つ以上のグループにクロスポストされている記事のスコアを低くしたければ、

          ("xref"
            ("[^:\n]+:[0-9]+ +[^:\n]+:[0-9]+ +[^:\n]+:[0-9]+"
             -1000 nil r))

本文への合致
     これは一般的にはあまり良い考えではありません---それはとても長時間かかってしまうからです。実際 Gnus は、それぞれの記事を個別にサーバーから取得してこなければならないのです。でも、あなたはそれでもやりたいかもしれませんね。合致させるキーは三つ (Head, Body, All) あるのですが、スコアファイル毎に一つ選んでそれに固定した方が良いです。もし二つを使うと、それぞれの記事は 二回 取得されてしまいます。もし Head からちょっとだけ、Body からちょっとだけ合致させたい、というのであれば、素直に All を使って全部合致させて下さい。

既読の印付け
     ある一定数値以下のスコアを持つ記事には、おそらく既読の印を付けてしまいたくなるでしょう。これは all.SCORE ファイルに以下のものを入れておくことによって最も簡単に実現できます。

          ((mark -100))

     expunge を使って同様のことを考えることもできます。

否定文字クラス
     もし [^abcd]* みたいなものを指定すると、たぶん期待通りの結果は得られないでしょう。これは改行文字にも合致してしまい、えーと、未知の世界まで続くかもしれません。代わりに [^abcd\n]* を使って下さい。

逆スコア
====

もし、表題ヘッダーに Sex with Emacs という文字がある記事だけを残して、その他の記事すべてを消去してしまいたければ、スコアファイルに以下のようなものを入れることもできます。

     (("subject"
       ("Sex with Emacs" 2))
      (mark 1)
      (expunge 1))

そして Sex with Emacs に合致するすべての記事を集めて、残りを蹴飛ばすために既読の印を付け、消去します。

グローバルスコアファイル
============

間違いなく、他のニュースリーダーは ``グローバル削除ファイル (global kill file)'' を持っています。これは普通、すべてのグループに適用される、利用者のホームディレクトリーに格納されている一つの削除ファイル以上の何物でもありません。はん! ちっぽけなニュースリーダーだね。弱すぎ。

僕がここで話しているのはグローバルスコアファイルです。全世界中からの、至る所からの利用者によるスコアファイル、世界の国々をすべて、巨大な一つの幸せなスコアファイル同盟に団結させるスコアファイル !Ange-score! 新しくてテストしていない!

他の人のスコアファイルを使うためにしなければならないことは、 gnus-global-score-files 変数を設定することだけです。それぞれのスコアファイル毎に、あるいはそれぞれのスコアファイルディレクトリー毎に対して一つの項目になります。Gnus はどのスコアファイルをどのグループに使うのが適切であるかを自分で決定します。

例えば /ftp@ftp.gnus.org:/pub/larsi/ding/score/soc.motss.SCORE のスコアファイルと /ftp@ftp.some-where:/pub/score ディレクトリーにあるすべてのスコアファイルを使いたければ、

     (setq gnus-global-score-files
           '("/ftp@ftp.gnus.org:/pub/larsi/ding/score/soc.motss.SCORE"
             "/ftp@ftp.some-where:/pub/score/"))

どうだい、簡単だろう? ディレクトリー名は / で終わらなくてはなりません。これらのディレクトリーは普通は、一回の Gnus 使用期間中に一回だけしか読み込みません。もし遠隔ディレクトリーを手動で再読み込みする必要が出てきたら、gnus-score-search-global-directories 命令を使うことができます。

ただし現時点では、このオプションを使うとグループに入るのがいくらか遅くなります。(つまり---かなり、ですけど)

もしスコアファイルを、他の人たちに使ってもらうように維持したくなってきたら、単にあなたのスコアファイルを匿名 FTP に置いて、世界中に公表して下さい。逆司会者になれるよ! その後に続いて間違いなく起こる逆司会者戦争、すなわち人々の共感を勝ち取るための逆司会者の戦いに参加することで、彼らのスコアファイルに間違った前提を使わせるように誘導するのだ! やった! これでネットは救われる!

以下に、逆司会者なりたがりのための秘技をいくつか、即席で述べます。

  * 非常に多くの場所にクロスポストされている記事は間違いなく屑である。

  * 一個の不適切な記事を減点するには、Message-ID で減点する。

  * 特に素晴らしい投稿者たちは永続的な主役達として加算する。

  * そのグループの憲章無視の投稿を頻繁に繰り返す投稿者は、絶滅させてしまって差し支えない。

  * mark と expunge アトムを設定し、汚らわしい記事を完全に葬り去る。

  * 消去のスコア項目を使ってファイルの大きさを小さく抑える。でもおそらくは、サイトによって古い記事を長期間保存するように、期限切れ消去の期間は長く取るでしょうけれども。

... 果たして他のニュースリーダーは将来、グローバルスコアファイルをサポートするでしょうか? うふふ。そう、どう考えてみたって、Blue Wave や xrn や 1stReader とかいったニュースリーダーはスコアをサポートするべきだね。今は固唾を飲んで見守ることにしましょうか?

消去ファイル
======

Gnus はまだ、あのうざったい古い消去ファイルをサポートしています。実際消去ファイルの項目はもう消してもよいのですが、それは Daniel Quinlan がスコアファイルを考え出す前に私が書いたものなので、そのコードはまだ残っています。

要するに、消去処理はスコア処理よりもかなり遅いので (私の言いたいのは ものすごく)、あなたの消去ファイルはスコアファイルに書き換えた方が良いかもしれません。

いずれにせよ、消去ファイルは普通の emacs-lisp ファイルです。このファイルの中にはどんな形式でも入れることができます。つまり消去ファイルをグループに入ったときに実行する一種の原始的なフック関数のように使うことができます。まあそれがあまりいい方法ではないとしてもね。

通常の消去ファイルは以下のようになります。

     (gnus-kill "From" "Lars Ingebrigtsen")
     (gnus-kill "Subject" "ding")
     (gnus-expunge "X")

これは私が書いたすべての記事に既読の印を付け、概略バッファーから印のついた記事を削除します。とっても便利です。あなたもそう思うでしょ。

他のプログラムではまったく違う消去ファイルの構文を使っています。もし Gnus が rn の消去ファイルらしきものに出会ったら、何とかそれを解釈しようとします。

GNUS 消去ファイルを編集するための二つの概略バッファー関数があります。

M-k
     そのグループの消去ファイルを編集する (gnus-summary-edit-local-kill)。

M-K
     一般消去ファイルを編集する (gnus-summary-edit-global-kill)。

消去ファイルを編集する二つのグループモード関数があります。

M-k
     そのグループの消去ファイルを編集する (gnus-group-edit-local-kill)。

M-K
     一般消去ファイルを編集する (gnus-group-edit-global-kill)。

消去ファイル変数。

gnus-kill-file-name
     soc.motss グループ用の消去ファイルは通常 soc.motss.KILL という名前です。このファイル名を得るためにグループ名に付加される接尾辞は、gnus-kill-file-name 変数で与えられます。 ``グローバル'' 消去ファイルは (スコアファイルの意味での ``グローバル'' じゃないよ、もちろん) 単に KILL という名前です。

gnus-kill-save-kill-file
     この変数が nil 以外であれば、Gnus は処理の後に消去ファイルを保存します。これは期限切れ消去を行なう消去を使っているときに必要です。

gnus-apply-kill-hook
     グループに消去ファイルを適用するために呼び出されるフック。これはディフォルトでは (gnus-apply-kill-file) です。もし同じグループに対してスコアファイルがある場合には消去ファイルを無視したければ、このフックを (gnus-apply-kill-file-unless-scored) に設定します。消去ファイルを処理させたくなければ、この変数を nil に設定して下さい。

gnus-kill-file-mode-hook
     消去ファイルモードバッファー内で呼び出されるフック。

消去ファイルの変換
=========

あなたが古い消去ファイルをどっさり持っているのであれば、それらをスコアファイルに変換したくなるでしょう。もしそれらが ``普通の'' やつであれば、 gnus-kill-to-score.el パッケージを使うことができます。そうでなければ、手で変換しなければならないでしょう。

消去ファイルからスコアファイルへの変換パッケージは、標準では Gnus には含まれません。 http://www.stud.ifi.uio.no/~larsi/ding-various/gnus-kill-to-score.el から入手することができます。

もしあなたの消去ファイルが非常に複雑なものであれば---それに gnus-kill 形式以外のものがたくさん含まれていれば、それらを手で変換しなければなりません。あるいは単にそれらを、そのままにしておいて下さい。Gnus は以前同様にそれらを使ってくれるでしょう。

上級スコア付け
=======

表題や From ヘッダーにスコアを付けるのは十分素敵ですが、ある人特定の題に関して言っていることにだけ本当に興味がある場合はどうすれば良いのでしょう? もしくは、A さんが B さんにフォローアップしているときに言っていることを読みたくないけれど、Cさんにフォローアップしているときは何を言っているかを知りたいという場合は?

上級スコア法則を使うことで、任意の複雑なスコアの付け方を作成することができます。

上級スコア付け構文
---------

普通のスコア法則は法則の最初の要素に文字列があります。上級スコア付け法則は最初の要素にリストがあります。二番目のリストは最初の要素が nil でない値に評価されたときに適用されます。

これらのリストは三つの論理作用子からなっており、それらは一方向作用子で、色々な合致作用子です。

論理作用子:

&
and
     この論理作用子はそれぞれの引数を false に評価されるものを見つけるまで評価し、それから停止します。すべての引数が true の値に評価された場合は、この作用子は true を返します。

|
or
     この論理作用子はそれぞれの引数を true に評価されるものを見つけるまで評価します。もしどの引数も true でないと、この作用子は false を返します。

!
not
,A,
     この論理作用子は単一の引数のみをとります。それはその引数の値の論理否定を返します。

引数をスコア付けされている現在の記事の祖先に適用する 間接作用子 があります。例えば、1- は現在の記事の親にもスコア法則を適用します。 2- は現在の記事の祖父母にスコア法則を適用します。代わりに、 ^^ を書くこともでき、この時、^ (キャラット) (carat) の数はどのくらい祖先の記事までさかのぼるかを示します。

最後に、合致作用子があります。これらが本当の仕事をするものです。合致作用子はヘッダー名の文字列で、その後に合致と合致の型が続きます。典型的な合致作用子は ("form" "Lars Ingebrigtsen" s) のようなものです。ヘッダー名は単純なスコア付けをするときのものと同じで、合致の型も同じです。

上級スコア付けの例
---------

以下の例はスコアファイルの規則であることに注意して下さい。完璧なスコアファイルを作るには、別の括弧の組でそれらを囲んで下さい。

Lars さんが Gnus に関して話をしているときに、彼によって書かれた記事のスコアを増やしたいとしましょう:

     ((&
       ("from" "Lars Ingebrigtsen")
       ("subject" "Gnus"))
      1000)

ね、とても単純でしょ?

彼が長い記事を書くとき、時々何か素敵なことを言います:

     ((&
       ("from" "Lars Ingebrigtsen")
       (|
        ("subject" "Gnus")
        ("lines" 100 >)))
      1000)

しかし、彼が Reig Eigil Logge によって書かれたものに反応しているときは、彼が書いたものを読みたくありません:

     ((&
       ("from" "Lars Ingebrigtsen")
       (1- ("from" "Reig Eigir Logge")))
      -100000)

Redmondo が消えた靴下について書いたときにフォローアップしたすべての人のスコアが上げられますが、それは彼らが白い靴下について語っているときのみです。しかし、Lars が靴下について話をしているときは、たいていあまりおもしろくありません:

     ((&
       (1-
        (&
         ("from" "redmondo@.*no" r)
         ("body" "disappearing.*socks" t)))
       (! ("from" "Lars Ingebrigtsen"))
       ("body" "white.*socks"))
      1000)

大量の記事が流れているグループを読んでいて、返答にしか興味が無いとしましょう。そういう場合にやることは、"Re:"、"Fw:" または "Fwd:" で始まる表題を持っていないすべての記事のスコアを下げて、返答の印で始まる表題を持っている記事のすべての親のスコアを上げることです。

     ((! ("subject" "re:\\|fwd?:" r))
       -200)
     ((1- ("subject" "re:\\|fwd?:" r))
       200)

可能性は無限大です。

上級スコアのちょっとした秘訣
--------------

& と | 論理作用子は、短縮回路論理を行ないます。すなわち、その作用の結果が明らかになって時点で、引数を実行過程にかけることを止めます。例えば、& の引数の評価が false になると、残りの引数を評価する目的は存在しなくなります。これは遅い合致 (body や header) を最後に持ってきて、速い合致 (from や subject) を最初に持ってくるべきであるということを意味します。

間接作用子 (1- など) はそれらの引数をスレッドの一世代前に作用するようにします。次のようなことをすれば:

     ...
     (1-
      (1-
       ("from" "lars")))
     ...

これは「現在の記事の祖父母の from ヘッダーにスコアを付ける」ということを意味します。間接はとても速いですが、次の方よりも:

     (1-
      (&
       ("from" "Lars")
       ("subject" "Gnus")))

次の方が良いです:

     (&
      (1- ("from" "Lars"))
      (1- ("subject" "Gnus")))

スコア腐敗
=====

スコアは再現無く膨れ上がる傾向があることに気付くかもしれません。特に、適応スコアを使っているときは。スコアが大きくなりすぎると、それらは意味を失います---それらは単に最大を通り越してしまって、それを意味のある方法で使うことは難しくなります。

Gnus はこの問題の解決を助けるためにスコアを腐らせる機構を提供します。スコアファイルは読み込まれ、gnus-decay-scores が nil でないと、Gnus はスコアファイルを腐敗機構を通し、すべての永続でないスコア法則のスコアを下げます。もし gnus-decay-scores が正規表現だったら、それに合致するスコアファイルだけが扱われます。例えば adaptive スコアファイルだけを腐敗させるために、それを \\.ADAPT\\' に設定することができます。腐敗自身は関数 gnus-decay-score-function によって実行され、ディフォルト値は gnus-decay-score です。以下はその関数の定義です:

     (defun gnus-decay-score (score)
       "Decay SCORE according to `gnus-score-decay-constant'
     and `gnus-score-decay-scale'."
       (let ((n (- score
                   (* (if (< score 0) -1 1)
                      (min (abs score)
                           (max gnus-score-decay-constant
                                (* (abs score)
                                   gnus-score-decay-scale)))))))
         (if (and (featurep 'xemacs)
                  ;; XEmacs' floor can handle only the floating point
                  ;; number below the half of the maximum integer.
                  (> (abs n) (lsh -1 -2)))
             (string-to-number
              (car (split-string (number-to-string n) "\\.")))
           (floor n))))

gnus-score-decay-constant はディフォルト値として 3 を持ちで、 gnus-score-decay-scale はディフォルト値として 0.05 を持ちます。これは以下のようなことを引き起こします:

 1. -3 から 3 の間のスコアはこの関数が呼ばれたときに 0 に設定されます。

 2. 3 から 60 までの間の大きさのスコアは三つ減らされます。

 3. 60 より大きいスコアはスコアの 5% に減らされます。

もしこの腐敗関数を好きでないなら、自分自身の関数を書いて下さい。それは腐敗するべきスコアを唯一の引数として呼ばれ、整数であるべき新しいスコアを返さなければなりません。

Gnus は一日に一回スコアを腐敗させようとします。例えば、もし Gnus を四日間実行していないと、Gnus は四回スコアを腐らせます。

いろいろ
****

プロセス/接頭引数
=========

多くの関数、その中でも記事の移動、デコード、保存をするための関数は、プロセス/接頭引数の習慣 として知られているものを使います。

これは利用者がどの記事に命令を実行したいかを見つけるための方法です。

それはこのような感じです:

もし数値接頭引数が N であると、現在の記事から始めて、次の N 記事に作業を実行します。もし数値接頭引数が負であると、現在の記事から始めて、前の N 記事に作業を実行します。

transient-mark-mode が nil でなく、リージョンが操作されていると、リージョンにあるすべての記事に作業がなされます。

もし接頭引数が無いけれど、いくつかの記事はプロセス印が付いているという場合は、プロセス印の付いている記事に作業が実行されます。

数値接頭引数やプロセス印の付いている記事が無い場合は、現在の記事にだけ作業を実行します。

これは本当に非常に簡単ですが、驚嘆を避けられるように詳細を明らかにしておく必要があるのです。

プロセス印に反応する記事は現在のプロセス印の付いている記事のリストをスタックに積み、すべてのプロセス印の記事のリストを消去します。前回の設定を M P y で復旧させることができます (see Setting Process Marks)。

多くの人々を驚かせ、恐がらせると思われることは、例えば、3 d は本当に d d d と同じことをすることです。それぞれの d (これは現在の記事に既読の印を付けます) はディフォルトでは印を付けた後に次の未読記事に移動するので、3 d は概略バッファーがどのようであっても、次の三つの未読記事を既読にします。もっと分かりやすい動作のためには gnus-summary-goto-unread を nil に設定して下さい。

多くのコマンドはプロセス/接頭引数の習慣を使いません。ということは、このマニュアルではっきりと述べています。プロセス/接頭引数の習慣を使わないコマンドに適用するには、M-& コマンドを使いましょう。例えば、そのグループのすべての記事を期限切れ消去可能として印を付けるには M P b M-& E とします。

対話的
===

gnus-novice-user
     もしこの変数が nil でないと、あなたは Usenet の世界に新しく入って来た人であるか、非常に慎重な人で、これは本当に良いことです。何か危険なことをする前に、``本当にこれをしたいのですか?'' というような質問を受けます。これはディフォルトでは t です。

gnus-expert-user
     この変数が nil でないと、あなたは Gnus からほとんど質問を受けることはありません。これは単純にあなたがどのような変なことをしていても、何をしているかをわかっていると見なします。

gnus-interactive-catchup
     nil でないと、グループに追いつく (catchup) 前に、確認を要求します。これはディフォルトで t です。

gnus-interactive-exit
     Gnus を終了する前に確認を要求します。この変数はディフォルトで t です。

シンボルの接頭引数
=========

非常に多くの Emacs の命令は (数値) 接頭引数に反応します。例えば、 C-u 4 C-f はポイントを 4 文字先に移動し、 C-u 9 0 0 I s s p は永続 Suject 文字列の一部スコア法則の 900 を現在の記事に加えます。

これは素敵で良いのですが、命令にもう少し追加の情報を与えたいときはどうすれば良いのでしょう? えーと、たいていの命令がしていることは、``生の'' 接頭引数を特別な方法で解釈することです。例えば、C-u 0 C-x C-s は現在の記事を保存するときにバックアップファイルを作らないで欲しいということを意味します。でも、バックアップファイルを作らないで保存し、同時に Emacs に光って欲しく、素敵な音楽を演奏して欲しいときはどうすれば良いでしょう?  それは不可能で、おそらくそれが不可能であってもあなたは幸せでしょう。

私はそうではありません。ですから、私は二つめの接頭引数---シンボル接頭引数 を加えました。接頭キーは M-i (gnus-symbolic-argument) で、次に押される文字が値です。望むだけ多くの M-i 接頭語を積み重ねることができます。 M-i a C-M-u は ``C-M-u 命令にシンボル接頭引数 a を与える'' ということです。M-i a M-i b C-M-u は C-M-u 命令にシンボル接頭引数 a b を与える'' ということです。趣旨は分かったでしょう。

シンボル接頭引数を受け付けない命令にそれを打鍵することは何も悪いことをしませんが、良いことも何もしません。現在のところ、あまり多くの関数がシンボル接頭引数を役立てているわけではありません。

もしどのように Gnus がこれを実装しているかに興味があるなら、 Extended Interactive を見て下さい。

書法仕様変数
======

このマニュアルを通して、あなたはおそらく gnus-group-line-format または gnus-summary-mode-line-format のように呼ばれるたくさんの変数があることに気付いたでしょう。これらは Gnus が色々なバッファーでどのように行を出力するかを制御します。非常にたくさんのものがあります。幸運なことに、それらはすべて同じ構文を使うので、あまり嫌な目には会わないでしょう。

書法仕様 (format) 指定の例があります (グループバッファーより): %M%S%5y: %(%g%)\n。それは実際に非常に醜く、たくさんのパーセント記号がどこにでもあります。

現在のところ、Gnus は以下の書法仕様変数を使います: gnus-group-line-format, gnus-summary-line-format, gnus-server-line-format, gnus-topic-line-format, gnus-group-mode-line-format, gnus-summary-mode-line-format, gnus-article-mode-line-format, gnus-server-mode-line-format, gnus-summary-pick-line-format。

これらすべての書法仕様変数は任意の elisp 式であることもできます。その場合は、それらは要求される行に挿入するために 評価 されます。

Gnus はあなた自身の書法仕様指定を作る手伝いをする命令を備えています。 M-x gnus-update-format は現在の式を 評価 し、当の指定を更新し、結果の Lisp 式を実行して行を作成することを実験できるバッファーに移動します。

書法仕様の基本
-------

それぞれの要素 % は当のバッファーが作成されるときに何らかの文字列や他のもので置き換えられます。%5y は ``y 指定を挿入し、 5 文字の場所を得るために空白を入れなさい'' ということです。

普通の C や Emacs Lisp の書法仕様 (format) 文字列と同じように、 % と書法仕様の型の文字の間の数値修飾子は常に少なくともその長さになるように、出力に 詰め れられます。%5y はその部分を常に (少なくとも) 5 文字の長さになるように、左に空白を詰めます。もし %-5y とすれば、代わりに右側に詰め込みます。

特に長い値からその部分を保護するために、長さを制限したいとも思うでしょう。そのためには、%4,6y とすることができて、これはその領域は決して 6 文字を超える長さにはならず、4 文字より少ない長さにならないということです。

Gnus は %&user-date; のような、いくつかの拡張様式指示もサポートします。

モード行書法仕様
--------

モード行書法仕様変数 (例えば gnus-summary-mode-line-format) は以下の二つの違い以外は、バッファー行に基づく書法仕様変数と (see Formatting Basics) 同じような規則に従います:

 1. 最後に改行 (\n) があってはなりません。

 2. 特別な %%b 指定をバッファー名を表示するために使うことができます。えーと、本当はそれは指定ではないのです---%% は単に書法仕様が機械的に切り裂くのを切り抜けて % をそのまま渡すための方法で、 Emacs が %b を受け取ると、Emacs のモード行表示の部分がそれを ``バッファー名を表示しなさい'' と解釈します。Emacs が理解するモード行指定の完全な一覧を見るためには、変数 mode-line-format の説明文を見て下さい。

上級書法仕様
------

何らかの方法で領域を後で処理するのは頻繁に役に立ちます。部分を詰め込む、制限する、切り取ることと特定の値を抑制することは、チルダ修飾子 を使うことにより達成されます。よくあるチルダ指定はこのように見えるかもしれません %~(cut 3)~(ignore "0")y。

これらは有効な修飾子です:

pad
pad-left
     要求された長さになるまで、領域に空白を左側から詰め込みます。

pad-right
     要求された長さになるまで、領域に空白を右側から詰め込みます。

max
max-left
     指定された長さになるように、文字を左側から切り取ります。

max-right
     指定された長さになるように、文字を右側から切り取ります。

cut
cut-left
     指定された数の文字を左側から切り落とします。

cut-right
     指定された数の文字を右側から切り落とします。

ignore
     領域が指定された値と等しければ (equal)、空文字列を返します。

form
     @ 指定が使われたときに、指定された式を領域の値として使います。

     これは例です:

          "~(form (current-time-string))@"

例を出してみましょう。概略モード行での %o 指定は小型の ISO0861 様式の日付を返します---19960809T230410 です。これは発音しにくいので、世紀を表す数と時間を削ぎ落として、6 文字の日付を残したいと思います。それは %~(cut-left 2)~(max-right 6)~(pad 6)o となるでしょう。(切り落とし (cutting) は 最大限 (maxing) より先になされるので、桁で素敵に見えるようにするために日付が 6 文字より少なく無くならないことを保証するために詰め込み (padding) が必要になります。)

無視 (ignore) が最初になされます。それから切り落とし (cut) が行なわれます。そして、それから最後の操作、詰め込み (pad) が行なわれます。

もしあなたが、これらの上級参照をたくさん使っているなら、Gnus がとても遅くなるのがわかるでしょう。これはあなたが行の外見に満足したときに M-x gnus-compile を実行することで格段に速度低下を減らすことができます。See Compilation.

利用者定義の指定
--------

すべての指定は利用者定義---u の指定を挿入することができます。書法仕様文字列の次の文字はアルファベットである必要があります。Gnus は関数 gnus-user-format-function-X を呼び、ここで X は %u に続くアルファベットです。関数には単一の引数が与えられます---引数の意味は関数がどのバッファーから呼ばれているかによって変わります。関数は文字列を返すべきで、それは他の指定からの情報とまったく同じようにバッファーに挿入されます。関数は意味の無い値と共に呼ばれることもありえるので、それの対策をするべきです。

Gnus は %u&foo; のような拡張利用者定義指示もサポートします。 Gnus は関数 gnus-user-format-function-foo を呼び出します。

新しい関数を定義しないでも、チルダ修飾子 (see Advanced Formatting) を使ってほとんど同じことを達成することができます。例です: %~(form (count-lines (point-min) (point)))@。ここで与えられた式は評価されて、現在の行数をもたらし、それから挿入されます。

書法仕様フォント
--------

ハイライトのための指定があり、それらはすべての書法仕様変数によって共有されています。%( と %) 指定の間の文章は特別な mouse-face プロパティが設定され、それはそこにマウスのポインターをあわせたときに (gnus-mouse-face によって) ハイライトされることになります。

%{ と %} 指定の間の文章は gnus-face-0 を使って普通のフェースが設定され、それはディフォルトで bold です。もし %{1 としたなら、代わりに gnus-face-1 を得、以下同様です。欲しいだけたくさんのフェースを作って下さい。同じことが mouse-face 指定にも言えます---hello が gnus-mouse-face-3 でマウス−ハイライトされるためには、%3(hello%) とすることができます。

%<< と %>> 指示子の間のテキストは特別な balloon-help プロパティが gnus-balloon-face-0 に設定されます。%1<< とすると、gnus-balloon-face-1 を得て、他も同様です。gnus-balloon-face-* 変数は文字列か文字列を返す関数を指すシンボルのどちらかである必要があります。マウスがプロパティの設定されているテキストの上を通過すると、バルーンウィンドウが現れて、文字列を表示します。これの詳しい情報は see Tooltips (The Emacs Editor), (GNU Emacs) または balloon-help-mode (XEmacs) の説明文字列を参照して下さい。(技術的な理由のために、ギィメ (guillemets: (guillemets (仏語) はギュメとも表記されます。日本語の「」に当たるもので、口頭表現を表記したり、強調したい単語を囲む、何かからの引用部分を囲む、書物等のタイトルを記す等様々に使われます。)) はこの節では << および >> として近似されました。)

これはグループバッファーの代替手法です:

     ;; 三つのフェースの型を作ります。
     (setq gnus-face-1 'bold)
     (setq gnus-face-3 'italic)

     ;; 記事の数をボールドで緑のフェースにしたいので、
     ;; my-green-bold という新しいフェースを作りました。
     ;;
     (copy-face 'bold 'my-green-bold)
     ;; 色を設定します。
     (set-face-foreground 'my-green-bold "ForestGreen")
     (setq gnus-face-2 'my-green-bold)

     ;; 新しい上等の書法仕様を設定します。
     (setq gnus-group-line-format
           "%M%S%3{%5y%}%2[:%] %(%1{%g%}%)\n")

あなたがこの案を使って完全に読めなくて非常に下品な表示を作ることができると確信しています。楽しんで下さい!

%( 指定 (やその類のもの) はモード行変数ではまったく意味をなさないことに注意して下さい。

ポイントの移動
-------

Gnus は通常ほとんどのバッファーで、ポイントを各行のあらかじめ決められた場所に移動します。ディフォルトでは、ポイントは行の最初のコロンに移動します。あなたはこの振るまいを、三つの違う方法でカスタマイズすることができます。

また、あなたはコロンを行のどの場所にでも移動することができます。

あなたはコロンの位置にポイントを移動させるための関数を定義し直すことができます。その関数は gnus-goto-colon と呼ばれています。

でも、もしあなたが行にコロンを含めたくないならば、これを扱うためのおそらく最も手ごろな方法は %* 指示子を使うことです。あなたの行の書法仕様の定義に %* を入れておけば、Gnus はそこにポイントを置きます。

整列
--

あなたは通常は、延ばしたり縮めたりして文字列をディスプレイに並べることができます。でも大きさが違う異なる文字列を連結させる場合は、単に文字列を出力してしまうのがより手ごろであることが多いはずで、しかしそうするとその後に続くテキストを並べるのに悩むことになります。

それを行なうため、Gnus は整列子 (tabulator) の指定 %= を備えています。これには二つの形式 hard tabulators と soft tabulators があります。

%50= は文字列が 50桁から始まるように空白文字を詰め込みます。もし 50桁より後ろにすでにテキストがある場合は何も挿入しません。これは穏やか (soft) な整列子です。

%-50= もまた、文字列が 50桁から始まるように空白文字を詰め込みます。ですが、もし 50桁より後ろにすでにテキストがある場合、50桁より後ろにある過剰なテキストは削除されます。これは厳密 (hard) な整列子です。

Wide Characters
---------------

多くの地域において、固定幅フォントは同じ幅の文字を持っています。しかしいくつかの地域、よく知られている東アジアの国々では、ラテン文字と幅の広い文字が混在して使われています。

整形において、Gnus は文字列が 10個の文字の幅だとしたら、スクリーンでも 10個分のラテン文字の幅になると仮定しますが、それは問題です。かの国々では、それは正しくありません。

それを救済するために、あなたは gnus-use-correct-string-widths を t に設定することができます。これはバッファーの生成を遅くしますが、より美しい結果を得ることができるでしょう。既定値は t です。

ウィンドウの配置
========

いえ、X に関することはありませんから、おとなしくして下さい。

もし gnus-use-full-window が nil でないと、Gnus はすべての他のウィンドウを消して、Emacs の画面全体を占有します。これはディフォルトで t です。

この変数を nil に設定するのはそれなりに動作しますが、問題もあります。危険を覚悟の上で使って下さい。

gnus-buffer-configuration はそれぞれの Gnus のバッファーがどのくらいの空間を与えられるべきかを現します。これはこの変数の抜粋です:

     ((group (vertical 1.0 (group 1.0 point)
                           (if gnus-carpal (group-carpal 4))))
      (article (vertical 1.0 (summary 0.25 point)
                             (article 1.0))))

これは連想リストです。キー は何らかの動作や他のものを任命するシンボルです。例えば、グループバッファーを表示するときは、ウィンドウ設定関数は group をキーとして使います。使用可能な名前の完全な一覧は下に挙げられています。

値 (すなわち、分割) はそれぞれのバッファーがどれくらいを占めるべきかを指定します。article 分割を例に取ると -

     (article (vertical 1.0 (summary 0.25 point)
                            (article 1.0)))

この 分割 は概略バッファー (summary buffer) が画面の上の 25% を占めるべきで、それは記事バッファー (article buffer) の上に配置されます。お気づきの通り、100% + 25% は実際は 125% です (えぇ、皆さんの計算はこの様になったと思います。) しかし、特別な数値 1.0 は、残りのバッファーが必要なものを取り去った後に、使用可能な残りの空間すべてを吸い取る、ということを合図するために使われます。一つの分割につき、1.0 の大きさ指定のバッファーは一つだけでなくてはなりません。

ポイントは省略可能な三つ目の要素、point を持つバッファーに置かれます。frame 分割では、タグ frame-focus が構成要素である (すなわち、point タグが存在するかどうかによって、リストの三番目か四番目かに存在する要素) 葉分割を持つ最後の副分割が焦点を得ることになります。

次はもっと複雑な例です:

     (article (vertical 1.0 (group 4)
                            (summary 0.25 point)
                            (if gnus-carpal (summary-carpal 4))
                            (article 1.0)))

もし大きさ指定が浮動小数点数の代わりに整数であったなら、それは割合ではなく、どのくらい多くの行をバッファーが占めるべきかを指定するために使われます。

もし 分割 が 評価 されるもののように見えるときは (明確にすると---分割の car が関数か原始関数 (subr) であるときは)、この分割は 評価 されます。結果が nil でないなら、それは分割として用いられます。これは、gnus-carpal が nil であれば三つのバッファーが、gnus-carpal が nil でないなら、四つのバッファーが存在するということです。

まだ複雑ではないですって? それでは、大きさにこれを試してみて下さい:

     (article (horizontal 1.0
                  (vertical 0.5
                      (group 1.0)
                      (gnus-carpal 4))
                  (vertical 1.0
                      (summary 0.25 point)
                      (summary-carpal 4)
                      (article 1.0))))

おぉっと。二つのバッファーに不思議な 100% タグが付いています。そして、あの horizontal っていうものは何でしょう?

もし分割の一つの最初の要素が horizontal であったなら、Gnus はウィンドウを水平に分割し、二つのウィンドウを横に並べます。これらのそれぞれの小片の中では、すべてを普通の流儀で行なうことができます。 horizontal の後の数値は、この小片に画面のどれくらいの割合が与えられるかを指定します。

それぞれの分割では、100% のタグを持つ要素が 必ず 一つある必要があります。分割は決して正確には行なわれないので、このバッファーが分割から残されたすべての行を占領します。

もう少し正式にするために、ここに有効な分割がどのようになるかの定義があります:

     split      = frame | horizontal | vertical | buffer | form
     frame      = "(frame " size *split ")"
     horizontal = "(horizontal " size *split ")"
     vertical   = "(vertical " size *split ")"
     buffer     = "(" buf-name " " size *[ "point" ] *[ "frame-focus"] ")"
     size       = number | frame-params
     buf-name   = group | article | summary ...

制限には、frame は最上位の分割としてしか現れることができないというものがあります。FORM は有効な分割を返す Emacs Lisp の式 (form) でなければなりません。それぞれの分割は完全に再帰的で、任意の数の vertical と horizontal 分割を含むことができます。

正しい大きさを見つけるのは少し複雑です。どのウィンドウも gnus-window-min-height (ディフォルト値 1) の文字の高さよりも小さくてはならず、少なくとも gnus-window-min-width (ディフォルト値 1) の文字幅でなくてはなりません。Gnus は分割を適用する前にこれを強制しようと試みます。もし普通の Emacs のウィンドウの幅/高さ制限を使いたいなら、この二つの変数を nil にするだけで良いです。

もし Emacs の用語になじんでいないのなら、 horizontal と vertical 分割は、期待するものと反対の動作をするでしょう。horizontal 分割の中のウィンドウは横に並んで表示され、 vertical 分割の中のウィンドウは上下に表示されます。

ウィンドウの設置に関して実験をしてみたいのであれば、よい方法は分割で直接 gnus-configure-frame を呼ぶことです。これはバッファーを分割するときにすべての本当の仕事をする関数です。下のものは 5 ウィンドウのとてもばかげた設定です。二つをグループバッファーに、三つを記事バッファーのために充てます。(それはばかげていると言ったでしょ。) もし下の文を 評価 すると、普通の Gnus の経路を使わないで、すぐにそれがどのように見えるかの考えを得ることができます。満足するまでそれで遊んで、それから gnus-add-configuration を使って新しい想像をバッファー設定リストに加えて下さい。

     (gnus-configure-frame
      '(horizontal 1.0
         (vertical 10
           (group 1.0)
           (article 0.3 point))
         (vertical 1.0
           (article 1.0)
           (horizontal 4
             (group 1.0)
             (article 10)))))

いくつかのフレームも欲しいかもしれません。簡単です---frame 分割を使うだけです:

     (gnus-configure-frame
      '(frame 1.0
              (vertical 1.0
                        (summary 0.25 point frame-focus)
                        (article 1.0))
              (vertical ((height . 5) (width . 15)
                         (user-position . t)
                         (left . -1) (top . 1))
                        (picon 1.0))))

この分割の結果は、最初 (もしくは、``主な'') フレームは見慣れた概略/記事ウィンドウ設定で、小さな追加のフレームが picon を表示するために作られるということになります。ご覧の通り、普通の 1.0 最上位指定の代わりに、それぞれの追加の分割がフレームパラメーター連想リストを大きさ指定として持たなければなりません (see Frame Parameters (The GNU Emacs Lisp Reference Manual))。XEmacs では、フレームプロパティリストも使えます---例えば、(height 5 width 15 left -1 top 1) はそのようなパラメーターリストです。gnus-buffer-configuration に使用可能なすべてのキーの一覧はそのディフォルト値で見つけることができます。

キー message は gnus-group-mail および gnus-summary-mail-other-window の両方で使われることに注意して下さい。もし二つを区別するほうが望ましいなら、このような物を使うことができます:

     (message (horizontal 1.0
                          (vertical 1.0 (message 1.0 point))
                          (vertical 0.24
                                    (if (buffer-live-p gnus-summary-buffer)
                                        '(summary 0.5))
                                    (group 1.0))))

複数のフレームへの良くある要望は、メールとニュースの作成には別のフレームを使い、元のフレームはそのままに残すというものです。これの達成には、以下のようなものでできます。

     (message
       (frame 1.0
              (if (not (buffer-live-p gnus-summary-buffer))
                  (car (cdr (assoc 'group gnus-buffer-configuration)))
                (car (cdr (assoc 'summary gnus-buffer-configuration))))
              (vertical ((user-position . t) (top . 1) (left . 1)
                         (name . "Message"))
                        (message 1.0 point))))

変数 gnus-buffer-configuration はとても長く複雑なので、単一の設定の変更を簡単にするための関数があります: gnus-add-configuration です。もし、例えば、article の設定を変えたいのなら、次のようにできます:

     (gnus-add-configuration
      '(article (vertical 1.0
                    (group 4)
                    (summary .25 point)
                    (article 1.0))))

普通はこれらの gnus-add-configuration 呼び出しを ~/.gnus.el ファイルに入れるか、何らかの起動時のフックに入れるでしょう---それらは Gnus が読み込まれた後に実行されるべきです。

もし設定で言及されたすべてのウィンドウがすでに見えているのであれば、 Gnus はウィンドウの設定を変更しません。もし常に ``正しい'' ウィンドウ設定を強制したいのであれば、 gnus-always-force-window-configuration を nil でない値に設定することができます。

木表示を使っていて (see Tree Display)、木ウィンドウは垂直方向に別のウィンドウで表示されるなら、ウィンドウの大きさが変更されることを避けるために gnus-tree-minimize-window をいじるのが良いでしょう。

ウィンドウ設定の例
---------

  * 左側を狭めてグループバッファーに。右側を分割して概略バッファー (上 1/6) と記事バッファー (下) に。

          +---+---------+
          | G | Summary |
          | r +---------+
          | o |         |
          | u | Article |
          | p |         |
          +---+---------+

          (gnus-add-configuration
           '(article
             (horizontal 1.0
                         (vertical 25 (group 1.0))
                         (vertical 1.0
                                   (summary 0.16 point)
                                   (article 1.0)))))

          (gnus-add-configuration
           '(summary
             (horizontal 1.0
                         (vertical 25 (group 1.0))
                         (vertical 1.0 (summary 1.0 point)))))

フェースとフォント
=========

フォントとフェースを弄るのは非常に難しかったのですが、今日では非常に簡単です。単に M-x customize-face とやって、変えたいフェースを選び出して、標準のカスタマイズインターフェースを使って変更することができます。

コンパイル
=====

あの行書法仕様指定変数を覚えていますか? gnus-summary-line-format, gnus-group-line-format などなどです。さて、Gnus はこれらの変数が何であっても注意を払いますが、不運なことにそれらを変更すると大変重大な速度低下を引き起こすことになります。 (これらの変数のディフォルト値はそれらに関連付けられたバイトコンパイルされた関数を持っていますが、利用者作成のものはもちろんそうではありません。)

これを改善するために、変数をいじくりまわして、(なんとなく) 満足したと感じた後で、M-x gnus-compile を実行することができます。これは新しい指定がバイトコンパイルされ、もう一度最高速度に復帰できるということです。 Gnus はこれらのバイトコンパイルされた指定を .newsrc.eld ファイルに保存します。(もっとも利用者が定義した関数は、この関数によってコンパイルされません---それらを ~/.gnus.el ファイルに突っ込んでから、自分で ~/.gnus.el ファイルをバイトコンパイルしなければなりません。)

モード行
====

gnus-updated-mode-lines はどのバッファーがそのモード行を常に最新のものにしておくかを指定します。それはシンボルのリストです。使うことのできるシンボルは group, article, summary, server, browse, tree などです。もし対応するシンボルが存在すると、Gnus は該当するであろう情報でモード行を更新します。この変数が nil であるなら、画面の再描画はもっと速いでしょう。

ディフォルトでは、Gnus は概略バッファーと記事バッファーのモード行に現在の記事の情報を表示します。Gnus が表示したい情報 (例えば、記事の表題) はしばしばモード行よりも長いことがあるので、どこかで切り落とされなければなりません。変数 gnus-mode-non-string-length はその行の他の要素 (すなわち、情報でない部分) がどのくらいの長さであるかを指定します。もしモード行に追加の要素を入れたなら、この変数を修正する必要があります:

     (add-hook 'display-time-hook
               (lambda () (setq gnus-mode-non-string-length
                                (+ 21
                                   (if line-number-mode 5 0)
                                   (if column-number-mode 4 0)
                                   (length display-time-string)))))

もしこの変数が nil であるなら (これがディフォルト値ですが)、モード行は切り落とされず、詰め込みもされません。ディフォルトでは、バッファーの完全なパーセント表示さえもモード行から追いやられる可能性もあるので、おそらく望ましい設定ではないということに注意して下さい。利用者が自分の設定に合うようにこの変数を適切に設定しなければなりません。

ハイライトとメニュー
==========

変数 gnus-visual はたいていの Gnus を素敵にする部分の操作をします。 nil であると、Gnus はメニューを作ったり、素敵な色やフォントを使ったりしようとしません。これは gnus-vis.el ファイルを読み込むことも禁止します。

この変数は使用可能な視覚的プロパティのリストであることができます。以下の要素は有効で、ディフォルトですべて含まれています:

group-highlight
     グループバッファーでハイライトをします。

summary-highlight
     概略バッファーでハイライトをします。

article-highlight
     記事バッファーでハイライトをします。

highlight
     すべてのバッファーでハイライトをするようにします。

group-menu
     グループバッファーでメニューを作成します。

summary-menu
     概略バッファーでメニューを作成します。

article-menu
     記事バッファーでメニューを作成します。

browse-menu
     ブラウズバッファーでメニューを作成します。

server-menu
     サーバーバッファーでメニューを作成します。

score-menu
     スコアバッファーでメニューを作成します。

menu
     すべてのバッファーでメニューを作成します。

ですから、記事バッファーだけをハイライトしたく、すべてのバッファーでメニューを作りたい場合は、このようにすることができます:

     (setq gnus-visual '(article-highlight menu))

もしハイライトだけで、メニューの類は欲しくないときは、次のようにできます:

     (setq gnus-visual '(highlight))

gnus-visual が t であると、ハイライトとメニューはすべての Gnus のバッファーで使用されます。

他のすべてのバッファーの外見に影響する総合的な変数は:

gnus-mouse-face
     これは Gnus でマウスのハイライトに使われるフェース (すなわち、フォント) です。gnus-visual が nil であると、マウスハイライトはなされません。

まったく違ったメニューを作成するために関連するフックがあります:

gnus-article-menu-hook
     記事モード (article mode) メニューを作成した後に呼ばれるフックです。

gnus-group-menu-hook
     グループモード (group mode) メニューを作成した後に呼ばれるフックです。

gnus-summary-menu-hook
     概略モード (summary mode) メニューを作成した後に呼ばれるフックです。

gnus-server-menu-hook
     サーバーモード (server mode) メニューを作成した後に呼ばれるフックです。

gnus-browse-menu-hook
     概観モード (browse mode) メニューを作成した後に呼ばれるフックです。

gnus-score-menu-hook
     スコアモード (score mode) メニューを作成した後に呼ばれるフックです。

ボタン
===

最近では、最新流行のマウス mouse 装置が、ちゃんとした操作法を学びたがらないナウなヤングの間で大人気です。それでは、私が Tops 20 システム上で Emacs を使っていた頃の '89 年の夏を思い起こしてみましょう。300 人の利用者が、一つのマシン上で、みんなが Simula コンパイラを走らせていました。ああ、ばかばかしい!

ほんとにそうだね。

まずですね、gnus-carpal を t に設定することによって、クリックするだけで何でもできるボタンだらけのバッファーを Gnus に表示させることができます。とっても簡単です、ほんとに。指圧療法の先生に教えてあげて。 (訳注: carpal とは手首の骨のこと)

gnus-carpal-mode-hook
     すべての手首モードバッファーで実行するフック。

gnus-carpal-button-face
     ボタンに使われるフェース。

gnus-carpal-header-face
     手首バッファーのヘッダーで使用されるフェース。

gnus-carpal-group-buffer-buttons
     グループバッファーのボタン。

gnus-carpal-summary-buffer-buttons
     概略バッファーのボタン。

gnus-carpal-server-buffer-buttons
     サーバーバッファーのボタン。

gnus-carpal-browse-buffer-buttons
     閲覧バッファーのボタン。

すべての buttons 変数はリストです。このリストの要素は、 car が表示される文で cdr が関数シンボルの cons セルか、もしくはただの文字列のどちらかです。

デーモン
====

Gnus、それは (言い伝えによれば) かつて書かれたいかなるプログラムよりも大きく、あなたがやって欲しいと思うさまざまな奇妙なことを、あなたのいないところで行なってくれるものです。例えば、あなたは時たま新着メールをチェックしてもらいたいかもしれません。あるいは Emacs をしばらく放っておいたときすべてのサーバーの接続を切断してもらいたくなるかもしれません。他にも何かそういったことです。

Gnus はさまざまな制御子 handlers を定義することによってそのようなことを可能にします。各制御子は三つの要素から成ります。関数, 時間, 空転 パラメーターです。

以下は Emacs が何もしない空転状態が三十分続いたときに接続を切断する制御子の例です。

     (gnus-demon-close-connections nil 30)

以下は Emacs が何もしていないとき、一時間毎に PGP ヘッダーを走査する制御子です。

     (gnus-demon-scan-pgp 60 t)

この 時間 パラメーターとそして 空転 パラメーターは、奇妙でかつ素晴らしい方法で一緒に動作します。基本的には、空転 が nil の時にはこの関数は 時間 分毎に呼び出されます。

もし 空転 が t であれば、この関数は Emacs が何もしていない時に限り、時間 分後に呼び出されます。いったん Emacs がずっと空転状態になった後は、この関数は 時間 分毎に呼び出されます。

空転 が数で 時間 も数である場合、この関数は、Emacs の空転状態が 空転 分続いた時に限り、時間 分毎に呼び出されます。

空転 が数で 時間 が nil の場合、この関数は、Emacs の空転状態が 空転 分続く度に一度呼び出されます。

そして 時間 が文字列の場合は、07:31 のような形式でなければならず、この関数は毎日その頃の時間になると一度呼び出されます。もちろん、空転 パラメーターで動作が変わります。

(ここで ``分'' と言ったとき、それは実際には gnus-demon-timestep 秒のことです。これはディフォルトでは 60 です。もしこの変数を変更すると、すべての制御子の計時に影響を与えます。)

というわけで、制御子を追加したければ、~/.gnus.el ファイルに、以下のようなものを書くことができます。

     (gnus-demon-add-handler 'gnus-demon-close-connections 30 t)

このための既製関数がいくつか作成されています。gnus-demon-add-nocem, gnus-demon-add-disconnection, gnus-demon-add-nntp-close-connection, gnus-demon-add-scan-timestamps, gnus-demon-add-rescan, gnus-demon-add-scanmail です。これらの能力が欲しければ、単にこれらの関数を ~/.gnus.el に入れて下さい。

もし gnus-demon-handlers で制御子を直接追加した場合には、それを効かせるために gnus-demon-init を実行して下さい。すべてのデーモンを取り消すには、gnus-demon-cancel 関数を使うことができます。

デーモンの追加は、やりすぎるのはとってもお行儀のよくないことです。すべてのサーバーからすべてのニュースとメールを二秒毎に調べまわす関数を付け加えちゃったりすると、どんな立派なシステムでも間違いなくお払い箱にしてしまいます。そう動くんだもん。

NoCeM
=====

Spam とは、同じ記事を何回も何回も何回も投稿することです。Spam は悪いことです。Spam は凶悪です。

Spam は通常一日かそこらで、さまざまな反 spam 機関から取り消しされます。これらの機関は通常一緒に、NoCeM メッセージも送信します。 NoCeM は ``no see-'em'' (彼らを見たくない) と発音され、意味はその名前の通りです---このメッセージは、罪を犯している記事を、つまり、消してしまいます。

どうせその記事が取り消しされてしまうのなら、これら NoCeM メッセージは何に使われるのでしょう? あるサイトでは取り消しメッセージを引き受けず、あるサイトでは特定の数人からの取り消しメッセージのみしか引き受けません。それで、あなたは NoCeM メッセージを使いたくなるかもしれないわけです。これらは alt.nocem.misc ニュースグループで配布されています。

Gnus はこのグループのメッセージを自動的に読み、解釈することができ、これで spam を消し去ります。

もちろん、これらをカスタマイズするための変数がいくつかあります。

gnus-use-nocem
     この変数を t に設定することで活動を開始させます。ディフォルトでは nil です。

gnus-nocem-groups
     Gnus はこのグループリストから NoCeM メッセージを探します。ディフォルト値は ("news.lists.filters" "news.admin.net-abuse.bulletins" "alt.nocem.misc" "news.admin.net-abuse.announce") です。

gnus-nocem-issuers
     NoCeM メッセージを発行する人はたくさんいます。このリストでは、誰のいうことに従いたいかを指定します。ディフォルト値は (("Automoose-1" "clewis@ferret.ocunix.on.ca" "cosmo.roadkill" "SpamHippo" "hweede@snafu.de") です。彼らはみんな、立派で高潔な市民です。

     このリストに含められる有名な反 spam 家たちは http://www.xs4all.nl/~rosalind/nocemreg/nocemreg.html に載っています。

     これらすべての人々の NoCeM メッセージに留意する必要はありません---いうことを聞きたい人だけでいいんです。またその人からの NoCeMメッセージすべてを受け入れる必要もありません。NoCeM メッセージにはそれぞれ種別 type ヘッダーがついており、これはそのメッセージの厳密な定義を与えています (多少は厳密な、程度ね。たいていは少だけど)。良く使われる種別には、spam, spew, mmf, binary, troll があります。これを指定するには、リストの中で (発行者 条件...) 要素を使う必要があります。各条件は文字列 (使いたい種別に合致する正規表現) か、または (not 文字列) という形式のリストです。この場合は 文字列 は使いたくない種別に合致する正規表現です。

     例えば、Chris Lewis からの NoCeM メッセージで、troll メッセージ以外のすべてを欲しい場合には、

          ("clewis@ferret.ocunix.on.ca" ".*" (not "troll"))

     一方、彼の spam と spew メッセージ以外は何もしたくなければ、以下のようにできます。

          ("clewis@ferret.ocunix.on.ca" (not ".*") "spew" "spam")

     この指定は左から右に適用されます。

gnus-nocem-verifyer
     これは NoCeM 発行者が本人であることを検証する関数でなくてはなりません。ディフォルト値は pgg-verify で、これは検証に成功したら非-nil を返し、そうでなければ (NoCeM メッセージが署名されていない場合を含みます) nil を返します。もしこれが非常に遅くて、検証結果を気にしない (これはたぶん危険です) のであれば、この変数を nil にすることができます。

     以前、ディフォルトは Mailcrypt の関数である mc-verify でした。まだそれを使うことができますが、PGP の公開鍵を GnuPG の鍵束に加えることを厭わなければ、GnuPG とともに動作するディフォルトの関数に変えることができます。

gnus-nocem-directory
     これは Gnus が NoCeM キャッシュファイルを保存する場所です。ディフォルト値は ~/News/NoCeM/ です。

gnus-nocem-expiry-wait
     古い NoCeM 項目をキャッシュから消すまでの日数。ディフォルト値は 15 です。これを短くするほど Gnus は速くなりますが、古い spam を見ることになってしまうかもしれません。

gnus-nocem-check-from
     非-nil では、記事のボディーにある発行人の正当性を調べます。そうでない場合は、著者が正しい発行人でなくても気にせずに記事を取り込みますが、もしあなたが正しい発行人を見分けられるならば、そうした方がとても速くなるでしょう。

gnus-nocem-check-article-limit
     非-nil で、すべての NoCeM グループにおけるチェックする記事の最大数を指定します。NoCeM グループは巨大になることがあり、そうなると処理がとても遅くなります。

NoCeM を使うと、もしかするとメモリ喰いになるかもしれません。あなたがたくさんの生きたグループ (つまり購読あるいは非購読グループ) を持っているのなら、Emacs プロセスは大きくなってしまうでしょう。もしこれが問題であれば、非購読のグループを全部 (あるいはその多くを) 消し去ってしまった方が良いです (see Subscription Commands)。

やり直し
====

実行したことのやり直しができると、とても便利です。普通の Emacs バッファーでは、これは十分簡単です---単に undo ボタンを押すだけです。しかし Gnus のバッファーでは、これは簡単ではありません。

Gnus がバッファー内に表示しているものは、Gnus にとってはまったく何の価値もありません---これはみんな、利用者に奇麗に見えるようにデザインされているただのデータなのです。C-k でグループバッファーからグループを消去するのは、その行は消え去りますが、それは実際の動作---問題のグループを Gnus の内部構造体から削除すること、の単なる副作用でしかありません。これらのやり直しは、通常の Emacs の undo 関数では行なうことができません。

Gnus は、利用者が何をするかを憶えておき、その利用者の動作の逆を行なう動作を提供することによって、これを何とか救済しようとします。そして利用者が undo キーを押したとき、Gnus はその一つ手前の動作あるいは動作群の逆のコードを実行します。しかし、すべての動作が簡単に可逆であるわけではないので、Gnus は現在、やり直し可能なキー関数は僅かしか提供していません。これらは、グループの削除、グループの貼り付け、グループの既読記事のリストの変更、それだけなんです。将来はもっと関数が追加されるかもしれませんが、関数の追加はそれぞれ保存するべきデータを増やすことになるので、Gnus は決して完全やり直し可能にはならないでしょう。

やり直し機能は gnus-undo-mode マイナーモードによって提供されます。これは gnus-use-undo が nil 以外であれば使用され、これがディフォルトです。C-M-_ キーが gnus-undo 命令を実行します。これは通常の Emacs の undo 命令にいくぶん似ているはずです。

述語の設定
=====

いくつかの Gnus の変数は 述語指示子 (predicate specifiers) です。これは述語の仕様に融通を効かせることができる特別な形式です。

これらの指示子は関数によるリスト、シンボルまたはリストです。

これは例です:

     (or gnus-article-unseen-p
         gnus-article-unread-p)

利用できるシンボルは or、and および not です。関数はすべて一つのパラメーターを受け取ります。

内部的に、Gnus は呼ぶことができる関数を作るために、これらの指示子について gnus-make-predicate を使います。この関数へのこの入力パラメーターは、述語指示子のすべての関数に渡されます。

司会役
===

もしあなたが司会者 (モデレーター) ならば、gnus-mdrtn.el パッケージを使うことができます。これは標準 Gnus パッケージには含まれません。 larsi@gnus.org に、どのグループの司会を行なうのかを述べたメールを書いて下さい。そうすればコピーを手に入れられます。

司会者用パッケージは概略バッファーのマイナーモードとして実装されています。

     (add-hook 'gnus-summary-mode-hook 'gnus-moderate)

をあなたの ~/.gnus.el ファイルに入れて下さい。

あなたが rec.zoofle の司会者だとすると、これは以下のように動作するようになっています。

 1. Newsgroups:.*rec.zoofle に合致する受信メールを分離します。これは投稿されようとしている記事をすべてあるメールグループ---例えば nnml:rec.zoofle に入れます。

 2. あなたは時折このグループに入り、e (edit-and-post) あるいは s (just send unedited) 命令を使って記事を投稿します。

 3. rec.zoofle ニュースグループを読んでいる途中で、もしあなたが承認していない記事をたまたま見つけたとしたら、c 命令で取り消しできます。

二つのグループで司会者モードを使うとすれば、こうなります。

     (setq gnus-moderated-list
           "^nnml:rec.zoofle$\\|^rec.zoofle$")

グループを取得する
=========

時々、“このグループを読みたいのであって、Gnus が起動しているかどうかを気にしたくない。”ということができれば便利なことがあります。これは、利用者よりもプログラムのコードを書く人に便利な機能ですが、どちらにしろ、 gnus-fetch-group コマンドはこの機能を提供します。そのコマンドは、グループの名前を引数としてとります。

画像の拡張
=====

XEmacs それに Emacs 21 (MS ウィンドウズの Emacs 21 はまだ画像をサポートしていません。) は絵やその他のものを表示することができるので、 Gnus はこれを利用することにします。

X-Face
------

X-Face ヘッダーは、メッセージの著者を表わすことになっている 48× 48 画素の白黒 (1 bit の深さ) の絵を描きます。これは進化し続けるあまたのメールとニュースリーダーによってサポートされるでしょう。

X-Face ヘッダーのデコードには、Emacs が compface をサポート (XEmacs のほとんどがサポート) しているか、あなたのシステムに compface がインストールされている必要があります。もしどちらかが真ならば、Gnus はディフォルトで X-Face ヘッダーを表示します。

これを制御するのは変数 gnus-article-x-face-command です。この変数が文字列ならば、この文字列がサブシェルで実行されます。関数ならば、この関数が顔を引数として呼ばれます。もし gnus-article-x-face-too-ugly (これは正規表現です) が From 欄に合致すれば、顔は表示されません。

Emacs 20 でのディフォルトの動作は display プログラム  (display は ImageMagick パッケージに含まれています。 uncompface と icontopbm の両プログラムについては、 `compface' や GNU/Linux システムにおける `faces-xface' のようなパッケージを探して下さい。) をフォークして見ようとします。

XEmacs か静止画をサポートしている Emacs 21+ でのディフォルトの動作は From 欄の前に顔を表示することです。(XEmacs が X-Face 機能付きでコンパイルされていると良いでしょう---それは表示を少し早くします。もし根本的 X-Face 機能がないのであれば、Gnus は pbmplus やその仲間の外部プログラムを使って X-Face 欄を変換しようと試みます  (GNU/Linux システムでは netpbm、libgr-progs または compface のような名前のパッケージを探して下さい。)。)

(注: 変数/関数名には xface ではなく x-face が使われます。)

フェースと変数:

gnus-x-face
     X-Face を表示するためのフェース。このフェースの色が表示される X-Face の前景色と背景色として使われます。ディフォルトの色は白と黒です。

gnus-face-properties-alist
     Face (see Face) と X-Face 画像に適用される、画像の形式とプロパティの連想リストです。ディフォルト値は Emacs 用の ((pbm . (:face gnus-x-face)) (png . nil)) または XEmacs 用の ((xface . (:face gnus-x-face))) です。例を挙げましょう:

          ;; From ヘッダーにおける Face と X-Face の高さを指定します。
          (setq gnus-face-properties-alist
                '((pbm . (:face gnus-x-face :ascent 80))
                  (png . (:ascent 80))))

          ;; Face と X-Face を凹んだボタンのように表示します。
          (setq gnus-face-properties-alist
                '((pbm . (:face gnus-x-face :relief -2))
                  (png . (:relief -2))))

     いろいろな画像の形式で利用可能なプロパティについては see Image Descriptors (The GNU Emacs Lisp Reference Manual), を参照して下さい。今のところ Emacs では pbm が X-Face 画像に使われ、 png が Face 画像に使われます。XEmacs では、それが libcompface ライブラリとともに構築されていれば、xface 画像形式に :face プロパティだけが効果を及ぼします。

Gnus は、外に出すメッセージに X-Face ヘッダーを簡単に挿入するための、便利な関数と変数を少しばかり提供します。

gnus-random-x-face は gnus-x-face-directory にあるすべての pbm をくまなく探してランダムに一つを選び取り、シェルコマンド gnus-convert-pbm-to-x-face-command を使ってそれを X-Face の形式に変換します。pbm ファイルは 48×48 画素の大きさでなければなりません。それは X-Face ヘッダーのデータを文字列で返します。

gnus-insert-random-x-face-header は gnus-random-x-face を呼んで、ランダムに生成されたデータによる X-Face ヘッダーを挿入します。

gnus-x-face-from-file はパラメーターとして GIF ファイルを受け取り、シェルコマンド gnus-convert-image-to-x-face-command を使ってそのファイルを X-Face の形式に変換します。

一番目は一般的に使うであろう関数です。以下のようなものを ~/.gnus.el ファイルに書いて下さい:

     (setq message-required-news-headers
           (nconc message-required-news-headers
                  (list '(X-Face . gnus-random-x-face))))

最後の関数を使うのは、このようになるでしょう:

     (setq message-required-news-headers
           (nconc message-required-news-headers
                  (list '(X-Face . (lambda ()
                                     (gnus-x-face-from-file
                                      "~/My-face.gif"))))))

Face
----

Face ヘッダーは、本質的によりファンキーな X-Face の変形です。それらは、メッセージを書いた人を象徴していることが期待される、 48×48 画素のカラー画像を描きます。

Face ヘッダーの内容は、base64 でエンコードされた PNG の画像でなければなりません。正確な仕様について、 http://quimby.gnus.org/circus/face/ を参照して下さい。

変数 gnus-face-properties-alist は表示される Face 画像の外観に影響します。See X-Face.

送信するメッセージに簡単に Face ヘッダーを挿入できるようにするために、 Gnus は 2〜3 の関数と変数を提供します。

gnus-convert-png-to-face は 726-byte 以下の 48×48 の PNG の画像を読み込んで、それを Face に変換します。

gnus-face-from-file は JPEG のファイル名をパラメーターとして受け取り、シェルコマンド gnus-convert-image-to-face-command を使ってそのファイルを Face フォーマットに変換します。

この関数の代表的な使い方を挙げておきましょう。以下のようなものを ~/.gnus.el ファイルに入れて下さい:

     (setq message-required-news-headers
           (nconc message-required-news-headers
                  (list '(Face . (lambda ()
                                   (gnus-face-from-file "~/face.jpg"))))))

スマイリー
-----

スマイリー smiley は Gnus とは別のパッケージですが、スマイリーを使っているパッケージは現在 Gnus だけなので、ここで説明します。

ひとことで言えば---Gnus でスマイリーを使うには、以下を ~/.gnus.el ファイルに書いて下さい。

     (setq gnus-treat-display-smileys t)

スマイリーは、文字の顔マーク---:-), 8-), :-( などといったもの---を絵に対応させ、文字の顔マークの代わりにその絵を表示します。この変換は文字に合致する正規表現とそれのファイル名への対応のリストで制御されます。

使われる連想リストは、変数 smiley-regexp-alist で設定します。各要素の最初の項目は合致させたい正規表現で、二番目の要素は絵で置き換えたいグループに合致する正規表現、そして三番目の要素は表示させたいファイルの名前です。

以下の変数は、スマイリーがこれらのファイルを探す場所をカスタマイズします:

smiley-data-directory
     スマイリーが顔ファイルを探す場所。

gnus-smiley-file-types
     スマイリーのファイル名として試してみる拡張子のリストです。

Picons
------

それで…、あなたはこのニュースリーダーをさらにもっと遅くしたいってわけだね! これはそうするのにぴったりな方法です。さらにこれは、あなたがニュースを読んでいるんだということを、あなたの肩越しに見つめている人に印象づけるための素晴らしい方法でもあります。

Picon とはなんでしょう? Picons ウェブサイトから直接引用しましょう。

     Picon とは、``個人アイコン (personal icons)'' の略です。これは、ネット上の利用者やドメインを表現するのに使われるための小さな画像で、データベースを持たせて、ある電子メールアドレスがあったら、それに適切な画像を見つけられるようにしておくものです。利用者とドメイン以外にも、Usenet ニュースグループや天気予報のためのpicon データベースがあります。picon は白黒の XBM 形式でもカラーの XPM 形式でも GIF 形式でも構いません。

Picon データベースの入手とインストールの手順については、ウェブブラウザーで http://www.cs.indiana.edu/picons/ftp/index.html を訪ねてみて下さい。

もし Debian GNU/Linux を使っているのなら、apt-get install picons.* と言えば Gnus が見つけることができる picon がインストールされます。

Picon の表示ができるようにするためには、picon データベースがあるディレクトリーが、ただ単に gnus-picon-databases に設定されているようにして下さい。

変数 gnus-picon-style は picon をどのように表示するかを制御します。 inline だったらテキスト形式の表現が置き換えられます。 right だったら、テキスト形式の表現の右側に picon が加えられます。

ものごとの所在を管理するために、以下の変数を設けています。

gnus-picon-databases
     Picon データベースの場所です。これは news, domains, users (などなど) のサブディレクトリーが含まれているディレクトリーのリストです。("/usr/lib/picon" "/usr/local/faces") がディフォルトです。

gnus-picon-news-directories
     gnus-picon-databases からニュースグループ用のフェースを探すためのサブディレクトリーのリストです。ディフォルトは ("news") です。

gnus-picon-user-directories
     gnus-picon-databases から利用者のフェースを探すためのサブディレクトリーのリストです。("local" "users" "usenix" "misc") がディフォルトです。

gnus-picon-domain-directories
     gnus-picon-databases からドメイン名のフェースを探すためのサブディレクトリーのリストです。ディフォルトは ("domains") です。このリストに "unknown" を追加しておきたくなる人もいるでしょう。

gnus-picon-file-types
     Picon のファイル名として試してみる拡張子の順番リストです。ディフォルトは、 ("xpm" "gif" "xbm") から Emacs に組み込まれていないものを除外したものです。

さまざまな XEmacs 変数
---------------

gnus-xmas-glyph-directory
     これは Gnus が絵を探す場所です。Gnus は通常このディレクトリーを自動検出しますが、もし標準的でないディレクトリー構造を持っている場合は、これを手動で設定することができます。

gnus-xmas-logo-color-alist
     これは連想リストで、キーは種別シンボル、値はタイトルページの絵文字の前面色と背景色です。

gnus-xmas-logo-color-style
     これは前記の連想リストで色を検索するのに使われるキーです。有効な値には flame, pine, moss, irish, sky, tin, velvet, grape, labia, berry, neutral, september があります。

gnus-xmas-modeline-glyph
     すべての Gnus モード行で表示される絵文字。これはディフォルトではちいさなヌー (gnu) の頭です。

ツールバー
.....

gnus-use-toolbar
     nil ならばツールバーを表示しません。nil 以外の場合は、 default-toolbar, top-toolbar, bottom-toolbar, right-toolbar, left-toolbar のどれかでなくてはなりません。

gnus-group-toolbar
     グループバッファー内のツールバーです。

gnus-summary-toolbar
     概略バッファー内のツールバーです。

gnus-summary-mail-toolbar
     メールグループの概略バッファー内のツールバーです。

ファジーな一致
=======

Gnus は、スコア付け、スレッドの形成、スレッド比較などを行なうときに、 Subject 行のファジーな一致 fuzzy matching 方法を提供しています。

正規表現一致とは違って、ファジーな一致はとってもファジーです。あまりにもファジーすぎて、何がファジー fuzziness であるかという定義さえ無いし、実装も何度も変更されています。

基本的には、これは比較の前に行から邪魔物を取り除こうとします。 Re:  や挿入句の印や空白文字等々は文字列から除去され、その結果を比較します。これはほとんどの場合妥当な結果を出します---たとえニュースリーダーの仮面をかぶった文字列切り刻み機で生成された文字列が差し出されても、です。

spam メールの裏をかく
=============

ここ最近の USENET では、宣伝のハゲタカどもが、彼らの詐欺や製品を押し付けるための電子メールアドレスを探そうとして、気違いのようにニュース上をうろついて grep しまくっています。これに対する反動として、多くの人々が From 行に無意味なアドレスを入れはじめるようになってしまいました。これは非生産的なことだと私は思います---あなたが書いたことに対する返信として正当なメールを送ることを面倒にさせ、また誰が書いたものなのかを分かりづらくします。こんな書き換えは結局は、押し付け宣伝メールそれ自身よりも大きな脅威となるかもしれません。

私にとっての spam メールの最大の問題は、嘘の口実で入ってくるからです。私が g を押したとすると、Gnus は十通の新着メールがありますと陽気に私に教えてくれます。私は ``おおっ、わーい! 僕って幸せ!'' と言ってメールグループを選択します。しかしそこには、二つのネズミ講と、七つの広告 (``最新! 奇跡の増毛トニック、ふさふさでつやつやの髪を、あなたのつま先まで!'') と、悔い改め神を信じよ、という一つのメールがあるだけなのです。

これは不愉快です。あなたがそれに関してできることがあります。

Spam の問題
--------

初めに spam の背景から。

あなたが電子メールを使っているならば、spam (専門用語としては Unsolicited Commercial E-mail---望まれない商用電子メール---の頭文字 UCE) のことはよく知っているでしょう。簡単に言えばそれは紙のメールに比べて電子メールの配送がとても安くつくために存在し、非常に小さな割合の人々が UCE に応答するだけで広告主に利益をもたらすのです。皮肉なことに最も一般的な spam の一つは、さらに spam を助長するための電子メールアドレスのデータベースを提供します。Spam の送信者はふつう spammers と呼ばれますが、vermin、scum、 sociopaths および morons のような用語もよく使われています。

Spam は種々さまざまな出どころからやって来ます。有用なメッセージを捨てずにすべての spam を単に始末することは不可能です。良い例は TMDA (訳注: 送信する度にユニークなアドレスを使う) システムで、それはあなたが知らない送信者に、彼らの電子メールが届く前に彼らが正当な送信者であることの確認を求めます。正当な出どころからの電子メールが TMDA システムによってそれらの出どころが確認できない、または行なわれない場合は捨てられてしまうかもしれないというマイナス面は、TMDA の技術的な側面に立ち入らなくても明白です。もう一つの TMDA の問題は、電子メールの配送と処理への基本的な理解を利用者に求めていることです。

Spam の除去 (filtering) への最も単純な取り組みは、メールサーバーで、あるいは入ってきたメールを分類するときに濾過すること (filtering) です。毎日 random-address@vmadmin.com から 200通の spam メッセージを受け取るのならば、vmadmin.com を阻止すればよろしい。バイアグラ に関するメッセージを 200通受け取るのならば、バイアグラ を含むすべてのメッセージを捨ててしまえばよろしい。例えばブルガリアからたくさんの spam がやって来るのならば、ブルガリアの IP から来るすべてのメールを濾過すればよろしい。

これは、残念ながら正当な電子メールを捨てるためのすぐれた方法です。あなたに接触しようとする国 (ブルガリア、ノルウェー、ナイジェリア、中国、等) 全体、または大陸 (アジア、アフリカ、ヨーロッパ、等) さえも封じ込めてしまう危険は明らかなので、あなたに選択権があるのならば、そんなことはしないで下さい。

もう一つの例として、とても示唆に富んで有益な RISKS ダイジェストは、それが spam メッセージと共通の語を 含んで いるために、熱心すぎるメール濾過器によって阻止されてしまいます。それでもなお孤立した環境では、注意深く使うことによって直接の濾過は有益になり得ます。

もう一つの電子メール濾過への取り組みは分散型 spam 処理で、DCC (訳注: Distributed Checksum Clearinghouse---http://www.rhyolite.com/anti-spam/dcc/) がそのようなシステムを導入しています。本質的には、世界中の N 個のシステムが、ガーナ、エストニアあるいはカリフォルニアにあるマシン X が spam 電子メールを送出していることを認めたら、それら N 個のシステムは X または X からやって来た spam メールをデータベースに記入します。Spam 検出の基準は変わります。それは送られたメッセージの数やメッセージの内容などであるかもしれません。メッセージが spam かどうかを分散処理システムの利用者が知りたい場合、彼はそれらの N 個のシステムのうちの一つを調べます。

分散型 spam 処理は同時に多くのメッセージを送る spammers と非常によく戦ってくれますが、それは利用者がかなり複雑なチェックを設定することを求めます。商用と、フリーな分散型 spam 処理システムがあります。分散型 spam 処理は、それ自体の危険もはらんでいます。例えば、正当な送信者が spam を送ったかどで非難され、彼らのウェブサイトやメーリングリストがその事件のために暫くの間閉鎖されてしまう、とか。

Spam 濾過への統計的な取り組みもまた普及しています。それは過去の spam メッセージの統計分析に基づいています。通常その分析は、おそらく単語の対か三つの単語の組合せの合成による、単語の出現頻度の単純な計数です。Spam の統計分析はほとんどの場合にとてもよく働くのですが、時として正当な電子メールを spam として分類してしまうことがあります。分析には時間がかかります。すべてのメッセージを分析しなければなりません。そして利用者は spam を分析するためのデータベースを用意しなければなりません。サーバーでの統計分析は人気を得ています。これには、利用者は単にメールを読めば良いという長所と、しかしサーバーにそれが過ってメールを分類したことを伝えるのが困難だという短所があります。

余人の言を待たずとも、spam との戦いは楽ではありません。ママからの電子メールとバイアグラ広告を区別する魔法のスイッチはありません。人々は非-spam と spam を区別するのに手を焼いているというのに。それは、 spammers が懸命にそれらをママだと思わせようとしているのが本質だからです。 Spamming は、世界が彼らに恩義があると思っている人々の一団からの、腹立たしく、無責任で、ばかげた行為です。以下の各項が spam なる疫病との戦いの助けになることを望みます。

Spam 退治の基礎
----------

Spam に対処する一つの方法は、Gnus にすべての spam を spam メールグループに分離させてしまうことです (see Splitting Mail)。

最初に、あなたに到達性のある正しいメールアドレスを一つ選び、それをすべてのあなたのニュース記事の From ヘッダーに入れます。(ここでは larsi@trym.ifi.uio.no を選びましたが、 larsi+usenet@ifi.uio.no 形式のたくさんのアドレスの方が良い選択です。あなたのサイトの sendmail の設定がメールアドレスのローカル部としてどんなキーワードを受け付けるかは、あなたのサイトのシステム管理者に聞いて下さい。)

     (setq message-default-news-headers
           "From: Lars Magne Ingebrigtsen <larsi@trym.ifi.uio.no>\n")

そして nnmail-split-fancy に以下の分離規則を入れます (see Fancy Mail Splitting)。

     (...
      (to "larsi@trym.ifi.uio.no"
          (| ("subject" "re:.*" "misc")
             ("references" ".*@.*" "misc")
             "spam"))
      ...)

この意味は、このアドレスに届いたすべてのメールをまず疑いますが、 Re: で始まる Subject がついているか、References ヘッダーがついていればおそらく OK だろう、ということです。残りはすべて spam グループに行きます (このアイデアはおそらく Tim Pierce 氏によるものです)。

これに加えて、多くのメール spam 屋は、あなたのところの SMTP サーバーと直接話し、To ヘッダーにあなたのメールアドレスが明示されないようにします。なんでそんなことをするのかはわかりませんが---おそらく私たちの裏をかく機構の裏をかくためかな? どちらにしても、対処は簡単なことです---あなた宛てでないものを全部 spam グループにいれるだけです。これはお好み分離規則の最後にこんな風に入れることでできます。

     (
      ...
      (to "larsi" "misc")
      "spam")

私の経験では、これで事実上すべてが正しいグループに分類されます。まあ、それでもときどき spam グループをチェックして、正しいメールがあるかチェックしなくてはいけませんけどね。もしあなたは自分が良いネットワーク市民であると思っているなら、それぞれの押し付け宣伝メールの関係当局に苦情を送り付けることさえもできます---暇なときにでもね。

これで私のところでは動いています。これでみんなは簡単な方法で私に連絡を取ることができ (普通に r を押すだけでできる)、私は spam に煩わされることはまったくありません。得々状態です。私の意見としては、From ヘッダーを偽造して存在しないドメインに送らせるのはキタナイです。

この手法には注意して下さい。Spammers はそれに気付いています。

SpamAssassin, Vipul's Razor, DCC, etc
-------------------------------------

Spam を避けるための前項のヒントが十分だった日々は過ぎ去りました。今では受け取ったたくさんの spam を減らすための多くの道具があります。この項は新旧置き換えによってすぐに時代遅れになってしまうでしょうが、幸いなことにほとんどの道具は類似のインターフェースを持っています。この項は例として SpamAssassin を使っていますが、他のほとんどの道具にも簡単に適合するはずです。

この項は spam.el パッケージとは関係無いことに注意して下さい。それは次の項で論じられます。すべての spam.el の機能に関心が無いのならば、これらの単純なレシピで間に合わせることができます。

もしあなたが使う道具がメールサーバーにインストールされていないならば、あなた自身がそれを呼び出す必要があります。以下に :postscript メールソース指示子 (see Mail Source Specifiers) を使う場合の考え方を示します。

     (setq mail-sources
           '((file :prescript "formail -bs spamassassin < /var/mail/%u")
             (pop :user "jrl"
                  :server "pophost"
                  :postscript
                  "mv %t /tmp/foo; formail -bs spamc < /tmp/foo > %t")))

いったん、メールを受けるスプールをどうにかして処理する、例えば メールに spam であることを表示するヘッダーを含める、ようにすれば、それをふるい落とす準備は完了です。使うのは普通の分割方式 (see Splitting Mail) です:

     (setq nnmail-split-methods '(("spam"  "^X-Spam-Flag: YES")
                                  ...))

または特級分割方式 (see Fancy Mail Splitting) です:

     (setq nnmail-split-methods 'nnmail-split-fancy
           nnmail-split-fancy '(| ("X-Spam-Flag" "YES" "spam")
                                  ...))

いくらかの人たちは :prescript を使ってメールをいろんなプログラムにパイプすることを嫌うかもしれません (もし何かのプログラムにバグがあったら、すべてのメールを失ってしまうかもしれません)。あなたがそれらの一人ならば、別の解は分割するときに外部の道具を呼ぶことです。特級分割方式の例です:

     (setq nnmail-split-fancy '(| (: kevin-spamassassin)
                                  ...))
     (defun kevin-spamassassin ()
       (save-excursion
         (widen)
         (if (eq 1 (call-process-region (point-min) (point-max)
                                        "spamc" nil nil nil "-c"))
             "spam")))

さらに nnimap バックエンドの場合、ディフォルトでは記事のボディーがダウンロードされないことに注意して下さい。それをするためには、 nnimap-split-download-body を t に設定する必要があります (see Splitting in IMAP)。

以上がこれに関することです。いくつかの spam はどうしても素通りしてしまうので、spam を読むはめになったときに呼ぶための気の利いた関数が欲しいでしょう。これがその気の利いた関数です:

      (defun my-gnus-raze-spam ()
       "Submit SPAM to Vipul's Razor, then mark it as expirable."
       (interactive)
       (gnus-summary-show-raw-article)
       (gnus-summary-save-in-pipe "razor-report -f -d")
       (gnus-summary-mark-as-expirable 1))

Hashcash
--------

Spam と戦うための新しい技法は、いくばくかの負担にはなるが明らかに独特なことを、送信するメッセージに対して送信者が行なうことを求めることです。これはインターネット標準の一部ではないので、世界中のすべての人がこの技法を使うことは当てにできないという明らかな欠点がありますが、小規模な共同体では役に立つでしょう。

前項の道具類が実際にうまく働いたとしても、それらは新しい形式の spam が現れるたびにしょっちゅう更新かつ整備されることによってのみ動作します。このことは、小さなパーセンテージの spam がいつも素通りしてしまうことを意味します。それはまた、どこかでだれかがそれらの道具を更新するために、たくさんの spam を読まなければならないことをも意味します。Hashcash はそれを回避しますが、代わりにあなたが電子メールで連絡するすべての人たちに、なるべくその仕組みを使ってもらう必要があります。あなたは実用 (pragmatic) と教条 (dogmatic) の二つの取り組みを考えることができます。それらの取り組みには利点もあれば不利な点もありますが、それは世の中では普通のことで、それらを連係させたものが他のばらばらなものより強力なのです。

「いくばくかの負担」とは CPU 時間を消費することで、具体的には一定数のビットまでハッシュの衝突 (hash collision) を計算することです。その結果としての hashcash クッキーは X-Hashcash: ヘッダーに挿入されます。もっと詳しいこと、そしてこの機能を使うためにインストールする必要がある外部アプリケーションの hashcash については http://www.hashcash.org/ を参照して下さい。さらなる情報が http://www.camram.org/ で見つかるでしょう。

送信するメッセージのそれぞれについて hashcash を生成させようと思うなら、以下のように message-generate-hashcash (see メールヘッダー (The Message Manual)) をカスタマイズして下さい:

     (setq message-generate-hashcash t)

いくつかの追加の変数の設定もしなければなりません:

hashcash-default-payment
     この変数はハッシュの衝突を成すディフォルトのビット数を示します。規定値は 20 です。提唱されている有効な値は 17 から 29 までの数です。

hashcash-payment-alist
     何人かの受取人は、あなたにディフォルトより多くの CPU 時間を費やすことを要求するかもしれません。この変数は (ADDR AMOUNT) の形式の要素のリストで、ADDR は受取人 (メールアドレスかニュースグループ)、AMOUNT は必要とされる衝突のビット数です。これはまた (ADDR STRING AMOUNT) の要素を持つことも可能で、STRING は文字列 (通常はメールアドレスかニュースグループ名) として使われます。

hashcash-path
     hashcash バイナリがインストールされている場所。この変数は executable-find によって自動的に設定されるはずですが、それが nil だった (ありがちなのは hashcash バイナリが実行 path 中に無い) 場合は、hashcash payments をチェックするときに警告され、 hashcash payments を生成するときはエラーになるでしょう。

Gnus は hashcash クッキーを認証することができますが、手でカスタマイズしたメール濾過スクリプトで行なうこともできます。メッセージ中の hashcash クッキーを認証するには、hashcash.el ライブラリの mail-check-payment 関数を使って下さい。入ってきたメールの hashcash クッキーを確認し、それによってメールを濾過するために、 spam-use-hashcash バックエンドで spam.el を使うこともできます (see Anti-spam Hashcash Payments)。

Spam ELisp パッケージを使った Spam の濾過
-----------------------------

spam.el の真の目的は spam 検出と濾過のための官制センターを Gnus の中に持つことです。そのために spam.el は二つのことを行ないます: 新しいメールを濾過し、spam または ham として知られるメールを分析することです。Ham は spam.el のいたる所で spam ではないメッセージを示すために使う名前です。

spam.el シーケンスのイベントの項をちゃんと読みましょう。 Spam ELisp Package Sequence of Events を参照して下さい。

spam.el を使うには、spam.el を自動読み込み (autoload) して spam.el の各フックをインストールするために、関数 spam-initialize を 実行しなければなりません。一つ例外があります: もし spam-use-stat の設定を使う (see spam-stat spam filtering) のであれば、それを spam-initialize より前に on にしておかなければなりません:

     (setq spam-use-stat t) ;; 必要なら
     (spam-initialize)

では spam.el を読み込むと何が起きるでしょうか?

第一に spam-initialize によっていくつかのフックが動作するようになります。spam-stat がそれらのデータベースをセーブできるようにするフックと、グループに入るときと抜けるときに興味深いものごとを起こすフックがあります。シーケンスのイベントについての詳細は後述 (see Spam ELisp Package Sequence of Events)。

以下のキーボード命令が使えるようになります:

M-d
M s x
S x
     gnus-summary-mark-as-spam。

     現在の記事に spam として印を付け、それを $ 印で表示します。 Spam 記事を見たときはいつでも、グループを抜ける前に必ず M-d でその概略行に印を付けるようにして下さい。これは spam グループの未読記事に対しては自動的に行なわれます。

M s t
S t
     spam-bogofilter-score。

     このコマンドがちゃんと働くためには Bogofilter をインストールしなければなりません。

     See Bogofilter.

また、spam.el を読み込むと、その変数群をカスタマイズすることができるようになります。spam 変数グループについて customize-group を試してみて下さい。

Spam ELisp Package Sequence of Events
.....................................

どのように spam.el が働くかを理解するために、必ずこの項を読んで下さい。読み飛ばし、速読、または斜め読みしてはいけません。

spam.el と Gnus の間には、二つの 接点 があると考えられます。 Spam のために新着メールを検査するとき、およびグループを抜けるときです。

Gnus における新着メールの取得は、二つの方法の一方で行なわれます。新着メールを分割するか、グループに入るときに新しい記事を ham と spam に分類するかの、どちらでも可能です。

新着メールの分割は、nnml や nnimap のように、新しいメールが Spool File と呼ばれる一つのファイルになるバックエンドに、より適しています。Spam ELisp Package Filtering of Incoming Mail を参照して下さい。

nntp のようなバックエンドには新着メールのスプールが無いので、代わりの機構を使わなければなりません。これは、サーバーが新着メールの分割を担当していて、Gnus がさらにまた分割を行なわないバックエンドでも、(代わりの機構が) 必要になるかもしれません。グループパラメーター spam-autodetect と spam-autodetect-methods (普通 G c and G p で操作可)、そしてそれらに対応する変数 gnus-spam-autodetect および gnus-spam-autodetect-methods (M-x customize-variable で操作可) が役立ちます。

spam-autodetect が使われる場合 (それはグループ/トピックについて、あるいは必要に応じて、正規表現の合致によって十把ひとからげに ON にできます)、それはグループに入る (そのグループの概略バッファーに移動する) 処理において実行されます。したがって、まだ読まれたことが無い、または未読の記事があるグループに入ることは、新着メールの検査の代わりになります。まだ読まれたことが無い記事、またはすべての未読の記事が処理されるかどうかは、 spam-autodetect-recheck-messages によって決まります。t に設定されると、未読のメッセージが再検査されます。おそらく、まだ読まれたことが無いメッセージのディフォルトの検査だけは、着実に行なわなければならないでしょう。

spam-autodetect は、多少なりとも spam 濾過の管理を利用者に許可します。利用者は各グループの spam 検出の手段をより多く管理することができるでしょう。したがって、疑わしい (suspect) グループで spam-use-blacklist および spam-use-bogofilter の手段が有効になっていても、例えば ding グループは自動検出手段として spam-use-BBDB を持つことができます。Spam として検出されるすべての記事には spam 印 $ が付けられ、グループを抜けるときに通常の spam として処理されます。彼が spam-split で行なっても良いように、利用者は検査の sequence をより少なく管理します。

新たに分割されたメールがグループに入った、またはメッセージが ham または spam として自動検出された場合、後に spam 処理を行なわせるために、それらのグループを (必要なら入った後で) 抜け出なくてはなりません。グループがその spam-content パラメーター (see Spam ELisp Package Global Variables) に基づいて ham または spam グループと考えられるか、未分類かどうかは重要です。Spam グループは、そこに入ると、まだ読まれたことが無い、または未読の記事に spam の印が付けられる (変数 spam-mark-only-unseen-as-spam に依存) という付加的な特性を持ちます。このように、分割されて spam グループに入れられた記事には、あなたがそのグループに入ったときに自動的に spam の印が付けられます。

したがって、グループ (の概略バッファー) を抜けると spam-processors が (何であれ設定されていれば) 適用され、処理されたメールは記事の分類に基づいて ham-process-destination か spam-process-destination に移動させられます。ham-process-destination または spam-process-destination のどちらかが (訳註: 移動先として) ふさわしい場合でも、それらが nil だった場合、その記事は現在のグループに残されます。

どれかのグループで spam が見つかったら (非-spam グループに限っては spam-move-spam-nonspam-groups-only で変更可)、グループを抜けるときに活きている spam-processors (see Spam ELisp Package Global Variables) で処理されます。さらに、後でトレーニングまたは削除するために、spam は spam-process-destination (see Spam ELisp Package Global Variables) に移動させられます。Spam が再三処理されることを望まないならば、gnus-registry.el パッケージを読み込み、 spam-log-to-registry 変数を有効にしなければなりません。このように spam はどこでも検出され処理されます。それはほとんどの人々が、そうしたいと思うことです。spam-process-destination が nil だった場合、spam には期限切れ消去の印が付けられます。普通それは正しい行ないです。

Spam が移動できない場合 (例えば NNTP のような読み込み専用バックエンドであるために)、それはコピーされます。

Ham グループで ham-marks パラメーターで決定される ham メールが見つかったら、グループを抜けるときに活きている ham spam-processor で処理されます。さらに、変数 spam-process-ham-in-spam-groups および spam-process-ham-in-nonham-groups によって、どこで見つかった ham でも処理できるように動作を変更することができます。Ham が再三処理されることを望まないならば、gnus-registry.el パッケージを読み込み、 spam-log-to-registry 変数を有効にしなければなりません。このように ham は必要な場合だけ検出され処理されます。それはほとんどの人々が、そうしたいと思うことです。これに関する詳細は see Spam ELisp Package Configuration Examples.

Ham が移動できない場合 (例えば NNTP のような読み込み専用バックエンドであるために)、それはコピーされます。

これらのすべてがわけがわからなくても、心配は要りません (訳注: でも訳文が正確ではないかもしれないので、変だと思ったら原文を見てね :-p)。すぐにそれは神経インターフェース上に Lisp で小話を書くように自然なことになります... え゛ごめん、それにはまだ 50年早いですね。ただ私たちを信頼して下さい。それは捨てたものではありません。

Spam ELisp Package Filtering of Incoming Mail
.............................................

入ってくるメールを濾過する目的で spam.el を使うには、特級分割リスト nnmail-split-fancy または nnimap-split-fancy に以下を追加しなければなりません:

     (: spam-split)

特級分割は、メールの取り込みに nnmail か nnimap のどちらのバックエンドを使っているかに応じて、nnmail-split-fancy または nnimap-split-fancy から呼ばれることに注意して下さい。

さらに、spam-split はいかなる方法によっても新着メールを改変しません。

spam-split 関数は入ってくるメールを処理し、spam と思われるメールを変数 spam-split-group で与えられる名前のグループに送ります。ディフォルトではそのグループ名は spam ですが、 spam-split-group をカスタマイズすることが可能です。 spam-split-group の内容が 絶対 グループ名であること、例えば your-server という nnimap サーバーの場合は、 spam 変数が最終的に nnimap+your-server:spam になることを確かめて下さい。従って nnimap+server:spam という値は間違いで、それは実際には nnimap+your-server:nnimap+server:spam というグループになり、それが働くか働かないかは、あなたのサーバーが奇妙なグループ名に対して寛容かどうかに依存するでしょう。

また、spam-split にパラメーター、例えば spam-use-regex-headers または "maybe-spam" を与えることもできます。なぜこれが有用なのでしょうか?

これらの (spam-use-regex-headers と spam-use-blackholes の設定による) 分割の規則を見て下さい:

      nnimap-split-fancy '(|
                           (any "ding" "ding")
                           (: spam-split)
                           ;; ディフォルトのメールボックス。
                           "mail")

さて、問題は ding 宛てのメッセージをすべて ding フォルダーに入れようとしていることです。でもそれは ding メーリングリスト宛てに送られた spam (例えば SpamAssassin と spam-use-regex-headers によって検出される spam) を許してしまうでしょう。一方、いくつかの ding 宛てのメッセージはブラックホールリストに載っているメールサーバーからやって来るので、 ding の規則より前に spam-split を発動することができません。

SpamAssassin ヘッダーに ding の規則を置き換えさせることはできますが、他のすべての spam-split の規則 (第二の正規表現ヘッダー検査を含む) は ding の規則の後になってしまうでしょう。

      nnimap-split-fancy '(|
     ;;; spam-use-regex-headers で検出された
     ;;; すべての spam は regex-spam へ。
                           (: spam-split "regex-spam" 'spam-use-regex-headers)
                           (any "ding" "ding")
     ;;; spam-split で検出された他のすべての spam は
     ;;; spam-split-group へ。
                           (: spam-split)
                           ;; ディフォルトのメールボックス。
                           "mail")

基本的に、これは特にあなたの必要に依存した特定の spam-split 検査を起動させ、それらの検査の結果は特定の spam グループを指し示します。すべてのメールをすべての spam テストに投げる必要はありません。これが良い別の理由は、規則を持っているメーリングリストへのメッセージに対して、資源集約的なブラックホール・チェックを実行する必要がないということです。さらに nnmail 分割に対して nnimap 分割のための、異なる spam 検査を指定することもできます。気が狂うー。

検査と同時に明らかに spam-split を実行するとしても、今までとおり spam-use-regex-headers を t に設定するような検査を行なっていなければなりません。なぜなら spam.el を読み込むときに、あなたが何の spam-use-xyz 変数を設定しているかに応じた、いくつかの条件付きの読み込みが行なわれるからです。

IMAP 利用者への注意

ヘッダーだけではなくてメッセージ全体に基づいて分割を行ないたい場合は、ブール変数 nnimap-split-download-body が設定される必要があります。ディフォルトでは、nnimap バックエンドはメッセージヘッダーだけを取り込みます。例えば spam-check-bogofilter、spam-check-ifile または spam-check-stat (それらの分割器はメッセージの本文全体から情報を得る) のような 統計的な 濾過器を使うならば、この変数は自動的に設定されるでしょう。それは IMAP の動作を遅くしてしまうので、統計的ではないバックエンドに対してディフォルトでは設定されていません。

See Splitting in IMAP.

Spam ELisp Package Global Variables
...................................

Ham プロセッサーと spam プロセッサーの概念は非常に重要です。あるグループの ham プロセッサーと spam プロセッサーは、spam-process グループパラメーターか gnus-spam-process-newsgroups 変数で設定することができます。後で同様のメールを spam ではないと解釈できるようにするために、 ham プロセッサーは非 spam (ham) であることがわかっているメールを受け取って、何らかの方法で処理します。Spam プロセッサーは、後で同様の spam が検出されるように、spam であることがわかっているメールを受け取って処理します。

Spam または ham プロセッサーを指定する形式を、かつてはシンボルで表していたのですが、現在は CONS セルになっています。詳しくは個々の spam プロセッサーの項を参照して下さい。

Gnus はあなたが受け取った spam から学びます。あなたは一つ以上の spam グループに spam 記事を集めて、変数 spam-junk-mailgroups を適切に設定もしくはカスタマイズしなければなりません。また、spam を含めるグループを、そのグループパラメーター spam-contents を gnus-group-spam-classification-spam に設定するか、またはそれに対応する変数 gnus-spam-newsgroup-contents をカスタマイズすることによって宣言することができます。spam-contents グループパラメーターと gnus-spam-newsgroup-contents 変数は、それらの種別を gnus-group-spam-classification-ham に設定することによって、 ham グループであることを宣言するために使うこともできます。グループが spam-junk-mailgroups, spam-contents または gnus-spam-newsgroup-contents であることを示す分類が行なわれていないと、それらは 未分類 であると解釈されます。すべてのグループはディフォルトでは未分類です。

Spam グループでは、ディフォルトですべてのメッセージが spam であると解釈されます: そのグループに入ると、それらに $ 印 (gnus-spam-mark) が付きます。メッセージを見ていったんそれに spam の印を付けても、後で取り消せば、その後そのグループに入ったときに、それには spam 印は付きません。ただし spam-mark-only-unseen-as-spam パラメーターを nil にすれば、そういう動作をやめさせる、つまりすべての未読メッセージに spam 印が付くようにすることができます。そのグループの概略バッファーにいるとき、やっぱり spam ではなかったすべての 記事から $ 印を消さなければなりません。$ 印を消すには M-u でその記事を ``未読'' にするか、あるいは d で spam ではないものとして読んだことを宣言すれば良いでしょう。グループを抜けるとき、すべての spam 印 ($) が付いた記事は spam プロセッサーに送られ、それらを spam の標本として学習します。

メッセージは他のいろいろな方法によっても消去されるかもしれないし、 ham-marks グループパラメーターが無効にされなければ、低いスコアのための Y 印と同様、ディフォルトの既読か明示的な消去のための R と r 印、自動または明示的な削除のための X と K 印、それらすべてが spam 記事とは無関係であると解釈されます。この仮定は、本物の spam を検出するために消去 (kill) ファイルかスコアファイルを特別に使っている場合は間違っているかもしれません。そうであれば ham-marks グループパラメーターを調整するべきです。

 -- Variable: ham-marks
     このグループまたはトピックパラメーターを ham であると解釈したい印のリストに設定することができます。ディフォルトでは、消去 (deleted)、既読 (read)、削除 (killed)、kill ファイルにあるもの (kill-filed) および低いスコア (low-score、既読だけれども spam ではないと考える) 印のリストです。Ham 印のリストに可視 (tick) 印を含めることが役立つこともあります。未読印を ham 印にすることは、通常それが分類が足りていないことを表すので、勧められません。しかし、あなたがそれを行なうことはできるし、私たちに不満はありません。

 -- Variable: spam-marks
     このグループまたはトピックパラメーターを spam であると解釈したい印のリストに設定することができます。ディフォルトでは spam 印だけを持つリストです。それを変更することは勧めませんが、本当にそうしたいのならご勝手に。

グループを抜けるときに (そのグループが 何 であっても)、その spam-contents の分類にかかわらず、spam 印が付いているすべての記事は spam プロセッサーに送られ、それらを spam の標本として学習します。意図的にたくさんの消去を行なうと、たまにそれは見ていない K 印が付いた記事で終わるかもしれません。そしてそれらは偶然に spam を含んでいるかもしれません。最も良いのは、本当の spam に $ が付いていて、他に何も無いことを確かめることです。

Spam グループを抜けるときに、spam 印が付いているすべての記事には spam プロセッサーで処理した後で期限切れ消去の印が付けられます。これは 未分類 または ham グループに対しては行なわれません。さらに spam グループにあるどの ham 記事も、 ham-process-destination グループパラメーターか gnus-ham-process-destinations 変数のどちらかに合致する場所に移されます。それらはグループ名に合致する正規表現のリストです (M-x customize-variable RET gnus-ham-process-destinations によってこの変数をカスタマイズするのが最も簡単です)。変数を手でカスタマイズする方が好きな人のために言っておくと、それぞれのグループ名のリストは普通の Lisp の list です。 ham-process-destination パラメーターが設定されていないと、ham 記事はそこに留め置かれます。 spam-mark-ham-unread-before-move-from-spam-group パラメーターが設定されていると、ham 記事は移動させられる前に未読の印が付けられます。

Ham が移動できない場合 (例えば NNTP のような読み込み専用バックエンドであるために)、それはコピーされます。

グループまたは正規表現ごとに複数の移動先を指定できることに注目して下さい! これによって ham 記事を正規のメールグループと ham トレーニング グループに送ることができます。

Ham グループを抜けるときに、ham 印が付いているすべての記事は ham プロセッサーに送られ、それらを spam ではない標本として学習します。

変数 spam-process-ham-in-spam-groups はディフォルトでは nil です。Spam グループで見つかった ham がプロセッサーに送られるようにしたい場合は t にして下さい。通常これは行なわれません。あなたが自分で ham 記事を ham グループに送って、そこで処理することが期待されています。

変数 spam-process-ham-in-nonham-groups はディフォルトでは nil です。Ham ではない (spam または未分類の) グループで見つかった ham がプロセッサーに送られるようにしたい場合は t にして下さい。通常これは行なわれません。あなたが自分で ham 記事を ham グループに送って、そこで処理することが期待されています。

Ham または 未分類 グループを抜けるときに、すべての spam 記事は、spam-process-destination グループパラメーターか gnus-spam-process-destinations 変数のどちらかに合致する場所に移されます。それらはグループ名に合致する正規表現のリストです (M-x customize-variable RET gnus-spam-process-destinations によってこの変数をカスタマイズするのが最も簡単です)。変数を手でカスタマイズする方が好きな人のために言っておくと、それぞれのグループ名のリストは普通の Lisp の list です。 spam-process-destination パラメーターが設定されていないと、spam 記事は単に期限切れ消去されます。グループ名は完全形であること、すなわちグループバッファーでグループ名の前に nntp:servername のようなものが見える場合は、ここでもそれを使う必要があります。

Spam が移動できない場合 (例えば NNTP のような読み込み専用バックエンドであるために)、それはコピーされます。

グループまたは正規表現ごとに複数の移動先を指定できることに注目して下さい! これによって spam 記事を正規のメールグループと spam トレーニング グループに送ることができます。

Ham と spam に関する問題は、Gnus がディフォルトではこの処理を追跡してくれないことです。処理された記事を追跡し、かつ複数回にわたって処理することを回避するために spam.el が gnus-registry.el を使うように、 spam-log-to-registry 変数を有効にして下さい。登録数を制限すると、制限が無い場合のように動作しないことを覚えておいて下さい。

Spam グループにある、まだ読まれたことが無い記事だけに spam の印を付けたい場合は、この変数をセットして下さい。ディフォルトではセットされています。これを nil にすると、未読の記事にも spam 印が付けられます。

Ham が spam グループから移動される前に印を消したい場合は、この変数をセットして下さい。これは ham に印を付けるために可視 (tick) 印のようなものを使う場合に、とても役に立ちます。記事はあたかもそれがメールサーバーを出たばかりのように、無印で ham-process-destination に置かれるでしょう。

この変数は spam.el が spam の自動検出を行なう場合に、まだ読まれたことが無い記事だけ、またはすべての未読記事の spam 検査を行なうかどうかを指示します。これはそのままにしておくことを勧めます。

Spam ELisp Package Sorting and Score Display in Summary Buffer
..............................................................

概略バッファーに spam のスコアを表示することができます。また、それらの spam のスコアによって、記事を並べ替えることもできます。

最初に、どのバックエンドを使うかを決める必要があります。 spam-use-spamassassin、spam-use-spamassassin-headers または spam-use-regex-headers バックエンドを使う場合、 X-Spam-Status ヘッダーが使われます。spam-use-bogofilter を使う場合は、X-Bogosity が使われます。spam-use-crm114 を使うのならば、CRM114 スコア・フォーマットに合致する、いずれかのヘッダーが使われます。spam.el をロードする 前 に、適切なバックエンド変数を t に設定する限り、うまくいくでしょう。spam.el は、Gnus が内部的に必要とするヘッダーのリストに、正しいヘッダーを自動的に追加します。

概略バッファーに spam のスコアを表示させるには、この行を ~/.gnus.el ファイルに加えて下さい (注: spam.el はディフォルトではそれを行なわないので、あなたが持っているかもしれない、存在するどんな S フォーマットよりも優先されません)。

     (defalias 'gnus-user-format-function-S 'spam-user-format-function-S)

では、概略バッファーの行書法仕様 (summary line format) が %uS を使うように設定しましょう。以下は spam のスコアを 5桁のフィールドに表示する例です:

     (setq gnus-summary-line-format
      "%U%R %10&user-date; $%5uS %6k  %B %(%4L: %*%-25,25a%) %s \n")

最後に、spam の状態による並べ替えを全グループで行なわせるようにしましょう:

     (setq
      gnus-show-threads nil
      gnus-article-sort-functions
       '(spam-article-sort-by-spam-status))

グループ毎に行なわせたい場合は Sorting the Summary Buffer を参照して下さい。

Spam ELisp Package Configuration Examples
.........................................

Ted の設定
.......

From Ted Zlatanov <tzz@lifelogs.com>.

     ;; gnus-registry-split-fancy-with-parent と spam の
     ;; 自動検出のため。詳細は gnus-registry.el を参照。
     (gnus-registry-initialize)
     (spam-initialize)

     ;; 私は spam 印を付けるのに C-s を好む。
     (define-key gnus-summary-mode-map "\C-s" 'gnus-summary-mark-as-spam)

     (setq
      spam-log-to-registry t ;; Spam の自動検出のため。
      spam-use-BBDB t
      spam-use-regex-headers t ;; X-Spam-Flag (SpamAssassin) をつかまえる。
      ;; 名前に spam を含むすべてのグループには spam 記事がある。
      gnus-spam-newsgroup-contents '(("spam" gnus-group-spam-classification-spam))
      ;; これらの docstring を参照。
      spam-move-spam-nonspam-groups-only nil
      spam-mark-only-unseen-as-spam t
      spam-mark-ham-unread-before-move-from-spam-group t
      nnimap-split-rule 'nnimap-split-fancy
      ;; あなたの設定に追加する前に、これが何をするか理解せよ!
      nnimap-split-fancy '(|
                           ;; References を親まで辿って
                           ;; それらのグループを入れる。
                           (: gnus-registry-split-fancy-with-parent)
                           ;; これはサーバー側の SpamAssassin
                           ;; タグをつかまえる。
                           (: spam-split 'spam-use-regex-headers)
                           (any "ding" "ding")
                           ;; Spam 記事はディフォルトで
                           ;; spam に行くことに注意。
                           (: spam-split)
                           ;; ディフォルトのメールボックス。
                           "mail"))

     ;; G p で設定した私のパラメーター。

     ;; すべての nnml グループと、nnimap+mail.lifelogs.com:train
     ;; と nnimap+mail.lifelogs.com:spam を除いたすべての nnimap
     ;; グループでは、どの spam も nnimap トレーニングに行く。
     ;; それは手動で検出しなければならないから。

     ((spam-process-destination . "nnimap+mail.lifelogs.com:train"))

     ;; すべての NNTP グループ。
     ;; Spam を blacklist で、ham を BBDB で自動検出。
     ((spam-autodetect-methods spam-use-blacklist spam-use-BBDB)
     ;; すべての spam をトレーニンググループに送る。
      (spam-process-destination . "nnimap+mail.lifelogs.com:train"))

     ;; 私が spam を自動検出させたい、いくつかの NNTP グループ。
     ((spam-autodetect . t))

     ;; 私の nnimap nnimap+mail.lifelogs.com:spam グループ。

     ;; これは spam グループ。
     ((spam-contents gnus-group-spam-classification-spam)

      ;; どんな spam も私は ham 印を付けなければ
      ;; nnimap+mail.lifelogs.com:train に行く
      ;; (前述の gnus-spam-newsgroup-contents 設定により、すべての
      ;; まだ読まれたことが無いメッセージを読むとそうなる)。

      (spam-process-destination "nnimap+mail.lifelogs.com:train")

      ;; どんな ham も私の nnimap+mail.lifelogs.com:mail フォルダ
      ;; に行くが、私の nnimap+mail.lifelogs.com:trainham フォルダ
      ;; にもトレーニングのために行く。

      (ham-process-destination "nnimap+mail.lifelogs.com:mail"
                               "nnimap+mail.lifelogs.com:trainham")
      ;; このグループでは ! 印が付いているものだけが ham。
      (ham-marks
       (gnus-ticked-mark))
      ;; 出かける間際に blacklist に送信者を覚えさせる - これは明らかに
      ;; 不要で、単に私の鬱憤を晴らすためにあります。
      (spam-process (gnus-group-spam-exit-processor-blacklist)))

     ;; その後 IMAP サーバー上で、私は SpamAssassin が spam を
     ;; 認識するトレーニングのために train グループを、ham を認識
     ;; するトレーニングのために trainham グループを使います。でも
     ;; Gnus はそういうことはやってくれません。

サーバー上の IMAP サーバーで、統計的な濾過器と spam.el を使う
......................................

From Reiner Steib <reiner.steib@gmx.de>.

私のプロバイダは (IMAP) メールサーバー上で (DCC と連係した) bogofilter を稼働させています。認識された spam は spam.detected へ行き、残りには通常の濾過規則が適用される、 すなわち some.folder か INBOX に行きます。肯定の失敗あるいは否定のトレーニングは、training.ham または training.spam それぞれに記事をコピーするか移動させることによって行なわれます。サーバー上の cron ジョブが、それらを適切な ham または spam オプションとともに bogofilter に与え、training.ham および training.spam フォルダからそれらを削除します。

以下の gnus-parameters の項によって、spam.el はほとんどの仕事を私のためにこなします:

        ("nnimap:spam\\.detected"
         (gnus-article-sort-functions '(gnus-article-sort-by-chars))
         (ham-process-destination "nnimap:INBOX" "nnimap:training.ham")
         (spam-contents gnus-group-spam-classification-spam))
        ("nnimap:\\(INBOX\\|other-folders\\)"
         (spam-process-destination . "nnimap:training.spam")
         (spam-contents gnus-group-spam-classification-ham))

  * The Spam folder:

     spam.detected フォルダにおいて、私は肯定の失敗 (すなわち、 bogofilter か DCC が spam であると誤って判定した正当なメール) のチェックをしなければなりません。

     gnus-group-spam-classification-spam の項のために、すべてのメッセージには spam の印 ($) が付けられます。肯定に失敗したものを見つけたら、私は記事にいくつかの他の ham 印 (ham-marks, Spam ELisp Package Global Variables) を付けます。グループを出るとき、それらの記事は INBOX (私が記事を置いておきたいところ) と training.ham (bogofilter のトレーニング用) の両方のグループにコピーされ、spam.detected フォルダから削除されます。

     gnus-article-sort-by-chars の項は、私の失敗した肯定の検出を単純にします。私は、すべて似たサイズの、たくさんのワーム (sweN, ...) を受け取ります。それらをサイズ (つまり文字数) でまとめると、他の間違った肯定を見つけやすくなるのです。(もちろん厳密にはワームは spam (UCE, UBE) ではありません。ともあれ、それらの要らないメールを濾過するのに bogofilter は私にとって優秀な道具です。)

  * Ham folders:

     私の ham フォルダで、認識されなかった spam メール (否定の失敗) を見たときはいつでも、私は単に S x (gnus-summary-mark-as-spam) を叩きます。グループを出るとき、それらのメッセージは training.spam に移されます。

spam-report.el で Gmane グループの spam を報告する
.......................................

From Reiner Steib <reiner.steib@gmx.de>.

以下の gnus-parameters に納めた項目によって、S x (gnus-summary-mark-as-spam) で gmane.* グループの spam 記事に印を付け、グループを出るときに Gmane に報告します:

        ("^gmane\\."
         (spam-process (gnus-group-spam-exit-processor-report-gmane)))

加えて、私は news.gmane.org からではなくローカルニュースサーバー (leafnode) を通して記事を読んでいるので、 (setq spam-report-gmane-use-article-number nil) を使っています。つまり、記事番号が news.gmane.org におけるものと異なるので、正しい記事番号を見つけるために spam-report.el に X-Report-Spam ヘッダーを検査させなければなりません。

ブラックリストとホワイトリスト
...............

 -- Variable: spam-use-blacklist

     入ってくるメールを分割するときにブラックリストを使いたい場合は、この変数を t に設定して下さい。送信者がブラックリストに載っているメッセージは spam-split-group に送られます。これは、送信者が spammer であることが定義されているメールに対してだけ動作する、明示的な濾過器です。

 -- Variable: spam-use-whitelist

     入ってくるメールを分割するときにホワイトリストを使いたい場合は、この変数を t に設定して下さい。送信者がホワイトリストに載っていないメッセージは、次の spam-split 規則に送られます。これは、ホワイトリストに載っていない誰かのメッセージは spam とも ham とも見なされないことを意味する、明示的な濾過器です。

 -- Variable: spam-use-whitelist-exclusive

     送信者がホワイトリストに載っていないすべてのメッセージが spam だと見なされることを意味する暗黙の濾過器としてホワイトリストを使いたい場合は、この変数を t にして下さい。注意して使って下さい。

 -- Variable: gnus-group-spam-exit-processor-blacklist

     このシンボルを、グループパラメーターのカスタマイズによってグループの spam-process パラメーターに加えるか、または gnus-spam-process-newsgroups 変数に加えて下さい。このシンボルがグループの spam-process パラメーターに加えられると、spam 印が付いた記事の送信者がブラックリストに追加されます。

     警告

     廃れた gnus-group-spam-exit-processor-blacklist の代わりに、 (spam spam-use-blacklist) を使うことを推奨します。すべて同等に動作することは保証されます。

 -- Variable: gnus-group-ham-exit-processor-whitelist

     このシンボルを、グループパラメーターのカスタマイズによってグループの spam-process パラメーターに加えるか、または gnus-spam-process-newsgroups 変数に加えて下さい。このシンボルがグループの spam-process パラメーターに加えられると、ham 印が付いた ham グループの記事の送信者がホワイトリストに追加されます。

     警告

     廃れた gnus-group-ham-exit-processor-whitelist の代わりに、 (ham spam-use-whitelist) を使うことを推奨します。すべて同等に動作することは保証されます。

ブラックリストは、あなたが spam の送信者だと考えるアドレスに合致する正規表現のリストです。例えば vmadmin.com の誰からでも来るメールを阻止するには、あなたのブラックリストに vmadmin.com を入れて下さい。空のブラックリストで始めましょう。ブラックリストの各項目は Emacs の正規表現シンタックスを使います。

逆に、ホワイトリストは何のアドレスが正当だと考えられるかを告げます。ホワイトリストにあるアドレスからやって来たすべてのメッセージは、非-spam だと見なされます。BBDB Whitelists も見て下さい。ホワイトリストの各項目は Emacs の正規表現シンタックスを使います。

ブラックリストとホワイトリストのファイルの所在は、 spam-directory 変数 (ディフォルトは ~/News/spam) または直接 spam-whitelist と spam-blacklist 変数でカスタマイズすることができます。ホワイトリストとブラックリストのファイルは、ディフォルトでは spam-directory のディレクトリーにあり、それぞれ whitelist と blacklist という名前が付けられます。

BBDB ホワイトリスト
............

 -- Variable: spam-use-BBDB

     spam-use-whitelist (see Blacklists and Whitelists) に似ていますが、ホワイトリストのアドレスの源として、正規表現ではない BBDB を使います。spam-use-BBDB をちゃんと動作させるには BBDB を load しなければなりません。その送信者が BBDB に載っていないメッセージは、次の spam-split 規則に送られます。これは、BBDB に載っていない誰かのメッセージは spam とも ham とも見なされないことを意味する、明示的な濾過器です。

 -- Variable: spam-use-BBDB-exclusive

     送信者が BBDB に載っていないすべてのメッセージが spam だと見なされることを意味する暗黙の濾過器として BBDB を使いたい場合は、この変数を t にして下さい。注意して使って下さい。BBDB に載っている送信者だけが通行を許され、他のすべては spammers として分類されます。

     spam.el に関する限りは、spam-use-BBDB の別名とし
     て spam-use-BBDB-exclusive を使うことができますが、それは別のバックエンドではありません。spam-use-BBDB-exclusive を t に設定すれば、BBDB による分割はすべて排他的になります。

 -- Variable: gnus-group-ham-exit-processor-BBDB

     このシンボルを、グループパラメーターのカスタマイズによってグループの spam-process パラメーターに加えるか、または gnus-spam-process-newsgroups 変数に加えて下さい。このシンボルがグループの spam-process パラメーターに加えられると、ham 印が付いた ham グループの記事の送信者が BBDB に追加されます。

     警告

     廃れた gnus-group-ham-exit-processor-BBDB の代わりに、 (ham spam-use-BBDB) を使うことを推奨します。すべて同等に動作することは保証されます。

Gmane Spam 報告
.............

 -- Variable: gnus-group-spam-exit-processor-report-gmane

     グループパラメーターか変数 gnus-spam-process-newsgroups をカスタマイズして、このシンボルをグループの spam-process パラメーターに加えて下さい。これが加えられると、spam 印が付いた記事のグループが HTTP 経由で Gmane の管理者に報告されます。

     Gmane は http://gmane.org で見つけることができます。

     警告

     廃れた gnus-group-spam-exit-processor-report-gmane の代わりに、 (spam spam-use-gmane) を使うことを推奨します。すべて同等に動作することは保証されます。

 -- Variable: spam-report-gmane-use-article-number

     この変数はディフォルトで t です。あなた自身がニュースサーバーを運営している、すなわちローカルな記事番号が Gmane の記事番号と合わない場合は、nil に設定して下さい。 spam-report-gmane-use-article-number が nil であると、 spam-report.el は Gmane が提供する X-Report-Spam ヘッダーを使います。

非-spam Hashcash 印
.................

 -- Variable: spam-use-hashcash

     spam-use-whitelist (see Blacklists and Whitelists) に似ていますが、送信者のアドレスの代わりに、潔白なメッセージのための hashcash の印 (tokens) を使います。Hashcash 印が無いメッセージは次の spam-分割 (spam-split) 規則に送られます。これは hashcash 印が見当たらないメッセージは spam とも ham とも見なされないことを意味する、明示的な濾過器です。

ブラックホール
.......

 -- Variable: spam-use-blackholes

     このオプションはディフォルトで無効になっています。このオプションをセットすると、Gnus にブラックホール型の分散 spam 処理システム (例えば DCC) を調べさせることができます。変数 spam-blackhole-servers は、Gnus が意見を求めるブラックホール・サーバーのリストを持ちます。現在のリストはかなり広範囲に渡っていますが、もし時代遅れなサーバーを含んでいたら私たちに知らせるために、確認して下さい。

     ブラックホール・チェックは dig.el パッケージを使います。しかし spam-use-dig を nil に設定すれば、より良い性能のために dns.el を代わりに使うことを spam.el に指示することができます。現状では spam-use-dig を nil に設定することは、いく人かの利用者が使えないかもしれないので、それが可能な性能改善であるにもかかわらず推奨されません。しかし、それが動くかどうかを確かめることはできます。

 -- Variable: spam-blackhole-servers

     ブラックホール・チェックのために意見を求めるサーバーのリストです。

 -- Variable: spam-blackhole-good-server-regex

     ブラックホール・サーバーのリストと照合されてはならない IP の正規表現。 nil に設定されると無効です。

 -- Variable: spam-use-dig

     dns.el パッケージの代わりに dig.el パッケージを使います。ディフォルトの設定である t が推奨されます。

ブラックホール・チェックは入って来るメールに対してだけ行なわれます。ブラックホールに spam または ham プロセッサーはありません。

正規表現によるヘッダーの合致検査
................

 -- Variable: spam-use-regex-headers

     このオプションはディフォルトで無効になっています。このオプションをセットすると、Gnus に正規表現のリストとメッセージヘッダーを照合させることができます。変数 spam-regex-headers-spam および spam-regex-headers-ham が正規表現のリストを持ちます。メッセージが spam または ham かどうかを決めるために、Gnus はメッセージヘッダーのそれぞれを検査します。

 -- Variable: spam-regex-headers-spam

     メッセージヘッダーの中で一致した時に、それが明らかに spam であることを見分けるための正規表現のリストです。

 -- Variable: spam-regex-headers-ham

     メッセージヘッダーの中で一致した時に、それが明らかに ham であることを見分けるための正規表現のリストです。

正規表現によるヘッダーの検査は、入ってきたメールに対してだけ行なわれます。正規表現のために特有な spam または ham プロセッサーはありません。

Bogofilter
..........

 -- Variable: spam-use-bogofilter

     Eric Raymond の迅速な Bogofilter を spam-split に使用したい場合は、この変数をセットして下さい。

     Spam 記事だけの $ 印を関連付ける最小の世話によって、Bogofilter トレーニングはすべてかなり自動的になります。各カテゴリーの spam かそうでない数百の記事を入手するまで、これをやらなければなりません。概略モードにおけるデバッグのための、あるいは好奇心のための S t コマンドは、現在の記事の spamicity (訳注: spam 度?) スコア (0.0〜1.0) を表示します。

     Bogofilter は、ある一定の閾値に基づいて、メッセージが spam かどうかを見極めます。閾値はカスタマイズできます。Bogofilter のドキュメントを調べて下さい。

     Path に bogofilter の実行ファイルが無い場合、Bogofilter の処理は取り消されます。

     spam-use-bogofilter-headers を使う場合は、これを有効にしてはいけません。

 -- Variable: spam-use-bogofilter-headers

     メッセージヘッダーだけを調べるために Eric Raymond の迅速な Bogofilter を spam-split に使用したい場合は、この変数をセットして下さい。これは spam-use-bogofilter と同じように動作しますが、あらかじめ X-Bogosity ヘッダーがメッセージに存在しなければなりません。通常これは procmail の技法か、何かそれに似たもので行なうことになるでしょう。Bogofilter のインストールに関する文書を調べて下さい。

     spam-use-bogofilter を使う場合は、これを有効にしてはいけません。

 -- Variable: gnus-group-spam-exit-processor-bogofilter
     このシンボルを、グループパラメーターのカスタマイズによってグループの spam-process パラメーターに加えるか、または gnus-spam-process-newsgroups 変数に加えて下さい。このシンボルがグループの spam-process パラメーターに加えられると、spam 印が付いた記事が bogofilter の spam データベースに加えらます。

     警告

     廃れた gnus-group-spam-exit-processor-bogofilter の代わりに、 (spam spam-use-bogofilter) を使うことを推奨します。すべて同等に動作することは保証されます。

 -- Variable: gnus-group-ham-exit-processor-bogofilter
     このシンボルを、グループパラメーターのカスタマイズによってグループの spam-process パラメーターに加えるか、または gnus-spam-process-newsgroups 変数に加えて下さい。このシンボルがグループの spam-process パラメーターに加えられると、ham 印が付いた ham グループの記事が非-spam 記事用の Bogofilter データベースに追加されます。

     警告

     廃れた gnus-group-ham-exit-processor-bogofilter の代わりに、 (ham spam-use-bogofilter) を使うことを推奨します。すべて同等に動作することは保証されます。

 -- Variable: spam-bogofilter-database-directory

     これは Bogofilter がそのデータベースを格納するディレクトリーです。ディフォルトでは設定されていないので、Bogofilter はそれ自身のディフォルトのデータベース・ディレクトリーを使います。

Bogofilter のメール分類器は、意図と目的の点で ifile に似ています。Spam と ham のプロセッサーが提供され、加えて spam-分割 (spam-split) にも Bogofilter が使われるべきであること、またはすでに記事に使われたことを示す spam-use-bogofilter および spam-use-bogofilter-headers 変数が提供されます。この機能を検査するために Bogofilter のバージョン 0.9.2.1 が使われました。

SpamAssassin back end
.....................

 -- Variable: spam-use-spamassassin

     spam-split に SpamAssassin を使いたい場合は、この変数をセットして下さい。

     SpamAssassin は、ベイジアンフィルタを内包する規則と分析のセットに基づいて、それぞれの記事のスコアを裁定します。ベイジアンフィルタは、spam 記事の $ 印を関連させることにより訓練することができます。Spam のスコアは、概略モードで S t コマンドを使うことによって見ることができます。

     この変数をセットすると、それぞれの記事は spam-split が呼ばれるときに SpamAssassin によって処理されます。メールが SpamAssassin で処理されるようになっている場合に、単に SpamAssassin ヘッダーを使いたいのならば、代わりに spam-use-spamassassin-headers をセットして下さい。

     spam-use-spamassassin-headers を使う場合、これを有効にしてはいけません。

 -- Variable: spam-use-spamassassin-headers

     メールが SpamAssassin で処理されるようになっている場合に、 SpamAssassin ヘッダーに基づいて spam-split に分割を行なわせたいのならば、この変数をセットして下さい。

     spam-use-spamassassin を使う場合、これを有効にしてはいけません。

 -- Variable: spam-spamassassin-path

     この変数は SpamAssassin の実行形式を指します。spamd を稼働しているならば、より速い処理のために、この変数に spamc の実行形式を設定することができます。spamd/spamc の更なる情報は、 SpamAssassin のドキュメントを見て下さい。

SpamAssassin は、spam を同定するために広範な分析を行なう、強力で融通性のある spam 濾過器です。SpamAssassin が提供する ham と spam のプロセッサーを使うか、あるいはすでにそれらが記事に適用済みかどうかを、 spam-use-spamassassin と spam-use-spamassassin-headers 変数で spam-split に指示します。この機能を検査するために SpamAssassin のバージョン 2.63 が使われました。

ifile による spam の濾過
..................

 -- Variable: spam-use-ifile

     Bogofilter に似た統計分析器である ifile を spam-split に使いたい場合は、この変数を有効にして下さい。

 -- Variable: spam-ifile-all-categories

     spam-use-ifile に、単なる spam/非-spam ではなくて ifile のすべてのカテゴリーを与えてもらいたいならば、この変数を有効にして下さい。これを使う場合は、その文献に書かれているように ifile をトレーニングしておかなければなりません。

 -- Variable: spam-ifile-spam-category

     ifile に関する限り、これは spam メッセージのカテゴリーです。実際に使われる文字列は無関係ですが、たぶんあなたは spam の値を残しておきたいでしょう。

 -- Variable: spam-ifile-database-path

     これは ifile データベースのファイル名です。ディフォルトでは定義されていないので、ifile はそれ自身のディフォルトのデータベース名を使います。

ifile のメール分類器は、意図と目的の点で Bogofilter に似ています。 Spam と ham のプロセッサー、それに spam-分割 (spam-split) に ifile が使われるべきであることを示す spam-use-ifile 変数を提供します。この機能を検査するために ifile のバージョン 1.2.1 が使われました。

spam-統計 (spam-stat) による spam の濾過
................................

See Filtering Spam Using Statistics with spam-stat.

 -- Variable: spam-use-stat

     Emacs Lisp による統計分析器である spam-stat.el を spam-split に使わせたいならば、この変数を有効にして下さい。

 -- Variable: gnus-group-spam-exit-processor-stat
     このシンボルを、グループパラメーターのカスタマイズによってグループの spam-process パラメーターに加えるか、または gnus-spam-process-newsgroups 変数に加えて下さい。このシンボルがグループの spam-process パラメーターに加えられると、spam 印が付いた記事が spam 記事用の spam-stat データベースに追加されます。

     警告

     廃れた gnus-group-spam-exit-processor-stat の代わりに、 (spam spam-use-stat) を使うことを推奨します。すべて同等に動作することは保証されます。

 -- Variable: gnus-group-ham-exit-processor-stat
     このシンボルを、グループパラメーターのカスタマイズによってグループの spam-process パラメーターに加えるか、または gnus-spam-process-newsgroups 変数に加えて下さい。このシンボルがグループの spam-process パラメーターに加えられると、ham 印が付いた ham グループの記事が非-spam 記事用の spam-stat データベースに追加されます。

     警告

     廃れた gnus-group-ham-exit-processor-stat の代わりに、 (ham spam-use-stat) を使うことを推奨します。すべて同等に動作することは保証されます。

これは spam.el が spam-stat.el と働き合うことを可能にします。spam-stat.el は (Lisp だけの) spam 内部データベースを提供しますが、それは ifile や Bogofilter と違って外部プログラムを必要としません。 Spam と ham のプロセッサーと spam-split のための spam-use-stat 変数が提供されます。

Gnus で SpamOracle を使うには
.......................

気軽に spam を濾過する一つのやり方は SpamOracle を使うことです。統計的にメールを濾過するための道具である SpamOracle は、Xavier Leroy によって書かれました。これは別にインストールする必要があります。

Gnus で SpamOracle を使うには、いくつかのやり方があります。すべての場合に、メールは mark モードで動作している SpamOracle にパイプされます。すると SpamOracle は、そのメールを spam だと見なしたかどうかを示す X-Spam ヘッダーを記入します。

実現可能な一つは、SpamOracle を :prescript として Mail Source Specifiers から走らせることです。この方法には、利用者が X-Spam ヘッダーを見ることができるという利点があります。

もっとも手軽な方法は、spam.el (see Filtering Spam Using The Spam ELisp Package) が SpamOracle を呼ぶようにすることです。

spam.el が SpamOracle を使えるようにするには、変数 spam-use-spamoracle を t にして、Filtering Spam Using The Spam ELisp Package の項で述べられているように nnmail-split-fancy か nnimap-split-fancy を設定して下さい。この例では nnimap サーバーの INBOX が SpamOracle によって濾過されます。Spam だと見なされたメールは spam-split-group、この場合は Junk に移動させられます。Ham なメッセージは INBOX に残ります:

     (setq spam-use-spamoracle t
           spam-split-group "Junk"
           nnimap-split-inbox '("INBOX")
           nnimap-split-rule 'nnimap-split-fancy
           nnimap-split-fancy '(| (: spam-split) "INBOX"))

 -- Variable: spam-use-spamoracle
     Gnus に SpamOracle を使って spam の濾過をさせたい場合に t にして下さい。

 -- Variable: spam-spamoracle-binary
     Gnus は利用者の PATH で見つかった spamoracle という SpamOracle のバイナリを使います。これにはカスタマイズ可能な変数 spam-spamoracle-binary を使います。

 -- Variable: spam-spamoracle-database
     SpamOracle はその解析結果をデータベースとして格納するために、ディフォルトで ~/.spamoracle.db ファイルを使います。これは変数 spam-spamoracle-database で制御され、ディフォルトは nil です。それは、ディフォルトの SpamOracle データベースが使われることを意味します。データベースがどこか特別な場所にある場合は、 spam-spamoracle-database をそのパスに設定して下さい。

SpamOracle はメッセージが spam か ham かを見極めるために統計的な手法を使います。間違いや見逃しの少ない良い結果を得るために、SpamOracle はトレーニングを必要とします。SpamOracle は spam メールの特徴を学びます。 add モード (トレーニング・モード) を使って、良いメール (ham) と spam を SpamOracle に与えなければなりません。これは、概略バッファーで | を押すことによってメールを SpamOracle のプロセスにパイプするか、または spam.el の spam および ham プロセッサーを使うことによって行なうことができます、see Filtering Spam Using The Spam ELisp Package.

 -- Variable: gnus-group-spam-exit-processor-spamoracle
     このシンボルを、グループパラメーターのカスタマイズによってグループの spam-process パラメーターに加えるか、または gnus-spam-process-newsgroups 変数に加えて下さい。このシンボルがグループの spam-process パラメーターに加えられると、spam 印が付いた記事が spam のサンプルとして SpamOracle に送られます。

     警告

     廃れた gnus-group-spam-exit-processor-spamoracle の代わりに、 (spam spam-use-spamoracle) を使うことを推奨します。すべて同等に動作することは保証されます。

 -- Variable: gnus-group-ham-exit-processor-spamoracle
     このシンボルを、グループパラメーターのカスタマイズによってグループの spam-process パラメーターに加えるか、または gnus-spam-process-newsgroups 変数に加えて下さい。このシンボルがグループの spam-process パラメーターに加えられると、 ham グループにある ham 印が付いた記事が ham の記事のサンプルとして SpamOracle に送られます。

     警告

     廃れた gnus-group-ham-exit-processor-spamoracle の代わりに、 (ham spam-use-spamoracle) を使うことを推奨します。すべて同等に動作することは保証されます。

例: これらは ham グループとして分類された、つまり ham の記事しかないグループのグループパラメーターです。

      ((spam-contents gnus-group-spam-classification-ham)
       (spam-process ((ham spam-use-spamoracle)
                      (spam spam-use-spamoracle))))

このグループでは spam-use-spamoracle が ham と spam 両方の処理を行ないます。このグループに spam 記事があって (SpamOracle が十分なサンプルを食べさせてもらっていなければ、そうなりますね)、かつ利用者がいくつかの記事に spam の印を付けたならば、それらの記事は SpamOracle によって処理されます。そのプロセッサーは、新しい spam のサンプルとして SpamOracle に記事を送ります。

Spam ELisp パッケージの拡張
...................

新しいバックエンド blackbox を追加したいあなたは、入ってくるメールを濾過するために以下を用意して下さい:

 1. コード

          (defvar spam-use-blackbox nil
            "Blackbox を使うときは t にする。")

     Blackbox が、入ってくるメールを検査できるのであれば、 spam-check-blackbox を書いて下さい。

     Blackbox が spam と ham を register/unregister できるのであれば、手始めに、bogofilter の register/unregister ルーチンか、より Blackbox にふさわしい他の restister/unregister ルーチンを使って spam-blackbox-register-routine および spam-blackbox-unregister-routine を書いて下さい。

 2. 関数

     spam-check-blackbox 関数は、他の習慣に倣って nil か spam-split-group を返さなければなりません。あなたにできることの例は、既存の spam-check-* 関数を参照して下さい。また、あなたがそうでない理由を完全に理解していないならば、テンプレートに齧り付いて下さい。

Spam と ham メッセージを処理するには、以下を用意して下さい:

 1. コード

     Spam または ham のプロセッサーを用意する必要はありません。 Blackbox が spam または ham の処理をサポートする場合だけ、それらを用意して下さい。

     さらに ham と spam のプロセッサーは単一の変数ではなくされつつあり、代わりに (spam spam-use-blackbox) または (ham spam-use-blackbox) の形式が推奨されます。今のところ spam/ham プロセッサー変数はまだあちこちにありますが、長くはありません。

          (defvar gnus-group-spam-exit-processor-blackbox "blackbox-spam"
            "概略を出るときに呼ばれる blackbox の spam プロセッサー。
          Spam グループだけに適用される。")

          (defvar gnus-group-ham-exit-processor-blackbox "blackbox-ham"
            "概略を出るときに呼ばれる blackbox の ham プロセッサー。
          Spam ではない (未分類または ham) グループだけに適用される。")

 2. Gnus のパラメーター

     gnus.el にあるグループパラメーター spam-process に

          (const :tag "Spam: Blackbox" (spam spam-use-blackbox))
          (const :tag "Ham: Blackbox"  (ham spam-use-blackbox))

     を加えて下さい。それをパラメーターと変数のカスタマイズの二回について行なうことを確かめて下さい。

     Blackbox が、入ってくるメールが spam かどうかを検査できるのであれば、

          (variable-item spam-use-blackbox)

     を gnus.el のグループパラメーター spam-autodetect-methods に加えて下さい。

     最後に、spam.el にある、適切な spam-install-*-backend 関数を使って下さい。利用できる関数は次の通りです。

      1. spam-install-backend-alias

          この関数は、オリジナルのバックエンドとすべてが似たバックエンドの別名を用意します。今のところ、これは spam-use-BBDB-exclusive を spam-use-BBDB のように働かせるためだけに使われます。

      2. spam-install-nocheck-backend

          この関数は、検査する機能は無いが ham または spam を register/unregister することができるバックエンドを用意します。 spam-use-gmane がそのようなバックエンドです。

      3. spam-install-checkonly-backend

          この関数は、入ってくるメールが spam かどうかの検査だけを行なうことができるバックエンドを用意します。それはメッセージを register または unregister することができません。spam-use-blackholes および spam-use-hashcash がそのようなバックエンドです。

      4. spam-install-statistical-checkonly-backend

          この関数は、入ってくるメールの検査だけを行なうことができる、統計処理を行なうバックエンド (検査のためにメッセージの本文全体を必要とする) を用意します。spam-use-regex-body がそのような濾過器です。

      5. spam-install-statistical-backend

          この関数は、入ってくるメールの検査と registration/unregistration ルーチンを持つ、統計処理を行なうバックエンドを用意します。 spam-use-bogofilter は、そのように仕立てられています。

      6. spam-install-backend

          これは最も普通なバックエンドを用意します。それは検査とメッセージの register/unregister を行なうことができ、統計処理の能力はありません。 spam-use-BBDB がそのようなバックエンドです。

      7. spam-install-mover-backend

          移動させる (Mover) バックエンドは、概略バッファーを出るときに spam.el の内部で、ある一定のやり方で記事を移動させます。おそらく、そのようなバックエンドは、あまりインストールしないでしょう。

Spam の濾過に spam-stat による統計を使う
----------------------------

Paul Graham は、統計を使った spam の濾過に関する優れたエッセイを書きました: A Plan for Spam (http://www.paulgraham.com/spam.html)。そこで彼は SpamAssassin によって使われているようなルールベースの濾過に固有な欠陥について述べています。例えば: 誰かがルールを書かなければならないし、他のすべての人はこれらのルールをインストールしなければなりません。あなたはいつも遅れをとってしまいます。それよりも、それが spam または非-spam に何となく似ているかどうかに基づいてメールを濾過するほうがはるかに良いだろうと彼は主張します。これを測定する一つの手段は単語の分布です。その後彼は、新着メールがあなたの他の spam メールに似ているかどうかをチェックする方法の記述に進みます。

基本的な案はこれです: あなたのメールの二つのコレクションを作ります。一つは spam、もう一つは非-spam で。両方のコレクションにおける各単語の出現頻度を数えて、コレクションのメールの総数で重み付けを行ない、この情報を辞書に格納します。新着メールのすべての単語について、spam か非-spam メールに属する確率を決定します。15 の最も顕著な単語を使って、そのメールが spam であることの確率の総計を計算します。この確率がある閾値より高かったら、そのメールは spam であると考えられます。

Gnus はこの種の濾過をサポートします。しかしそれにはいくつかの設定が必要です。第一に、あなたのメールの二つのコレクションが要ります。一つは spam、もう一つは非-spam で。そして、それらの二つのコレクションを使って辞書を作り、それをセーブして下さい。そして特に最後に、あなたの特級分割の規則でこの辞書を使って下さい。

spam-統計 (spam-stat) 辞書を作る
.........................

統計に基づいた spam 濾過を始めるには、あなたは二つのメールのコレクションに基づいた統計を作らなければなりません。一つは spam もう一つは非-spam で。そしてそれらの統計は、後で利用するために辞書に格納されます。それらの統計を意味のあるものにするために、両方のコレクションにつき数百通のメールが必要です。

今のところ Gnus は nnml バックエンドでだけ辞書の自動生成をサポートします。 nnml バックエンドは一通のメールにつき一つのファイルで、すべてのメールをディレクトリーに格納します。以下を使って下さい。

 -- Function: spam-stat-process-spam-directory
     このディレクトリーにあるすべてのファイルについて spam の統計を生成します。すべてのファイルは一つの spam メールとして扱われます。

 -- Function: spam-stat-process-non-spam-directory
     このディレクトリーにあるすべてのファイルについて非-spam の統計を生成します。すべてのファイルは一つの spam ではないメールとして扱われます。

普通は ~/Mail/mail/spam のようなディレクトリー (通常 nnml:mail.spam グループに対応) に対して spam-stat-process-spam-directory を呼ぶでしょう。また ~/Mail/mail/misc のようなディレクトリー (通常 nnml:mail.misc グループに対応) に対して spam-stat-process-non-spam-directory を呼ぶでしょう。

あなたが IMAP を使っているならメールをローカルには持っていないので、それは動かないでしょう。一つの解決策は、Gnus エージェントで記事をキャッシュすることです。そうすれば spam-stat-process-spam-directory として "~/News/agent/nnimap/mail.yourisp.com/personal_spam" のようなものが使えます。See Agent as Cache.

 -- Variable: spam-stat
     この変数はすべての統計のハッシュテーブル---辞書と言っているもの---を持ちます。このハッシュテーブルは、双方のコレクションのすべての単語について spam および非-spam メールにおける出現頻度を表すベクトルを格納します。

統計を最初から作り直したいときは、辞書をリセットする必要があります。

 -- Function: spam-stat-reset
     spam-stat ハッシュテーブルをリセットし、すべての統計を削除します。

行なったら辞書をセーブしなければなりません。辞書はかなり大きくなるかもしれません。辞書を追加更新しない場合 (言い換えると、例えば毎月一回作り直す場合)、頻繁に現れないか、または spam か非-spam のどちらに属するかがはっきりしないすべての単語を削除することによって、辞書のサイズを小さくすることができます。

 -- Function: spam-stat-reduce-size
     辞書のサイズを小さくします。これは辞書を追加更新したくない場合だけ使って下さい。

 -- Function: spam-stat-save
     辞書をセーブします。

 -- Variable: spam-stat-file
     辞書の格納に使うファイル名です。ディフォルトは ~/.spam-stat.el です。

spam-統計 (spam-stat) を使ってメールを分割する
................................

spam-stat を使ってメールを分割するために、~/.gnus.el ファイルに以下を追加する必要があります。

     (require 'spam-stat)
     (spam-stat-load)

これは必要な Gnus のコードとあなたが作った辞書を load します。

次に、特級分割の規則を適合させる必要があります: どうやって spam-stat を使うかを決めて下さい。以下の例は nnml バックエンド用です。nnimap バックエンドでもまったく同様に動作します。単に nnmail-split-fancy の代わりに nnimap-split-fancy を使って下さい。

では mail.misc と mail.spam の二つのグループだけがある最も単純な事例ではどうなるか。以下の式はメールが spam であるか、またはそれが mail.misc に行くべきだと言っています。もし spam だったら spam-stat-split-fancy は mail.spam を返します。

     (setq nnmail-split-fancy
           `(| (: spam-stat-split-fancy)
               "mail.misc"))

 -- Variable: spam-stat-split-fancy-spam-group
     Spam 用のグループです。ディフォルトは mail.spam です。

特定の表題を持つメールを他のグループに入れる濾過をも行ないたいならば、以下の式を使って下さい。正規表現に合致しないメールだけを spam かもしれないと考えます。

     (setq nnmail-split-fancy
           `(| ("Subject" "\\bspam-stat\\b" "mail.emacs")
               (: spam-stat-split-fancy)
               "mail.misc"))

最初に spam の濾過をしたい場合、辞書を作るときに十分に注意しなければなりません。 spam-stat-split-fancy は mail.emacs と mail.misc のどちらのメールも非-spam であると解釈しなければならないので、辞書を作るときの非-spam コレクションに両方とも入っていなければならないことに注意して下さい。

     (setq nnmail-split-fancy
           `(| (: spam-stat-split-fancy)
               ("Subject" "\\bspam-stat\\b" "mail.emacs")
               "mail.misc"))

これを伝統的な濾過と組み合わせることもできます。ここではすべての HTML だけのメールを mail.spam.filtered グループに入れるものとしましょう。 spam-stat-split-fancy はそれらのメールを見ないので、辞書を作るときに、mail.spam.filtered のメールが spam または非-spam コレクションのどちらにも入るべきではないことに注意して下さい!

     (setq nnmail-split-fancy
           `(| ("Content-Type" "text/html" "mail.spam.filtered")
               (: spam-stat-split-fancy)
               ("Subject" "\\bspam-stat\\b" "mail.emacs")
               "mail.misc"))

spam-統計 (spam-stat) 辞書への低階層インターフェース
...................................

spam-stat を使うための主インターフェースは以下の関数です:

 -- Function: spam-stat-buffer-is-spam
     Spam であると考えられる新着メールがあるバッファーで呼ばれます。処理前の新着メールに対して使って下さい。

 -- Function: spam-stat-buffer-is-no-spam
     非-spam であると考えられる新着メールがあるバッファーで呼ばれます。処理前の新着メールに対して使って下さい。

 -- Function: spam-stat-buffer-change-to-spam
     Spam ではない通常のメールだとはもはや考えられないメールがあるバッファーで呼ばれます。すでに非-spam であるものとして処理されてしまったメールの地位の変更に使って下さい。

 -- Function: spam-stat-buffer-change-to-non-spam
     通常のメールではない spam だとはもはや考えられないメールがあるバッファーで呼ばれます。すでに spam であるものとして処理されてしまったメールの地位の変更に使って下さい。

 -- Function: spam-stat-save
     ハッシュテーブルをファイルにセーブします。変数 spam-stat-file で設定されたファイル名が使われます。

 -- Function: spam-stat-load
     ハッシュテーブルをファイルから load します。変数 spam-stat-file で設定されたファイル名が使われます。

 -- Function: spam-stat-score-word
     単語の spam スコアを返します。

 -- Function: spam-stat-score-buffer
     バッファーの spam スコアを返します。

 -- Function: spam-stat-split-fancy
     特級メール分割のためにこの関数を使って下さい。 nnmail-split-fancy に規則 (: spam-stat-split-fancy) を追加します。

それを使う前に、必ず辞書が load されているようにして下さい。これには ~/.gnus.el ファイルに以下が必要です:

     (require 'spam-stat)
     (spam-stat-load)

代表的なテストは以下の関数呼出しを必要とします:

     Reset: (setq spam-stat (make-hash-table :test 'equal))
     Learn spam: (spam-stat-process-spam-directory "~/Mail/mail/spam")
     Learn non-spam: (spam-stat-process-non-spam-directory "~/Mail/mail/misc")
     Save table: (spam-stat-save)
     File size: (nth 7 (file-attributes spam-stat-file))
     Number of words: (hash-table-count spam-stat)
     Test spam: (spam-stat-test-directory "~/Mail/mail/spam")
     Test non-spam: (spam-stat-test-directory "~/Mail/mail/misc")
     Reduce table size: (spam-stat-reduce-size)
     Save table: (spam-stat-save)
     File size: (nth 7 (file-attributes spam-stat-file))
     Number of words: (hash-table-count spam-stat)
     Test spam: (spam-stat-test-directory "~/Mail/mail/spam")
     Test non-spam: (spam-stat-test-directory "~/Mail/mail/misc")

辞書を生成する方法:

     Reset: (setq spam-stat (make-hash-table :test 'equal))
     Learn spam: (spam-stat-process-spam-directory "~/Mail/mail/spam")
     Learn non-spam: (spam-stat-process-non-spam-directory "~/Mail/mail/misc")
     Repeat for any other non-spam group you need...
     Reduce table size: (spam-stat-reduce-size)
     Save table: (spam-stat-save)

他のモードとの相互作用
===========

Dired
-----

gnus-dired-minor-mode は dired バッファーで使えるいくつかの便利な機能を提供します。これは次の式で有効になります:

     (add-hook 'dired-mode-hook 'turn-on-gnus-dired-mode)

C-c C-m C-a
     Dired で印を付けたものを添付ファイルとして送信します (gnus-dired-attach)。Message バッファーで確認を求められます。

C-c C-m C-l
     適切な mailcap 項目に従ってファイルを開きます (gnus-dired-find-file-mailcap)。接頭引数を付けると、ファイルを新しいバッファーで開きます。

C-c C-m C-p
     mailcap 項目に従ってファイルを印刷します (gnus-dired-print)。印刷コマンドが無い場合は PostScript 画像に印刷します。

いろいろのいろいろ
=========

gnus-home-directory
     すべての Gnus のファイル名とディレクトリー名の変数は、これによって初期化されます。ディフォルト値は ~/ です。

gnus-directory
     Gnus が格納するたくさんのファイル名とディレクトリー名の変数は、これによって初期化されます。ディフォルト値は SAVEDIR 環境変数の値か、その変数が設定されていない場合は ~/News/ です。

     ~/.gnus.el ファイルが読まれたときは Gnus のほとんどはすでに読み込まれているということに注意して下さい。これはつまり、この変数を ~/.gnus.el の中で設定しても、この変数によって初期化される他のディレクトリー変数は正しく設定されないだろうということです。この変数は代わりに .emacs で設定して下さい。

gnus-default-directory
     上記の変数にはまったく関係ありません---この変数はすべての Gnus バッファーのディフォルトディレクトリーをどうすべきかを設定します。もし C-x C-f のような命令を実行すると、現在のバッファーのディフォルトディレクトリーを起点にしたプロンプトが出てくるでしょう。

     この変数が nil (これがディフォルト値) であれば、Gnus を起動したときにあなたがいたバッファーのディフォルトディレクトリーがディフォルトディレクトリーになるでしょう。

gnus-verbose
     この変数は 0 から 10 まで間の整数です。大きい数値ほどたくさんのメッセージが表示されます。この変数が 0 であれば Gnus は何のメッセージも見せません。これが 7 (ディフォルト値) であれば特に重要なメッセージが表示され、 10 であれば Gnus は決してお喋りを止めず、たくさんのメッセージであなたにめまいを起こさせるでしょう。

gnus-verbose-backends
     この変数は gnus-verbose と同様に動作しますが、Gnus 本体ではなく Gnus のバックエンドに対して適用されます。

nnheader-max-head-length
     バックエンドが記事のヘッダーをまっすぐ読んでいるときは、できる限り少ない量だけを読もうと努力します。この変数 (ディフォルト値 4096) は、バックエンドがヘッダーと本文の間の区切り行を見つけるまでに読み込もうとする絶対最大長を指定します。この変数が nil であれば、読み込み上限はありません。もし t であれば、バックエンドは記事を部分部分で読み込もうとはせず、記事全体を読み込みます。これは ange-ftp や efs のあるバージョンで意味をもちます。

nnheader-head-chop-length
     この変数 (ディフォルト値 2048) は、前記の操作を行なっているときに、どれくらいの大きさの単位で各記事を読み込むかを設定します。

nnheader-file-name-translation-alist
     これはファイル名の文字をどのように変換するかを指定する連想リストです。例えば、もし : があなたのシステムではファイル名の文字としては使えない場合 (あなたは OS/2 利用者です)、以下のようにすることができます。

          (setq nnheader-file-name-translation-alist
                '((?: . ?_)))

     実際には、これは OS/2 と (くそ) MS Windows システム上でのこの変数のディフォルト値です。

gnus-hidden-properties
     これは ``不可視'' テキストを隠すために使われる属性のリストです。ほとんどのシステムではディフォルト値は (invisible t intangible t) で、これは不可視テキストを見えなくしてさわれなくします。

gnus-parse-headers-hook
     ヘッダーを解釈する前に呼び出されるフック。これは例えば、取得したヘッダーの統計情報を取るとか、あるいはある種のヘッダーを取り除くことに使うことができます。まあ、私は何でこんなものが欲しいかよくわかんないんだけどね。

gnus-shell-command-separator
     二つのシェル命令を区切るのに使用される文字列。ディフォルト値は ; です。

gnus-invalid-group-regexp

     利用者にグループ名を確認するときに使う、``使えない'' グループ名に合致する正規表現です。既定値は Gnus の内部動作 (選択方法とグループの境界に、通常 : を使っている) をめちゃめちゃにしてしまうかもしれない、いくつかの 本当に 使えないグループ名を捕まえます。

     IMAP 利用者はグループ名に / を使いたいと思うでしょうけれど。

終わり
***

はい、以上がマニュアルです---あなたはもう自分自身の人生を送ることができます。連絡をとって下さい。あなたの猫によろしく伝えて下さい。

おお、神よ---さよならを耐えることはできません。(すすり泣き。)

Ol' Charles Reznikoff はそれを非常によく現しているので、ここは彼のために譲ります:

     Te Deum

     Not because of victories

     I sing,

     having none,

     but for the common sunshine,

     the breeze,

     the largess of the spring.

     Not for victory

     but for the day's work done

     as well as I was able;

     not for a seat upon the dais

     but at the common table.

試訳:

     Te Deum

     勝利したからではなく

     私は歌う

     何も無いけれど

     あの日光や

     息吹や

     春の大きさのために

     勝利のためではなく

     一日の労働のために

     また、それを達成できたことに

     高座の上の席のためではなく

     普通のテーブルのところで

付録
**

XEmacs
======

XEmacs はパッケージの蒐集として配布されています。Gnus の XEmacs パッケージが必要とするものは何であれ、あなたはインストールすべきです。今のところ必要なのは gnus, mail-lib, xemacs-base, eterm, sh-script, net-utils, os-utils, dired, mh-e, sieve, ps-print, w3, pgg, mailcrypt, ecrypto および sasl です。

歴史
==

GNUS は梅田政信氏によって書かれました。1994年の夏が忍び寄ってくるころ、退屈していたラルス・マッグヌ・イングブリグットスン (Lars Magne Ingebrigtsen) は Gnus を書き直そうと決心しました。

この無礼を行なった人物を調べてみたいのなら、あなたの (くそ!) ウェブブラウザーを http://quimby.gnus.org/ に向けることができます。これは新しくて粋な版の Gnus の第一配布場所で、Newsrc をぶっ壊して人々を激怒させるサイトとして知られています。

最初のアルファ版の開発期間に、新しい Gnus は ``(ding) Gnus'' と呼ばれていました。(ding) はもちろん、ding is not Gnus の短縮形で、これはまったく完全な嘘ですが、だれがそんなことを気にするでしょうか? (ところで、この短縮形の ``Gnus'' はおそらく梅田さんの意図通り ``ニュース'' と発音されるべきで、そうするともっと適切な名前になります。そう思いませんか?)

どちらにせよ、すべてのエネルギーを新しい元気の良い名前を付けるのに使い果たした後、その名前は あまりに 元気が良すぎるということになり、それを ``Gnus'' と再び命名しました。でも、今回は大文字と小文字を混ぜています。``Gnus'' と ``GNUS'' です。新しいもの と 古いもの。

Gnus Versions
-------------

最初の ``適切な'' Gnus 5 のリリースは 1995年11月に Emacs 19.30 の配布に含まれたときになされました (132 の (ding) Gnus のリリース 足すことの Gnus5.0 の 15 リリース)。

1996年3月に次の世代の Gnus (別名 ``September Gnus'' (99 リリースの後で)) が ''Gnus 5.2`` という名前でリリースされました (40 リリース)。

1996年の 7月28日に Red Gnus の作業が始まり、それは 1997年1月25日に (84 リリースの後で) ``Gnus 5.4'' としてリリースされました (67 リリース)。

1997年9月13日に、Quassia Gnus が開始され、37 リリース続きました。それは ``Gnus 5.6'' として 1998年3月8日にリリースされました (46 リリース)。

1998年8月29日に Gnus 5.6 から Pterodactyl Gnus が生まれ、1999年12月3日に (99 リリースと CVS リポジトリでの作業の後) ``Gnus 5.8'' としてリリースされました。

2000年10月26日に Oort Gnus が開始されました。

もし接頭引数を持った版の Gnus---``(ding) Gnus'', ``September Gnus'', ``Red Gnus'', ``Quassia Gnus'', ``Pterodactyl Gnus'', ``Oort Gnus''---に出会っても、混乱しないで下さい。あなたが恐がっていることを知られてはいけません。後ろに下がりなさい。ゆっくりと。他に何をしても、走ってはいけません。それが届かくなるまで、静かに歩き去りなさい。適切にリリースされた版の Gnus を見つけて、代わりにそれに寄り添って下さい。

他の Gnus のバージョン
--------------

Lars さんが調製してリリースした Gnus に加えて、日本では Semi-gnus の開発が行なわれています。これは SEMI という MIME の機能を実現するためのライブラリを使うことを前提としています。

これらの Gnus は、主に Gnus 5.6 と Pterodactyl Gnus を元にしています。それらは ``Semi-gnus'' と総称され、T-gnus, Nana-gnus および Chaos の異なった系統があります。これらは強力な MIME の機能と各国語対応の機能を提供するもので、特に日本人の利用者にとって大事なものです。

なぜ?
---

Gnus の目的は何ですか?

私は、あなたの考え付くことをすべてできる ``すばらしい'' ``かっこいい'' ``いかす'' ``はやりの'' ニュースリーダを提供したいと思います。これは私の大元の動機ですが、Gnus の作業をしている間に、この世代のニュースリーダーは本当に石器時代に属しているということが明らかになりました。ニュースリーダーは、インターネットの幼児期からほとんど発展していませんでした。もし現在の増加率で量が増加しつづければ、すべての現在のニュースリーダーはまったく役に立たなくなるでしょう。一日に 1000 やもっとたくさんの新しい記事のあるニュースグループを扱うにはどうすれば良いのでしょう? 投稿をする百万やそれより多い人々に遅れないように付いていくにはどうすれば良いのでしょう?

Gnus はこれらの質問に本当の解決を提案しますが、私は Gnus がニュースを読み、取得するための新しい方法を実験する場として使われて欲しいです。梅田さんのニュースリーダーをバックエンドから分離するという賢明な方針を拡張することによって、Gnus はメールを取得したり、違ったところからニュースを取得するための新しいバックエンドを書きたい人のために、簡単で単純なインターフェースを提供しています。私は、役に立つであろうという部分にすべて、カスタマイズのためのフックを加えました。それをすることによって、探検し、発明したいすべての人を招いているのです。

おそらく Gnus は完成することはないのかもしれません。 C-u 100 M-x all-hail-emacs と C-u 100 M-x all-hail-xemacs です。

互換性
---

Gnus は GNUS と完全に互換性があるように設計されています。ほとんどすべてのキーバインディングはそのまま残っています。もちろん、多くのキーバインディングが追加されましたが、一つか二つのあいまいな場合を除いて、古いバインディングが変更されたことはありません。

私たちのモットーは:

     鋼鉄の骨組みの空高く。

です。

すべての命令はその名前が変わっていません。いくつかの内部関数は名前を変えました。

gnus-uu パッケージは劇的に変化しています。See Decoding Articles.

一つの主要な互換性の質問は、いくつかの概略バッファーが存在することです。すべてのグループを読み込むときに関連する変数はそれが属する概略バッファーのバッファー固有です。多くの重要な変数はそれの全体の版にも複製されますが、概略バッファーで命令が実行されると、この変更は、あなたが注意していないと、正しくない値になるかもしれません。

GNUS の内部の知識に依存したすべてのコードは実行できないでしょう。二つ例を挙げます: gnus-newsrc-alist の並べ替え (もしくは、実際は何らかの方法でそれを変更すること) は絶対に禁止されています。Gnus はこの連想リストの登録を指し示すハッシュテーブルを保持しており (それは多くの関数の速度を上げます)、直接連想リストを変更することは異常な結果をもたらすでしょう。

古い hilit19 のコードはまったく動作しません。実際のところ、おそらくすべての hilit コードをすべての Gnus のフック (gnus-group-prepare-hook および gnus-summary-prepare-hook) から取り除くべきでしょう。Gnus はハイライトのためのいろいろな統合された関数を提供します。これらはもっと速くもっと正確です。すべての人の人生を楽にするために、Gnus はディフォルトですべての hilit フックからすべての hilit 呼び出しを取り除きます。きたないもの! とんでけ!

expire-kill のようなパッケージはもう動作しません。実際、Gnus を使い始めたときには、おそらくすべての古い GNUS パッケージ (と他のコード) を消去するべきでしょう。GNUS に実行させるために書いたコードは、 Gnus がすでに実行しているということは良くあることです。(くすくす。)

ものごとを実行する古い方法はまだ使用できますが、新しい方法だけがこのマニュアルに記載されています。もしこのマニュアルを読んでいる間に何かをする新しい方法を発見しても、古い方法を止めなければならないということではありません。

Gnus はすべての GNUS 起動ファイルを理解します。

全体として、GNUS の内部に依存したコードをほとんど書いていない普通の利用者は問題に苦しむことはないでしょう。問題が起これば、魔法の M-x gnus-bug 命令を実行することによって私に知らせて下さい。

非常に よくバグ報告を送る癖があるのであれば、しばらくすると役に立つ help バッファーがうるさいと感じるかもしれません。そうであれば、それが表示されるのを避けるために、 gnus-bug-create-help-buffer を nil に設定して下さい。

一致性
---

これは理由無き反抗、じゃないですよ、奥さん。私たちはすべての知られている標準に沿っています。もちろん私たちが賛成できない標準と/もしくは習慣は除きますが。

RFC (2)822
     この標準への知られている違反はありません。

RFC 1036
     この標準も知られている違反はありません。

Son-of-RFC 1036
     これにはいくつかの違反があります。

     X-Newsreader

     User-Agent
          これは ``つまらないヘッダー'' と考えられていますが、私は消費者の情報であると見なしています。tin と Netscape から送られてくる非常に多くの様式に沿っていない記事を見た後で、私はそれらを記事を投稿するためには使わない方が良いということを知りました。もし X-Newsreader ヘッダーが無ければ私はその情報を得ることはなかったでしょう。

USEFOR
     USEFOR は、IETF の working group が Son-of-RFC 1036 に基づいて、 RFC 1036 の後継として書いているものです。ニュース記事の様式に対して、いろいろな変更を提案した draft を作成しました。Gnus タワーは draft が RFC として認められたときに変更の実装を調べることになるでしょう。

MIME - RFC 2045-2049 etc
     MIME 関連のすべての RFC がサポートされています。

Disposition Notifications - RFC 2298
     Message Mode は受信者に開封確認を要求することができます。

PGP - RFC 1991 and RFC 2440
     RFC 1991 は最初の PGP メッセージの規格で、Informational RFC (訳注: 後述の標準化トラックではないが有用な情報) として発行されました。現在 Open PGP と呼ばれる後継の RFC 2440 が、標準化トラック (訳注: Standards Track---国際標準とすべき仕様) に乗せられました。どちらも非-MIME メッセージのための PGP の様式を定義します。 Gnus はエンコード (署名および暗号化) とデコード (認証および暗号のデコード) の両方をサポートします。

PGP/MIME - RFC 2015/3156
     RFC 2015 (RFC 1991 の代わりに RFC 2440 に基づいた 3156 で置き換えられました) は、RFC 1991/2440 を MIME で囲う様式について述べています。 Gnus はエンコードとデコードの両方をサポートします。

S/MIME - RFC 2633
     RFC 2633 は S/MIME の形式について述べています。

IMAP - RFC 1730/2060, RFC 2195, RFC 2086, RFC 2359, RFC 2595, RFC 1731
     RFC 1730 は IMAP バージョン 4 で、RFC 2060 (IMAP 4 改定 1) で多少更新されています。 RFC 2195 は IMAP の CRAM-MD5 認証について述べています。 RFC 2086 は IMAP の使用制限一覧 (ACL) について述べています。 RFC 2359 は IMAP のプロトコルの拡張について述べています。 RFC 2595 は IMAP における適切な TLS の統合 (STARTTLS) について述べています。 RFC 1731 は IMAP の GSSAPI/Kerberos4 の手法について述べています。

上に書かれている文章に関することで、Gnus がそれを満たしていないような動作をしていることに気付いたら、ためらわずに Gnus タワーと私たちに知らせて下さい。

Emacsen
-------

Gnus は以下のもので動作します:

  * Emacs 21.1 とそれ以上。

  * XEmacs 21.4 以上の Mule 機能付き

この Gnus の版はこれより古いどんな Emacsen でも完全に動作しないでしょう。少なくとも、信頼できる動作はしないでしょう。古い版の Gnus は古い Emacs の版でも動作するでしょう。

いろいろなプラットフォームの Gnus の間にはいくつかの漠然とした違いがあります---XEmacs はもっと画像機能 (ロゴとツールバー) を特徴にしています---しかし、その他は、すべての Emacsen でほとんど同じはずです。

Gnus の開発
--------

Gnus は二つの段階の循環で開発されています。最初の段階は ding@gnus.org でのたくさんの議論があり、そこで変更や新しい機能を提案します。この段階は アルファ 段階と呼ばれます。というのは、この段階でリリースされた Gnusae は アルファリリース もしくは (他の団体ではより良く使われる) スナップショット と呼ばれるものだからです。この段階では、Gnus は不安定であると考えられており、一般の利用者によって使われるものではありません。Gnus アルファリリースは ``Red Gnus'' や ``Quassia Gnus'' のような名前になっています。

50-100 くらいのリリースの後で、Gnus は 凍結 されたと宣言され、バグ修正のみが適用されます。Gnus は接頭引数が取れ、その代わりに ``Gnus 5.6.32'' のように呼ばれます。これら普通の人が使うことのできるものと考えられ、主に gnu.emacs.gnus ニュースグループで議論されています。

アルファ Gnusae とリリースされた Gnusae では変数のディフォルト値が違うものがあります。特に、mail-source-delete-incoming はアルファ Gnusae では nil で、リリースされた Gnusae では t です。これはメールを扱っている際に、アルファリリースの齟齬によりメールを失なうことを避けるためです。

ding メーリングリストと Gnus ニュースグループにおける議論の分離は純粋に公衆の関心によってなされているわけではありません。アルファ Gnus リリースが (ときどき) するかもしれない恐ろしいことを公衆の場で書くのは、皆を恐れさせるというのも事実ですが、もっと重要なことは、導入された新しい実験的な機能について話すことは一般の使用者を混乱させる可能性があります。新しい機能は頻繁に導入され、いじくられ、不十分であると判断され、そうすると捨てられるか、完全に書き換えられるかのどちらかです。メーリングリストを読んでいる人は普通はこの速い変更に付いていきますが、ニュースグループの人もそうであるとみなすことはできません。

貢献者
---

新しい Gnus の版は (ding) メーリングリストのすべての人の助けが無ければできなかったでしょう。一年以上、私は毎日とてもたくさんの素敵なバグレポートを受け取り、そのそれぞれが私を喜びで満たしました。愛撫。このリストの人々は忍耐を超えて私の ``あぁ、それはすばらしい考えだ <type type>、うん、私は待たずにそれをすぐリリースしよう <ship off>、それはまったく動作しない <type type>、うん、私はすぐに出そう <ship off> いや、纏う、それはまったく動作しないぞ''' というリリースに関する主義を変えて試してきた人々です。 Micro$oft---あぁ。アマチュア。私は もっと 悪い。(もしくは、``より悪い''? ``もっと悪い''? ``最悪''?)

私はこの機会にこの学会に... おおっと、違った。

  * 梅田政信---元の GNUS を書いた人です。

  * Shenghuo Zhu---uudecode.el, mm-uu.el, rfc1843.el, webmail.el, nnwarchive と MIME と他の形式のエンコード/デコードやバグ修正、新しい機能などのほんとうに多くのもの。

  * Per Abrahamsen---custom、スコア、ハイライトと SOUP コード (他の多くのことと共に)。

  * Luis Fernandes---デザインとグラフィック。

  * Joe Reiss---スマイリーの顔の作者。

  * Justin Sheehy---FAQ のメインテイナー。

  * Erik Naggum---援助、考え、サポート、コードとその他。

  * Wes Hardaker---gnus-picon.el と picon の部分のマニュアル (see Picons)。

  * Kim-Minh Kaplan---picon コードに置ける更なる作業。

  * Brad Miller---gnus-gl.el と Grouplens の部分のマニュアル。

  * Sudish Joseph---数え切れないほどのバグの修正。

  * Ilja Weis---gnus-topic.el。

  * Steven L. Baur---たくさんのたくさんのたくさんのバグの発見と修正。

  * Vladimir Alexiev---refcard とリファレンスの小冊子。

  * Felix Lee & Jamie Zawinski---私は Felix Lee と JWZ の XGnus 配布からいくつかの部分を盗みました。

  * Scott Byer---nnfolder.el の拡張と改訂。

  * Peter Mutsaers---古事記事のスコアコード。

  * Ken Raebburn---POP メールサポート。

  * Hallvard B Furuseth---いろいろな小さな物や部分、特に .newsrc ファイルを扱う部分。

  * Brian Edmonds---gnus-bbdb.el。

  * David Moore---nnvirtual.el の改訂と多くの他のこと。

  * Kevin Davidson---ding の名前を思い付きました。ですから、彼を責めて下さい。

  * Fran,Agois Pinard---多くの、多くの興味深く完全なバグレポートと autoconf のサポート。

このマニュアル (Gnus 英語版) は Adrian Aichner と Ricardo Nassif, Mark Borges によって校正され、Jost Krieger によって一部分を校正されました。

以下の人々は多くのパッチと提案で貢献しました:

Christopher Davis, Andrew Eskilsson, Kai Grossjohann, Kevin Greiner, Jesper Harder, Paul Jarc, Simon Josefsson, David K,Aegedal, Richard Pieri, Fabrice Popineau, Daniel Quinlan, Michael Shields, Reiner Steib, Jason L. Tibbitts, III, Jack Vinson, 山岡 克美, and Teodor Zlatanov.

それと、以下の人にもパッチやその他のものを感謝します:

Jari Aalto, Adrian Aichner, Vladimir Alexiev, Russ Allbery, Peter Arius, Matt Armstrong, Marc Auslander, Miles Bader, Frank Bennett, Alexei V. Barantsev, Robert Bihlmeyer, Chris Bone, Mark Borges, Mark Boyns, Rob Browning, Lance A. Brown, Kees de Bruin, Martin Buchholz, Joe Buehler, Kevin Buhr, Alastair Burt, Joao Cachopo, Zlatko Calusic, Massimo Campostrini, Castor, David Charlap, Dan Christensen, Kevin Christian, Jae-you Chung, James H. Cloos, Jr., Laura Conrad, Michael R. Cook, Glenn Coombs, Andrew J. Cosgriff, Neil Crellin, Frank D. Cringle, Geoffrey T. Dairiki, Andre Deparade, Ulrik Dickow, Dave Disser, Rui-Tao Dong, Joev Dubach, Michael Welsh Duggan, Dave Edmondson, Paul Eggert, Mark W. Eichin, Karl Eichwalder, 榎並　嗣智, Michael Ernst, Luc Van Eycken, Sam Falkner, Nelson Jose dos Santos Ferreira, Sigbjorn Finne, Sven Fischer, Paul Fisher, Decklin Foster, Gary D. Foster, Paul Franklin, Guy Geens, Arne Georg Gleditsch, David S. Goldberg, Michelangelo Grigni, Dale Hagglund, D. Hall, Magnus Hammerin, 半田 剣一, Raja R. Harinath, 林 芳樹, P. E. Jareth Hein, 久重 Kenji, Scott Hofmann, Marc Horowitz, Gunnar Horrigmo, Richard Hoskins, Brad Howes, Miguel de Icaza, Fran,Agois Felix Ingrand, 市川 達哉, 石川 一郎, Lee Iverson, 岩室 元典, Rajappa Iyer, Andreas Jaeger, Adam P. Jenkins, Randell Jesup, Fred Johansen, Gareth Jones, Greg Klanderman, Karl Kleinpaste, Michael Klingbeil, Peter Skov Knudsen, 小林 修平, Petr Konecny, 小関 吉則, Thor Kristoffersen, Jens Lautenbacher, Martin Larose, Seokchan Lee, Joerg Lenneis, Carsten Leonhardt, James LewisMoss, Christian Limpach, Markus Linnala, Dave Love, Mike McEwan, Tonny Madsen, Shlomo Mahlab, Nat Makarevitch, Istvan Marko, David Martin, Jason R. Mastaler, Gordon Matzigkeit, Timo Metzemakers, Richard Mlynarik, Lantz Moore, 守岡 知彦, Erik Toubro Nielsen, Hrvoje Niksic, Andy Norman, Fred Oberhauser, C. R. Oldham, Alexandre Oliva, Ken Olstad, 大西 雅晴, 小野 秀貴, Ettore Perazzoli, William Perry, Stephen Peters, Jens-Ulrik Holger Petersen, Ulrich Pfeifer, Matt Pharr, Andy Piper, John McClary Prevost, Bill Pringlemeir, Mike Pullen, Jim Radford, Colin Rafferty, Lasse Rasinen, Lars Balker Rasmussen, Joe Reiss, Renaud Rioboo, Roland B. Roberts, Bart Robinson, Christian von Roques, Markus Rost, Jason Rumney, Wolfgang Rupprecht, Jay Sachs, Dewey M. Sasser, Conrad Sauerwald, Loren Schall, Dan Schmidt, Ralph Schleicher, Philippe Schnoebelen, Andreas Schwab, Randal L. Schwartz, Justin Sheehy, Danny Siu, Matt Simmons, Paul D. Smith, Jeff Sparkes, Toby Speight, Michael Sperber, Darren Stalder, Richard Stallman, Greg Stark, Sam Steingold, Paul Stevenson, Jonas Steverud, Paul Stodghill, 須藤 清一, Kurt Swanson, Samuel Tardieu, Teddy, 戸沢 晶彦, Chuck Thompson, Philippe Troin, James Troup, Trung Tran-Duc, Jack Twilley, Aaron M. Ucko, Aki Vehtari, Didier Verna, Vladimir Volovich, Jan Vroonhof, Stefan Waldherr, Pete Ware, Barry A. Warsaw, Christoph Wedler, Joe Wells, Lee Willis, and Lloyd Zusman.

それぞれの人々が行なったことの完全な概観を得るために、 ChangeLog が Gnus のアルファ配布には含まれていて、豊富な読み物を与えるでしょう。(550KB といくらか)。

私が忘れたすべての人に謝罪します。間違いなくたくさんの人を忘れていることでしょう。

わぁ、こんなに人がいるとは思わなかった。これは本当に Gnus を使っている人がいるということなんでしょう。そんなことを誰が想像したでしょうか!

新しい機能
-----

このリストは、もちろん、たいていの 重要な新しい機能に関する 短い 概観でしかありません。いいえ、本当はそうではありません。もっともっとたくさんのものがあります。はい、私たちは創造性の完全な効果を感じているのです。

(ding) Gnus
...........

Gnus 5.0/5.1 の新しい機能:

  * すべてのバッファーの外観はフォーマットのような変数 (see Group Buffer Format, Summary Buffer Format) によって設定を変えることができるようになりました。

  * ローカルスプールと、いくつかの NNTP サーバーを同時に使うことができるようになりました (see Select Methods)。

  * 複数のグループを仮想グループに合併できるようになりました (see Virtual Groups)。

  * 多くの違ったメール様式 (see Getting Mail) を読めるようになりました。すべてのメールバックエンドは便利なメール期限切れ消去機構を実装しています (see Expiring Mail)。

  * Gnus は根っこ (root) を失ったスレッドを集めるためのいろいろな戦略 (それによってまばらな副スレッドを一つのスレッドにする) を使ったり、いったん戻って完全なスレッドをくみ上げるのに十分なヘッダーを取得しすることができます (see Customizing Threading)。

  * 切られたグループ (killed group) はぐループバッファーに表示することができて、それも読むことができます (see Listing Groups)。

  * Gnus は部分的グループ更新をすることができます---2,3 のグループの新しい記事を調べるためにアクティブファイル全体を取得する必要はありません (see The Active File)。

  * Gnus はグループの段階的購読度を実装しました (see Group Levels)。

  * 任意の数の基準に従って記事にスコアを付けることができます (see Scoring)。あなたのために記事をどのようにスコアを付けるかを Gnus に見つけさせることもできます (see Adaptive Scoring)。

  * Gnus は普通の Emacs の方法で自動保存されるドリブルバッファーを保持しているので、あなたのマシンが落っこちたときでもあまりデータを失わないでしょう (see Auto Save)。

  * Gnus は今や .emacs ファイルをぐちゃぐちゃにすることを避けるために専用の起動ファイル (~/.gnus.el) を持つようになりました。

  * グループと記事の両方にプロセス印を付けることができ、すべての印の付いた項目に演算をすることができます (see Process/Prefix)。

  * グループの一部を grep して、その結果からグループを作ることができます (see Kibozed Groups)。

  * えーと、すべてにしたがって、グループの一覧を挙げることができます (see Listing Groups)。

  * 外部サーバーを概観して、それらのサーバーのグループを購読することができます (see Browse Foreign Server)。

  * Gnus はサーバーとの二つ接続で、記事を非同期にとってくることができます (see Asynchronous Fetching)。

  * 記事をローカルにキャッシュすることができます (see Article Caching)。

  * uudecode の関数が拡張され、一般化されました (see Decoding Articles)。

  * 過去の GNUS のあまり知られていない機能の uuencode された記事をまだ投稿することができます (see Uuencoding and Posting)。

  * 親記事 (と他の記事) の取得は、今や実際に突然故障することなく動作するようになりました (see Finding the Parent)。

  * Gnus は FAQ とグループの記述を取得することができます (see Group Information)。

  * 記事をハイライトし、カスタマイズすることができます (see Customizing Articles)。

  * URL と他の外部参照がボタンになるようになりました (see Article Buttons)。

  * Gnus のウィンドウとフレームの設定でたくさんの変なことをできるようになりました (see Window Layout)。

  * キーボードを使う代わりに、ボタンをクリックできるようになりました (see Buttons)。

September Gnus
..............

Gnus 5.2/5.3 の新しい機能:

  * 新しいメッセージ作成モードが使われます。 mail-mode, rnews-reply-mode と gnus-msg のすべての古いカスタマイズ変数は今や旧式になりました。

  * Gnus は まばら スレッドを作成することができるようになりました---スレッドの失われた記事があるところは空の節で表現されるようになっています (see Customizing Threading)。

          (setq gnus-build-sparse-threads 'some)

  * 外に出ていく記事は特別な保管サーバーに保存されるようになりました (see Archived Messages)。

  * 記事が参照されたときに、スレッドの部分作成が起こるようになりました。

  * Gnus は GroupLens の予言を使うことができるようになりました。

  * Picons (personal icons) (個人アイコン) が XEmacs で表示できるようになりました (see Picons)。

  * trn のような木バッファーが表示されるようになりました (see Tree Display)。

          (setq gnus-use-trees t)

  * nn のような取って読むマイナーモードが概略バッファーで使うことができるようになりました (see Pick and Read)。

          (add-hook 'gnus-summary-mode-hook 'gnus-pick-mode)

  * バイナリーグループで特別なバイナリーマイナーモードを使うことができるようになりました (see Binary Groups)。

  * Group が折り畳みトピック階層にグループ分けできるようになりました (see Group Topics)。

          (add-hook 'gnus-group-mode-hook 'gnus-topic-mode)

  * Gnus が失敗メールを再送できるようになりました (see Summary Mail Commands)。

  * グループがスコアを持つことができるようになり、訪れる回数に基づいて並べ替えをできるようになりました (see Group Score)。

          (add-hook 'gnus-summary-exit-hook 'gnus-summary-bubble-group)

  * グループにプロセス印を付けられるようになり、グループのぐループに命令が実行できるようになりました (see Marking Groups)。

  * 仮想グループでキャッシュができるようになりました。

  * nndoc はすべての集配配送、メールボックス、rnews ニュース一括、 ClariNet 短収集、そしてすべてのその他を理解できるようになりました (see Document Groups)。

  * Gnus は SOUP パケットを作成/読み込みをするための新しいバックエンド (nnsoup) を持っています。

  * Gnus キャッシュがずっと速くなりました。

  * グループを多くの基準に従って並べ替えできるようになりました (see Sorting Groups)。

  * アドレスのリストと期限切れ消去の時間を設定する新しいグループパラメーターが導入されました (see Group Parameters)。

  * すべてのフォーマット指定が使われるフェースを指定できるようになりました (see Formatting Fonts)。

  * M P 副マップにプロセス印の付いた記事の設定/削除/実行のためのいくつかの命令があります (see Setting Process Marks)。

  * 広い範囲の基準に基づいて、概略バッファーが可能な記事の部分の表示に制限できるようになりました。これらの命令は / 副マップのキーにバインドされています (see Limiting)。

  * * 命令によって、記事を永続にすることができるようになりました (see Persistent Articles)。

  * 記事の要素を隠すすべての関数は切り替え関数になりました。

  * 記事のヘッダーがボタンにすることができるようになりました (see Article Washing)。

  * すべてのメールバックエンドで Message-ID による記事の取得を使用できるようになりました。

  * 重複メールを適切に扱うことができるようになりました (see Duplicates)。

  * すべての概略モード命令が記事バッファーから直接使用できるようになりました (see Article Keymap)。

  * フレームが gnus-buffer-configuration の部分になることができます (see Window Layout)。

  * デーモンのプロセスでメールを再走査することができるようになりました (see Daemons)。

  * Gnus は spam を根絶やしにするために NoCeM ファイルを使うことができるようになりました (see NoCeM)。

          (setq gnus-use-nocem t)

  * グループを永久可視にすることができるようになりました (see Listing Groups)。

          (setq gnus-permanently-visible-groups "^nnml:")

  * カスタマイズを簡単にするために多くの新しいフックが導入されました。

  * Gnus は Mail-Copies-To ヘッダーに注意を払うようになりました。

  * References ヘッダーを集めることによりスレッドを集めることができるようになりました (see Customizing Threading)。

          (setq gnus-summary-thread-gathering-function
                'gnus-gather-threads-by-references)

  * 既読記事は再取得を避けるために特別なバックログバッファーに貯められるようになりました (see Article Backlog)。

          (setq gnus-keep-backlog 50)

  * 簡単にトリートメントができるようにするために、現在の記事のきれいな複製がいつも別バッファーに蓄積されるようになりました。

  * Gnus がどこに記事を保存するかを提案できるようになりました (see Saving Articles)。

  * Gnus は保存するときに同じくらいの入力要求をしなくても良いようになりました (see Saving Articles)。

          (setq gnus-prompt-before-saving t)

  * uu は記事を取得している間に非同期でデコードされたファイルを表示できるようになりました (see Other Decode Variables)。

          (setq gnus-uu-grabbed-file-functions 'gnus-uu-grab-view)

  * 引用された文章に対して、記事バッファーでの折り返しが適切に動作するようになりました (see Article Washing)。

  * 隠された引用文は隠すことを切り替えるボタンを加え、どのくらいの引用文を隠すかをカスタマイズできるようになりました (see Article Hiding)。

          (setq gnus-cited-lines-visible 2)

  * 退屈なヘッダーを隠すことができます (see Article Hiding)。

  * スコアのディフォルト値がメニューバーから設定できるようになりました。

  * 出て行く記事の更なる構文チェックができるようになりました。

Red Gnus
........

Gnus 5.4/5.5 の新しい機能:

  * nntp.el は非同期の流儀で完全に改訂されました。

  * スコア付けは and, or, not のような論理演算子と、親の再方向で実行できるようになりました (see Advanced Scoring)。

  * 記事の洗濯状態が記事モード行に表示されるようになりました (see Misc Article)。

  * gnus.el が多くの小さいファイルに分割されました。

  * Message-ID に基づいた、重複記事の抑制がなされるようになりました (see Duplicate Suppression)。

          (setq gnus-suppress-duplicates t)

  * どのスコアと適応ファイルがホームのスコアと適応ファイルであるかを指定する (see Home Score File) 新しい変数が加えられました。

  * nndoc が簡単に拡張可能になるように改訂されました (see Document Server Internals)。

  * グループは親のトピックからグループパラメーターを継承できるようになりました (see Topic Parameters)。

  * 記事編集が改訂され、実際に使用可能になりました。

  * 署名がもっと知的な方法で認識されるようになりました (see Article Signature)。

  * 概略ピックモードがもっと nn のようになりました。行数が表示されて、 . 命令が記事を取るために使うことができるようになりました (Pick and Read)。

  * あるサーバーから別のサーバーへ .newsrc.eld を移動する命令が加えられました (see Changing Servers)。

  * 今や、バッファーの行を作成するときに、抑制される ``おもしろくない'' 部分を指定する方法があります (see Advanced Formatting)。

  * グループバッファーでのいくつかの命令は C-M-_ で元に戻すことができるようになりました (see Undo)。

  * 新しいスコアの型 w を使うことで、語にスコア付けをすることが可能になりました (see Score File Format)。

  * 表題に一語一語を基にして適応スコアをできるようになりました (see Adaptive Scoring)。

          (setq gnus-use-adaptive-scoring '(word))

  * スコアが腐敗できるようになりました (see Score Decays)。

          (setq gnus-decay-scores t)

  * 日付のヘッダーに正規表現を使ってスコア付けを実行できるようになりました。日付はまず短縮 ISO 8601 様式で正規化されます (see Score File Format)。

  * 基本サーバーの記事に関するすべてのデータを取り除く命令が加えられました (see Changing Servers)。

  * 文書の集合を読むための新しい命令 (nndoc と nnvirtual の上で) が加えられました---C-M-d (see Really Various Summary Commands)。

  * プロセス印の設定が push と pop できるようになりました (see Setting Process Marks)。

  * 新しいメールからニュースへのバックエンドが NNTP サーバーが投稿を許可していない場合でも、投稿できるようになりました (see Mail-To-News Gateways)。

  * ウェブ検索エンジン (DejaNews, Alta Vista, InReference) からの検索結果を読む新しいバックエンドが加えられました (see Web Searches)。

  * 標準の並べ替え関数を使ってグループの中のトピックを並び代えすることができ、それぞれのトピックが独立して並べ替えできるようになりました (see Topic Sorting)。

  * グループの一部分が独立して並べ替えできるようになりました (Sorting)。

  * キャッシュされた記事がグループに入れられるようになりました (see Summary Generation Commands)。

  * スコアファイルがもっと信頼できる順番で適用できるようになりました (see Score Variables)。

  * メールメッセージがどこに行くかの報告を作成することができるようになりました (see Splitting Mail)。

  * 入って来たメールを保存する前にがらくたを取り除くフックと関数がもっと追加されました (see Washing Mail)。

  * 強調文が適切にフォントが変更されるようになりました:

Quassia Gnus
............

Gnus 5.6 の新しい機能:

  * Gnus をオフラインニュースリーダーとして使う新機能が加えられました。過剰なほどの新しい命令とモードが追加されました。完全な話に付いては Gnus Unplugged を見て下さい。

  * nndraft バックエンドが戻ってきましたが、依然とは違うように動作するようになりました。すべてのメッセージバッファーは nndraft グループの記事でもあり、それは自動的に作成されます。

  * gnus-alter-header-function がヘッダーの値を変えるために使われるようになりました。

  * gnus-summary-goto-article が Message-ID を受け付けるようになりました。

  * リージョンの外のメッセージの本文の文章を消去するための新しいメッセージ命令があります: C-c C-v。

  * C-u C-c C-c によって nnvirtual グループを生成しているグループに投稿できるようになりました。

  * nntp-rlogin-program---カスタマイズを簡単にするための新しい変数です。

  * gnus-article-edit-mode の C-u C-c C-c は記事バッファーの再ハイライトを禁止するようになりました。

  * gnus-boring-article-headers に新しい要素があります---long-to。

  * M-i シンボル接頭引数命令があります。詳細は Symbolic Prefixes を見て下さい。

  * 概略バッファーの L と I は all.SCORE ファイルにスコア法則を加えるためにシンボル接頭引数 a を受け付けるようになりました。

  * 変数 gnus-simplify-subject-functions により単純化をもっと制御できるようになりました。

  * A T---現在のスレッドを取得するための新しい命令です。

  * / T---現在のスレッドを制限に含めるための新しい命令です。

  * M-RET は引用文を止めるための新しいメッセージ命令です。

  * \\1 表現が nnmail-split-methods で有効になりました。

  * 関数 custom-face-lookup が取り除かれました。あなたの初期化ファイルでこの関数を使っているのなら、代わりに face-spec-set を使うように書き直さなければなりません。

  * 投稿取り消しは現在の選択方法を使うようになりました。シンボル接頭引数 a は普通の投稿方法を強制します。

  * M******** sm*rtq**t*s を適切な文章に翻案する新しい命令があります--- W d。

  * nntp のより簡単なデバッグのために、 nntp-record-commands を nil でない値に設定することができます。

  * nntp は ~/.authinfo を使うようになり、これは .netrc のようなファイルで、どこでどのように AUTHINFO を NNTP サーバーに送るかを制御するためのものです。

  * 概略バッファーのグループパラメーターを編集するための命令が加えられました。

  * メールがどこに分割されたかの履歴を使用可能になりました。

  * 新しい記事日付命令が加えられました---article-date-iso8601。

  * gnus-score-thread-simplify を設定することによりスレッドを作成しているときは表題が単純化されるようになりました。

  * メッセージで引用をするための新しい関数が加えられました--- message-cite-original-without-signature。

  * article-strip-all-blank-lines---新しい記事命令です。

  * 記事の終わりまでを切る新しいメッセージ命令が加えられました。

  * 変数 gnus-adaptive-word-minimum を使うことにより最小限適応スコアを指定することができます。

  * gnus-start-date-timer 命令により ``記事が投稿されたときからの経過時間'' ヘッダーが継続的に更新されるようになりました。

  * ウェブ listserv アーカイブが nnlistserv バックエンドにより読むことができるようになりました。

  * 古い dejanews アーカイブが nnweb から読むことができるようになりました。

Pterodactyl Gnus
................

Gnus 5.8 の新しい機能:

  * メールを取り込む機能が変わりました。たくさんの詳細についてはマニュアルを見て下さい。特に、procmail で取り込むためのすべての変数が無くなっています。

     このような procmail の使い方は

          (setq nnmail-use-procmail t)
          (setq nnmail-spool-file 'procmail)
          (setq nnmail-procmail-directory "~/mail/incoming/")
          (setq nnmail-procmail-suffix "\\.in")

     現在は次のように変わっています。

          (setq mail-sources
                '((directory :path "~/mail/incoming/"
                             :suffix ".in")))

     See Mail Source Specifiers.

  * Gnus は MIME に対応したリーダーになりました。これは Gnus の多くの部分に影響していて、たくさんの新しいコマンドが追加されています。詳細はマニュアルを参照して下さい。

  * Gnus はまた各国語対応になりました。ここでは要約できないくらいに Gnus の多くの部分に影響していて、新しいたくさんの変数が追加されています。

  * gnus-auto-select-first が関数であってもよくなりました。

  * Summary バッファーと NOV ファイルに含める追加のヘッダーを、利用者が決めることができるようになりました。

  * gnus-article-display-hook が削除されました。代わりに gnus-treat- で始まるたくさんの変数が追加されました。

  * Gnus posting styles が再び改装されました。現在は微妙に違う規則で動作します。

  * 新しいウェブに基づいたバックエンドが追加されました。nnslashdot, nnwarchive および nnultimate です。nnweb は再び改作され、常に変化する構成を続けます。

  * Gnus は nnimap によって IMAP メールを読むことができます。

Oort Gnus
.........

Gnus 5.10 の新しい機能:

  * 領域が活性化されている場合、 F キー (gnus-article-followup-with-original) および R キー (gnus-article-reply-with-original) は、その領域にあるテキストだけを yank します。

  * gnus-group-read-ephemeral-group を G M キーで対話的に呼ぶことができます。

  * ドラフト・グループで e キーが gnus-draft-edit-message コマンドに割り当てられました。gnus-summary-edit-article コマンドには、代わりに B w キーを使って下さい。

  * 改定された Gnus FAQ がマニュアルに含まれています。 See Frequently Asked Questions.

  * Oort を使ったことがある場合の、以前の (安定な) 版からのグレードアップ。

     Oort (このリリースに先立つ安定ではない Gnus の枝) を使ってみたものの、安定版に戻してしまったならば、この版にグレードアップするときに注意して下さい。特に、おそらくすべての .marks (nnml) と .mrk (nnfolder) ファイルを消去する必要があるでしょう。この版 (の Gnus) がフラグを格納する .marks/.mrk ファイルではなくて .newsrc.eld からフラグが読まれるようになっていたからです。後述の項目で、印 (marks) に関するより多くの情報を読んで下さい。グレードを下げても一般には助けにならないことに注意して下さい。

  * 記事のボタン

     URL、メールアドレス、Message-ID、Info へのリンク、man ページと Emacs または Gnus に関連した参考文献のための、より多くのボタン。See Article Buttons. すべての記事のボタンの見栄えを制御するために gnus-button-*-level 変数を使うことができます。 See Article Button Levels.

  * Dired の統合

     gnus-dired-minor-mode (Other modes 参照) は、dired のバッファーでキー設定---添付ファイルの送信、mailcap の適切な項目を使ってファイルを開く、それに mailcap の項目を使ってファイルを印刷する---を行ないます。

  * Gnus は RSS のニュース配送を、ニュースグループとして表示します。 See RSS.

  * 単一の yenc でエンコードされた添付パートがデコードできます。

  * Picons

     Picon のコードが、GNU Emacs で動作させるために再実装されました。以前のいくつかのオプションが、削除または改名されています。

     Picon は、利用者、ドメイン、それにニュースグループを表現するための「個人的なアイコン (personal icons)」で、記事バッファーに表示することができます。See Picons.

  * 新しいオプション gnus-treat-body-boundary を非-nil にすると、ヘッダーのおしまいに境界線が描かれます。

  * 憲章とコントロールメッセージの取得

     二つのコマンド---ニュースグループの憲章を取り込む (H c)、コントロールメッセージを取得 (H C)---があります。

  * 遅延記事

     Message バッファーにおける C-c C-j で、メッセージの送信を遅らせることができます。メッセージは指定された時刻に配送されます。これはあなた自信のための忘備録として役に立つでしょう。See Delayed Articles.

  * auto-compression-mode が有効になっていると、添付ファイルを見るときに自動で圧縮が解かれます。

  * 新しいオプション nnml-use-compressed-files を非-nil にすることによって、nnml が圧縮されたメッセージファイルを扱うことができるようになります。

  * 記事の署名ヘッダー (X-PGP-Sig) を、W p で認証することができます。

  * 概略バッファーは fringe の中の矢印で現在の記事を示します。これを無効にするには (setq gnus-summary-display-arrow nil) を使って下さい。

  * ニュースにメールで返信しようとしたら警告

     間違ってニュースにメールで返信しようとしてしまうことが、しょっちゅうありませんか?  そんなあなたに新オプション gnus-confirm-mail-reply-to-news。

  * 新しいオプション gnus-summary-display-while-building を非-nil にすると、概略バッファーが作られていく様子が表示されます。

  * 新しい recent 印 . で、新規に届いたメッセージを (未読だけれども古い記事とは区別して) 表示します。

  * 新しいオプション gnus-gcc-mark-as-read は、Gcc の記事に自動的に既読の印を付けます。

  * nndoc バックエンドは、mailman のまとめ送りと exim が弾いたメッセージをサポートするようになりました。

  * Gnus は RFC 2369 のメーリングリストのヘッダーをサポートします。また、メーリングリストのグループ用に数々のコマンドを用意しました。See Mailing List.

  * 日付ヘッダーを、英語で発音できる形式で表示することができます。 See Article Date.

  * Sendmail を使うときのエンベロープ送信者 (envelope sender) のアドレスが、カスタマイズできるようになりました。See メール変数 (The Message Manual).

  * mm-uu-diff-groups-regexp に合致するグループでは、差分 (diffs) が自動的にハイライトされます。

  * TLS ラッパーが Gnus に同梱

     TLS/SSL が、tls.el と GNUTLS を介して IMAP と NNTP でサポートされるようになりました。 (サードパーティーの) ssl.el と OpenSSL による古い TLS/SSL は、まだ使えます。

  * MS ウィンドウズで Gnus をコンパイルしてインストールするための、新しい make.bat

     MS ウィンドウズで Gnus をインストールするには make.bat を使って下さい。このバッチ・プログラムの第一引数はディレクトリーです。そこで xemacs.exe と emacs.exe が順に捜し出されます。コンパイルしてから Gnus をインストールしたいときは、make.bat の第二引数に /copy を与えて下さい。

     make.bat はゼロから書き直されました。XEmacs と GNU Emacs を自動認識し、gnus-load.el を生成し、コンパイル中と info ファイルの生成中にエラーが起きたら構築処理の最後に報告します。makeinfo が利用可能であればそれを使い、さもなければ infohack.el に頼ります。今や make.bat は Gnus を動作させるために必要なすべてのファイルをインストールするはずで、大体において Unix システムにおける configure; make; make install サイクルの完全な置き換えになりました。

     新しい make.bat は make-x.bat を不要にしたので、それは削除されました。

  * 非-ASCII ドメイン名のサポート

     Message は From:, To: および Cc: にある非-ASCII ドメイン名をサポートし、メッセージの送信を試みるときにエンコードするかどうかを尋ねます。 message-use-idna 変数でこれを制御します。Gnus もまた、メッセージを見るときに From:, To: および Cc: にある非-ASCII ドメイン名をデコードします。これを制御するのは gnus-use-idna 変数です。

  * マイクロソフト引用様式のより良い取り扱い

     いくつかのマイクロソフトのメイラーが、メッセージの残りの部分が引用であることを示すために使う台無しにされたヘッダーブロックを、たとえそれが引用符で囲まれていなくても、Gnus は認識しようとします。変数 gnus-cite-unsightly-citation-regexp は、それらの引用の先頭に合致します。

  * gnus-article-skip-boring

     gnus-article-skip-boring を t に設定すると、Gnus はうんざりする文しか含んでいないページを見せるために、下方にスクロールしません。 gnus-article-boring-faces を使って、何を読み飛ばしてしまっても良いかをカスタマイズすることができます。

     長くて刈り込まれていない引用が、てっぺんに少しだけある新規な内容に続いているたくさんの記事を読む場合に、これは特に役に立ちます。

  * ポイントの位置決めのためのフォーマットの仕様 (format spec) である %C は、%* に変更されました。

  * 新しい変数 gnus-parameters が、グループパラメーターを設定するために使うことができます。

     これは初期には、パラメーターを ~/.newsrc.eld に格納する G p (または G c) でしか行なうことができませんでしたが、この変数によってカスタマイズの威力を堪能することができます。また、その変数は ~/.newsrc.eld ではなくて ~/.emacs で設定するので、バックアップが簡単になります。その変数は、グループ名に合致する正規表現を、以下のような流儀でグループパラメーターに割り当てます:

          (setq gnus-parameters
                '(("mail\\..*"
                   (gnus-show-threads nil)
                   (gnus-use-scoring nil))
                  ("^nnimap:\\(foo.bar\\)$"
                   (to-group . "\\1"))))

  * スマイリー (:-), ;-) など) が Emacs でもアイコン化されるようになりました。

     これを働かないようにするには、(setq gnus-treat-display-smileys nil) を ~/.emacs に置いて下さい。

  * Gnus は今では Sender: ヘッダーを自動では生成しません。

     初期のころ、それは利用者が設定できる email アドレスが、Gnus が想定した利用者のディフォルトのアドレスと違っていた場合に生成されました。今日ではその想定アルゴリズムが正しいことはまれで、Sender: ヘッダーの唯一の (議論の的になる) 用途は、ニュースを cancel/supersede する資格があるかどうかを検査すること (これは代わりに、他の項で述べられる Cancel Locks によって解決された) なので、そのヘッダーの生成はディフォルトで抑制されています。変数 message-required-headers、 message-required-news-headers および message-required-mail-headers を参照して下さい。

  * サードパーティーによる message-utils.el の機能が message.el に加えられました。

     Message は表題 (subject) の行から (was: <old subject>) を削除するかどうかを尋ねるようになりました (message-subject-trailing-was-query 参照)。 C-c M-m と C-c M-f は挿入されたテキストを示す印を挿入します。 C-c C-f a は X-No-Archive: ヘッダーを付け加えます。C-c C-f x は、適切なヘッダーと、クロスポストとフォロー先についての注意書きを本文に挿入します (message-cross-post-* 変数群を見て下さい)。

  * 今や message-generate-headers-first が nil だったら、メッセージの作成を始めるときに References と X-Draft-Headers は生成されません。

  * 改良された spam 対抗機能。

     Gnus は非常に変化に富んだプログラムと濾過の規則を使って、メールやニュースの奔流から spam を抜き取ってしまうことができるようになりました。対応している方式は、RBL blocklists、bogofilter それにホワイト/ブラックリストです。また SpamAssassin や Hashcash のような外部パッケージを簡単に使うための hook も新しくなりました。See Thwarting Email Spam.

  * X-Faces ヘッダーの挿入が簡単になりました。

  * Face ヘッダーを扱えるようになりました。

  * 概略バッファーに、新しいコマンド / N は新着メッセージを挿入し、 / o は古いメッセージを挿入します。

  * W m を押すと、Gnus はモールスでエンコードされたメッセージをデコードします。

  * nnimap のグループにおける未読の数が正確になりました。

     グループバッファーで、nnimap グループの未読記事の数の見積りが正確になったはずです。これは gnus-setup-news-hook (起動時に呼ばれる) と gnus-after-getting-new-news-hook (新しいメールを取得した直後に呼ばれる) から nnimap-fixup-unread-after-getting-new-news を呼ぶことによって成し遂げられます。これらの変数をディフォルトから変えている場合は、再び nnimap-fixup-unread-after-getting-new-news を追加する必要があるかもしれません。見積りに満足していて、新しいメールを取得するときにいくらか (最小限度の) 時間を節約したいのであれば、その関数を外して下さい。

  * グループカーボンコピー (GCC) を引用符で囲む

     空白や他の変な文字を含むグループを扱えるようにするために、グループは Gcc: header に置かれる前に引用符で囲まれます。これは、空白を含むグループが使えるようにするために、もはや gnus-message-archive-group のような変数に引用文字を含めるべきではないことを意味します。さらに、文字列 nnml:foo, nnml:bar (二つのグループに Gcc を格納することを示す) を使っているならば、リスト ("nnml:foo" "nnml:bar") を返すように変更しなければなりません。さもないと、Gcc: 行は間違った囲まれ方をされてしまうでしょう。初期のころに文字列 nnml:foo, nnml:bar を返すようにしたことが間違いだったことに着目して下さい。それは直接挿入されたので、まったく問題を生じませんでした。

  * ~/News/overview/ は不要。

     以下の変更の結果、今後は ~/News/overview/ ディレクトリーは要りません。すべての階層を安全に削除することができます。

  * gnus-agent

     Gnus エージェントは大規模な更新を経て、今やディフォルトで活性化されます。そして gnus-select-method と gnus-secondary-select-method で指定されるすべての nntp と nnimap のサーバーが、ディフォルトでエージェント化されます。初期においては gnus-select-method のサーバーだけがディフォルトでエージェント化され、エージェントはディフォルトで不活性化されていました。エージェントが活性化されると、可能ならばバックエンドに代わってエージェントのキャッシュからヘッダーが取り寄せられます。初期には、これはオフライン (unplugged) の状態でのみ行なわれていました。サーバーバッファーで J a と J r を使うことによって、サーバーの登録と削除を行なうことができます。グループバッファーから J u か J s を使って命令しない限り、Gnus は記事をエージェントのキャッシュにダウンロードしません。(setq gnus-agent nil) でもって、エージェントが不活性化されていた昔の振る舞いに戻すことができます。今後は ~/.gnus.el に (gnus-agentize) を置いておく必要が無いことに注意して下さい。

  * gnus-summary-line-format

     ディフォルト値が %U%R%z%I%(%[%4L: %-23,23f%]%) %s\n に変わりました。さらに、受信者の名前か NNTP グループに投稿したグループ名で利用者名を置き換えるために、gnus-extra-headers、 nnmail-extra-headers および gnus-ignored-from-addresses のデフォルト値が変わりました。

  * deuglify.el (gnus-article-outlook-deuglify-article)

     いかれた Outlook (Express) の記事を醜くなくするための、Raymond Scholz rscholz@zonix.de によって新設されたファイルです。

  * (require 'gnus-load)

     単独で配布されている Gnus を使う場合には、 load-path に Gnus の lisp ディレクトリーを追加してから、 ~/.emacs に (require 'gnus-load) を加えるのが良いです。

     gnus-load.el ファイルは、そのうちのいくつかは Emacsen の配布に入っていないかもしれない自動読み込み (autoload) コマンド、関数および変数を含んでいます。

  * gnus-slave-unplugged

     オフラインの Gnus をスレーブモードで起動する新しいコマンドです。

  * message-insinuate-rmail

     (message-insinuate-rmail) と (setq mail-user-agent 'gnus-user-agent) を .emacs に加えることで、 message-mode でメッセージの作成、返信および転送を行なうように Rmail を説得することができます。そこでは MML の威力を堪能できます。

  * message-minibuffer-local-map

     下の行で、メッセージを再送するときに BBDB が使えます:

          (define-key message-minibuffer-local-map [(tab)]
            'bbdb-complete-name)

  * 添付ファイル (attachments) の切り離し (externalizing) と消去。

     gnus-gcc-externalize-attachments または message-fcc-externalize-attachments が非-nil になっていると、ローカルファイルを外部パートとして添付します。

     gnus-mime-save-part-and-strip コマンド (MIME ボタン上で C-o に割り当てられている) は、パートをセーブしてから外部のそれと置き換えます。gnus-mime-delete-part (MIME ボタン上で d に割り当てられている) は、パートを削除します。これは編集をサポートしているバックエンドでだけ動作します。

  * gnus-default-charset

     デフォルト値は iso-8859-1 に代わって current-language-environment 変数によって決定される値になります。また、gnus-group-charset-alist にあった .* の項目は削除されました。

  * gnus-posting-styles

     このような合致の様式が加わりました。

          ((header "to" "larsi.*org")
           (Organization "Somewhere, Inc."))

     下記のような古い様式は時代遅れになりましたが、まだ受け入れられます。

          (header "to" "larsi.*org"
                  (Organization "Somewhere, Inc."))

  * message-ignored-news-headers と message-ignored-mail-headers

     X-Draft-From と X-Gnus-Agent-Meta-Information が、これら二つの変数に加えられています。それらをカスタマイズする場合に、もしかするとそれら二つのヘッダーを加える必要があります。

  * Gnus は差し込まれている (plugged) ときに、エージェントから NOV と記事を読み込みます。

     差し込まれているときに記事を読む場合に、その記事がすでにエージェントにあるならば、もう一度ダウンロードすることはありません。(setq gnus-agent-cache nil) は旧式の動作に戻します。

  * Gnus は ``format=flowed'' (RFC 2646) パラメーターをサポートします。メッセージを作成するときに、それは use-hard-newlines で活性化されます。 format=flowed のデコードは以前からできましたが、初期の版では説明の文書がありませんでした。

  * Gnus は RFC 2298 の開封確認要求の生成をサポートします。

     これはメッセージモードの C-c M-n キーで起動されます。

  * Gnus は Maildir グループをサポートします。

     Gnus は新バックエンドである nnmaildir.el を含んでいます。 See Maildir.

  * 印刷の性能が向上しました。

     Gnus はそれ自身が、概略と記事バッファーにおける O P で Muttprint をサポートします。さらに MIME ボタン上で p を使うことによって、個々の MIME パートのそれぞれを印刷することができます。

  * Message は Importance: ヘッダー (RFC 2156) をサポートするようになりました。

     メッセージバッファーで C-c C-f C-i か C-c C-u を使うと、可能な値が循環します。

  * Gnus はニュースの Cancel Locks をサポートします。

     投稿するニュース記事に Cancel-Lock ヘッダーが挿入されることです。これは、記事をあなたが書いたのかどうかを確かめるために使います (キャンセルと置き換えのとき)。最初に記事を投稿するときに、Gnus はランダムなパスワード文字列を生成し、カスタムの機構を使って ~/.emacs にセーブします。その変数は canlock-password と呼ばれますが、機密を気にするデータではありません。ウェブ上で canlock を公開しても、以前から彼女ができなかった何かを、誰かができるようにするものではありません。 message-insert-canlock をカスタマイズすることによって、振る舞いを変更するができます。

  * Gnus は Sieve を使ったサーバー側でのメールの濾過をサポートします。

     Sieve の規則はグループパラメーターとして加えることができ、グループバッファーで D g を使うと完全な Sieve スクリプトが生成されます。そうしたら、生成された Sieve バッファーで C-c C-l を使って、サーバーにアップロードして下さい。Sieve Commands、それに新しい Sieve のマニュアル (see Emacs Sieve) を参照して下さい。

  * 拡張されたフォーマットの仕様 (format specs)。

     フォーマットの仕様 %&user-date; が gnus-summary-line-format-alist に追加されました。それに、利用者定義による拡張されたフォーマットの仕様もサポートされています。拡張されたフォーマットの仕様は %u&foo; のようなもので、関数 gnus-user-format-function-FOO を起動します。 & がエスケープ文字に使われているので、古い利用者定義フォーマットである %u& は今やサポートされていません。

  * / * (gnus-summary-limit-include-cached) が書き直されました。

     これは Y c (gnus-summary-insert-cached-articles) の別名でした (訳注: 以前は)。新しい関数は他の記事を濾過して除去します。

  * いくつかのコマンドは C-u 接頭引数で合致の否定を扱うことができます。

     C-u を subject、author または extra ヘッダーをこの順に使う---すなわち / s、/ a および / x (gnus-summary-limit-to-{subject,author,extra})--- と、結果としてその表現に合致しないすべての記事が表示されます。

  * グループ名は、ディフォルトで UTF-8 であるものとして取り扱われます。

     これは USEFOR が移行しようとしていると想定されるものです。カスタマイズするには gnus-group-name-charset-group-alist および gnus-group-name-charset-method-alist を参照して下さい。

  * nnml と nnfolder バックエンドは、グループ毎に印 (marks) を格納するようになりました。

     これは nnml/nnfolder サーバー/グループ を ~/.newsrc.eld と切り離して、しかし印は守りつつ、バックアップすることを可能にします。さらに、例えば研究室や職場などの組織内で、(~/.newsrc.eld ファイルを共有すること無しに) 利用者間で記事と印を共有することをも可能にします。これは、 ~/.newsrc.eld に格納される印を、グループ毎の .marks ファイル (nnml 用) と GROUPNAME.mrk ファイル (GROUPNAME の名前を持つ nnfolder 用) に格納することによって動作します。 nnml/nnfolder を他のマシンに引っ越しても、 Gnus は ~/.newsrc.eld にある情報の代わりに、自動的に .marks か .mrk ファイルを使います。新しいサーバー変数である nnml-marks-is-evil と nnfolder-marks-is-evil が、この機能を抑制するために使うことができます。

  * グループと概略バッファーのメニュー項目の名前 ``Misc'' は ``Gnus'' に改名されました。

  * Message mode で ``MML'' と名付けられたメニュー項目は、 ``Attachments'' に改名されました。このメニューは、署名と暗号化 (see セキュリティー (The Message Manual)) のような、保安に関連したものも含んでいることに着目して下さい。

  * gnus-group-charset-alist と gnus-group-ignored-charsets-alist。

     これらの変数に設定された正規表現は、完全な (full) グループ名と比較されます。Gnus 5.8 では実際の (real) グループ名が比較の対象でした。したがって、これらの変数をカスタマイズしている利用者は、正規表現を変更しなければなりません。例です:

          ("^han\\>" euc-kr) -> ("\\(^\\|:\\)han\\>" euc-kr)

  * Gnus は PGP (RFC 1991/2440)、PGP/MIME (RFC 2015/3156) および S/MIME (RFC 2630-2633) をサポートします。

     これには S/MIME と OpenPGP が実装されている必要があります。でも追加の Lisp ライブラリは要りません。メッセージの作成時に、いくつかのメニューと C-c RET キーの割り当てが Attachments メニューに追加されます。これはまた、gnus-article-hide-pgp-hook を時代遅れにしました。

  * Gnus は外部パート (message/external) をインライン表示します。

  * MML (Mime 作成) コマンドの接頭キーが、M-m から C-c C-m に変わりました。

     この変更によって、標準キー割り当ての back-to-indentation との衝突が回避されました。このコマンドもまた、メッセージモードでは役に立つのです。

  * message-forward-show-mml のディフォルトが best に変わりました。

     値 best の振る舞いは、それがふさわしい場合は MML を表示する (すなわち MIME に変換する) ことです。変換がディジタル署名を無効にしてしまうので、署名された、または暗号化されたメッセージを転送するときは MML は使われません。

No Gnus
.......

No Gnus の新しい機能:

     [file gnus-news-ja.texi not included]

マニュアルを書く
========

おそらく、たいていのマニュアルは事実の後で書かれていると思います。すでにあるプログラムを文書化しています。このマニュアルはそういう方法で書かれていません。何かを実装するときは、何かをそのままマニュアルの一節に書きます。それから機能の説明が難しいことを発見して、それがどのようにあるべきであるかを書き、それから実装を変更します。文書とコードを書くのは一緒に行なわれていきます。

もちろん、これはこのマニュアルには流れ構造がほとんど無いか、あっても少しだということです。Gnus の完全にすべてのことが説明されていますが、探している場所ではないということがよくあります。これはリファレンスマニュアルであり、Gnus を始めるための手引きではありません。

それはまったく違った本になり、このリファレンスマニュアルを元として使って書かれたものになるでしょう。とても違ったものになるはずです。

用語
==

ニュース (news)
     これはあなたがそのためにこのものを使いたいと思っているものです---ニュースを読むことです。ニュースは一般的には近くの NNTP サーバーから取得され、普通はすべての人に広く利用可能なものです。もしニュースを投稿すれば、全世界があなたがちょうど書いたものを読む可能性があり、それらはすべていたずらっぽくクスクス笑われるでしょう。あなたの知らないところで。

メール (mail)
     あなたに個人的に配送されるものすべてがメールです。いくつかのニュース/メールリーダー (Gnus のような) はメールとニュースの違いをぼやけさせますが、そこには違いは存在します。メールは私的です。ニュースは公的です。メールを送信することは投稿ではなく、返信はフォローアップではありません。

返信 (reply)
     あなたが読んでいるものを書いた人にメールを送ることです。

フォローアップ (follow up)
     あなたが読んでいる記事に応答して現在のニュースグループに記事を投稿することです。

バックエンド (back end)
     Gnus はメールとニュースがほとんど同じだとみなします。本当に。違いは実際の記事にどのようにアクセスするかだけです。メールメッセージはローカルディスクのファイルから読めるのに対して、ニュース記事は一般に NNTP プロトコルで取得します。Gnus の内部構造は、それらのために ``フロントエンド'' と数々の ``バックエンド'' から成り立っています。内部的に、あなたがグループに入る (そう、RET をたたく) とき、そのために Gnus のフロントエンドの機能を呼び出します。フロントエンドはそこでバックエンドに「foo グループの記事のリストをくれ」とか「4711 番の記事を見せてよ」と ``話す'' のです。

     そういうわけで、バックエンドは主にプロトコルか、ファイルの形式とディレクトリーの配置を定義します。前者は nntp バックエンドが NNTP でニュースにアクセスしたり nnimap バックエンドが IMAP でメールにアクセスすることを指します。また、後者は nnspool バックエンドが共通の ``スプールディレクトリー'' 形式にアクセスしたり、それととてもよく似た nnml バックエンドがファイルの形式とディレクトリーの配置によってメールにアクセスすることを指します。

     Gnus は基本的なメディアを扱いません。すべてはバックエンドによって行なわれるということができます。バックエンドは記事にアクセスするための機能の集成です。

     しかし、``バックエンド'' という用語はしばしば ``サーバー'' という意味でも使われてきました。そして ``選択方法'' (``select method'') も同じ意味で使うことができます。かように、Gnus の用語はとても混乱しています。

基本 (native)
     Gnus はいつも一つの方法 (とバックエンド) をニュースを得るための 基本 もしくはディフォルトとして使います。

外部 (foreign)
     同時に任意の数の外部グループを活動状態にすることもできます。これらはニュースを取得するための、基本でなく、二番目でもないバックエンドを使うグループです。

二番目 (secondary)
     二番目のバックエンドは、基本と外部の間くらいにあるバックエンドで、ほとんど基本と同じように動作するものです。

記事 (article)
     ニュースとして投稿されたメッセージです。

メールメッセージ (mail message)
     メールで送られたメッセージです。

メッセージ
     メールメッセージもしくはニュース記事です。

ヘッド (head)
     メッセージの最上部で、認証情報 (等) が入れられているところです。

本文 (body)
     記事の残りの部分です。ヘッドでないものはすべて本文です。

ヘッダー (header)
     記事のヘッドからの行です。

ヘッダー群 (headers)
     そのような行の集合もしくは、ヘッドの集合です。もしくは、NOV 行の集合です。

NOV
     Gnus がグループに入ると、グループのすべての未読記事のヘッダーをバックエンドに求めます。ほとんどのサーバーは News OverView 様式が使用可能で、それは普通の HEAD 様式よりもっと手短でもっと速く読んで解析 (parse) することができます。

レベル (level)
     それぞれのグループは何らかの レベル か他のもの (1-9) で購読されています。低いレベルのものは高いレベルのものより ``より'' 購読されています。実際のところ、レベル 1-5 のグループは 購読; 6-7 は 未購読; 8 は ゾンビ; 9 は 切られた と見なされます。グループをリストしたり、新しいグループを走査したりする命令はすべて数値接頭引数を 動作レベル として使います。

切られたグループ (killed groups)
     切られたグループの情報は蓄積されたり更新されたりしないので、切られたグループを購読されたグループより簡単に扱えるようになります。

ゾンビグループ (zombie groups)
     ほとんど切られたグループと同じで、それより少し死んでいるだけです。

アクティブファイル (active file)
     ニュースサーバーはどの記事を運んでいるか、どのグループが存在するかを記録しておかなければなりません。すべてのこの情報は現状ファイルに蓄積され、それはあなたが想像するように比較的大きいです。

偽グループ (bogus groups)
     .newsrc ファイルに存在するグループですが、サーバーに知られていないグループ (すなわち、それはアクティブファイルにありません) は 偽グループ です。これは、おそらく (すでに) そのグループは存在していないのでしょう。

活動化 (activating)
     サーバーにグループの情報を尋ね、未読記事の数を演算する行為は グループを活動化する と呼ばれています。非活動グループはグループバッファーに * とともに一覧表示されます。

スプール (spool)
     ニュースサーバーは、あるやり方、または他の流儀で記事をローカルに保存します。ある古い流儀の保存方法は、記事毎にたった一つのファイルを持つことです。それは伝統的なスプール (traditional spool) と呼ばれます。

サーバー (server)
     接続して、ニュース (もしくはメール) を取得することのできるグループです。

選択方法 (select method)
     バックエンド、サーバーと、仮想サーバーの設定を指定する構造です。

仮想サーバー (virtual server)
     命名された選択方法です。選択方法は (物理的) サーバーに接続するために必要な方法を定義するため、ものごとを全体として受けるのは仮想サーバーになります。

洗濯 (washing)
     バッファーを持ってきて、何らかの種類の選別機にかけることです。結果は (多かれ少なかれ) 元のものよりもよりきれいで喜ばしいものになるでしょう。

一時グループ (ephemeral groups)
     たいていのグループはどの記事を読んだかのデータを蓄積します。一時 グループはデータが溜められないグループです---グループを出ると、それは天空に消え去ります。

固定グループ (solid groups)
     これは一時グループの反対です。グループバッファーに挙げられているすべてのグループは固定グループです。

まばら記事 (sparse articles)
     gnus-build-sparse-threads の機能を使用しているときは、概略バッファーに記事の入れ場所が表示されます。

スレッド作り (threading)
     それが応答した記事の直後にその記事への応答を置くことです---階層的流儀で。

根 (root)
     スレッドの最初の記事が根です。それはスレッドのすべての記事の祖先です。

親 (parent)
     応答のある記事です。

子 (child)
     違った記事---その親 に応答する記事です。

集配 (digest)
     複数のメッセージを一つのファイルに集めたものです。もっとも普通の集配様式は RFC1153 で指定されています。

分割 (splitting)
     ある規則によってメールを分類する行為です。ときどき間違ってメールの濾過 (mail filtering) と呼ばれます。

カスタマイズ
======

すべての変数はこのマニュアルのどこか別のところで適切に説明されています。この部分は非常に良くある状況でどのように Gnus をカスタマイズすれば良いかの総合適指示先を与えるために考案されています。

遅い/高い NNTP 接続
-------------

もし Emacs をローカルのマシンで実行していて、非常に細い線の向こうのマシンからニュースを取得しているのであれば、Gnus が NNTP サーバーから取得するデータの総量を減らしたいと思うでしょう。

gnus-read-active-file
     これを nil にして下さい。そうすれば、Gnus にサーバーからアクティブファイル全体を要求することを禁止できます。このファイルはしばしば非常に大きくなっています。それに加えて、Gnus が突然とにかく現状ファイルを取得しようと決定しないことを確実にするために、 gnus-check-new-newsgroups および gnus-check-bogus-newsgroups も nil に設定しなければなりません。

gnus-nov-is-evil
     これも nil にしていなければなりません。もしそうでなければ、 NNTP サーバーから記事のヘッダーをつかんでくるのがあまり速くなりません。すべての NNTP サーバーが XOVER の機能を提供しているわけではありません。Gnus が自分自身でそれを検査します。

遅いターミナル接続。
----------

あなたは、ホームコンピューターを Emacs と Gnus を実行しているシステムにダイアルアップするために使っているとしましょう。もしあなたのモデムが遅ければ、(可能な限り) 線を伝って送られているデータの総量を減らしたいと思うでしょう。

gnus-auto-center-summary
     Gnus が常に概略バッファーを中心再設定をすることを禁止するためにこれを nil に設定して下さい。これが vertical であると、垂直方向の (vertical) 中心再設定のみをします。nil でも vertical でも無ければ、水平方向と垂直方向の両方の中心再設定を行ないます。

gnus-visible-headers
     記事に含まれるヘッダーを最小限に減らします。実際のところ、全部なくしてしまっても何とかなります---とにかく、たいていの役に立つデータは概略バッファーにあります。この変数を ^NEVVVVER や From: や、何でも好きなものに設定して下さい。

     このフックにすべての使用可能な隠匿命令を設定します:

          (setq gnus-treat-hide-headers 'head
                gnus-treat-hide-signature t
                gnus-treat-hide-citation t)

gnus-use-full-window
     これを nil に設定することで、すべてのウィンドウを小さくすることができます。これは総じてそんなに減らしません。これは、記事をどっちにしろ読みたくないということを決定する前に、少しの部分しか見る必要が無いということです。

gnus-thread-hide-subtree
     これが nil でなければ、すべての概略バッファーのスレッドは初めに隠されます。

gnus-updated-mode-lines
     これが nil であると、Gnus はバッファーのモード行に情報を入れないので、時間を節約できるでしょう。

少しのディスク容量
---------

起動ファイルは比較的大きくなるので、空き容量が少なくなってきているときはその大きさを少し小さくする必要があるでしょう。

gnus-save-newsrc-file
     これが nil であると、Gnus は決して .newsrc を保存しません---それは .newsrc.eld のみを保存します。これは、Gnus の他のニュースリーダーを使えないということです。この変数はディフォルトで t です。

gnus-read-newsrc-file
     これが nil であれば、Gnus は .newsrc を決して読みません---.newsrc.eld だけを読みます。これは、Gnus 以外のニュースリーダーを使えなくなる、ということです。この変数はディフォルトでは t です。

gnus-save-killed-list
     これが nil であると、Gnus は死んだグループのリストを保存しません。この変数を nil に設定したときは、 gnus-check-new-newsgroups を ask-server に、 gnus-check-bogus-newsgroups を nil に設定するべきでしょう。この変数はディフォルトで t です。

遅い機械
----

もし遅い機械を持っているか、もしくは単に本当に忍耐力がない時は、Gnus の実行を把握するためにできることが少しあります。

起動を速くするために gnus-check-new-newsgroups および gnus-check-bogus-newsgroups を nil に設定して下さい。概略バッファーに入ることと抜けることを速くするために gnus-show-threads と gnus-use-cross-reference、それに gnus-nov-is-evil を nil に設定して下さい。

問題解決
====

Gnus は箱から出してすぐに 非常に よく動作します---何も問題の起こることは想像できません、本当に。

オッホン。

 1. あなたのコンピュータのスイッチが入っていることを確かめて下さい。

 2. 本当に現行の Gnus 版を読み込んでいることを確認して下さい。今まで GNUS を実行してきたのであれば、Gnus が動作するように一度 Emacs を終了して再起動する必要があります。

 3. M-x gnus-version を試して下さい。もし Gnus v5.10.6 のようなものが出てきたなら、正しいファイルが読み込まれています。そうならない場合は、古い .el ファイルが散らかっています。それらを消して下さい。

 4. FAQ と how-to を読むためにヘルプグループ (グループバッファーで G h) を読んで下さい。

 5. Gnus は多くの多くの再帰構造で動作し、何らかの極端な (そして非常にまれな) 事例では、Gnus は再帰を ``あまりに深く'' 降りすぎて、Emacs があなたにビープ音を鳴らすことがあります。もしこれが起こったなら、 max-lisp-eval-depth を 500 かそれくらいの値に設定して下さい。

もし他のすべてが失敗したなら、バグとして問題を報告して下さい。

もし Gnus のバグを見つけたなら、M-x gnus-bug 命令によってそれを報告することができます。 M-x set-variable RET debug-on-error RET t RET として、それから私にバックトレースを送って下さい。私はバグを修正しようとしますが、あなたがバグを再現させる方法を正確に書いてくれたときのみ、それを修正することができます。

バグ報告では、詳細すぎることは決してありません。バグ報告をするときは、いつも M-x gnus-bug 命令を使って下さい。それを使うたびに 10Kb のメールができてしまっても、そしてあなたの環境を以前私に 500 回送ったとしてもです。

私は、記憶という種類のものはまったく持っていないことを覚えておくことも重要です。もしあなたがバグ報告を送ると、私が返答を送ります。そして、それからあなたが ``いや、そうではない! このばか者!'' とだけ送り返してくると、私はあなたが何に対して私を侮辱しているかがわかりません。常に、すべてを説明しすぎて下さい。それは私たちすべてにとってもっと簡単になります---もし私が必要なすべての情報を得られなかったら、私はあなたにメールを送ってさらなる情報を求め、その結果すべてがより多くの時間を取ることになります。

もしあなたの直面している問題が非常に視覚的で、それをうまく説明できない場合は、Emacs のウィンドウをファイルにコピーして (例えば、xwd で)、それをどこか手の届くどこかにおいて、その画像の URL をバグ報告に含めて下さい。

もしあなたがバグの修正や改善のためのパッチを寄稿して下さるのでしたら、すみませんがそのパッチは diff -u で作って下さい。

問題を報告する前にもっとデバッグしたければ、あなた自身で問題を解決してパッチを送るために edebug を使うことができるでしょう。Lisp コードのデバッグについては Elisp マニュアル (see Debugging Lisp Programs (The GNU Emacs Lisp Reference Manual)) に書かれています。edebug を始めるには、もし c を押したときにある変な振舞いが発見されるならば、第一歩は C-h k c をタイプし、ドキュメンテーション・バッファー中でハイパーリンクをクリック (Emacsのみ) して、その関数定義を参照することです。そしてその関数名の場所で M-x edebug-defun RET をタイプして Gnus に戻り、そのコードを起動するために c を押します。Lisp バッファーでは、SPC でシングルステップ動作、M-: で式を評価、 C-h v で変数を検査、q で実行を中断、あるいは c か g で実行を再開することができます。

ときどき、直接に elisp のエラーを起こさないものの、Gnus が非常に遅くなるために明らかになる問題があります。そんな場合には M-x toggle-debug-on-quit を使って、遅くなったときに C-g を押し、しかる後にバックトレースを解析して下さい (その手続きを繰り返すことは、真の問題領域の分離に役立ちます)。より上等な取り組みは elisp プロファイラー (訳注: プログラムの実行時の動きを分析する道具) ELP を使用することです。プロファイラーについてはどこか他の場所で完全に文書化されているはずですが、それを始めるために必要な手順を少々書いておきましょう。第一に、プロファイルしてみたい Gnus の部分を計測するための設定を、例えば M-x elp-instrument-package RET gnus や M-x elp-instrument-package RET message で行なって下さい。そして、遅い動作を行なわせてから M-x elp-results を押しましょう。すると、どの動作が時間を食っているかを見て、後でそれらをデバッグすることができます。動作全体が、プロファイラーの出力の中で最も遅い関数で費やされた時間よりはるかに長くかかるのは、たぶん Gnus の間違っている部分をプロファイルしたせいでしょう。プロファイルの統計をリセットするには M-x elp-reset-all を使って下さい。M-x elp-restore-all はプロファイルする動作を取り除くことになっていますが、 Gnus によって複雑にされかつ動的なコード生成の影響を受けるため、それは必ずしも完全に動作するとは限らないかもしれません。

もし援助が欲しいだけであれば、gnu.emacs.gnus で尋ねるのが良いでしょう。私はあまり役に立ちません。

また、ding メーリングリスト---ding@gnus.org に訊ねることもできます。購読するためには ding-request@gnus.org に書いて下さい。

Gnus の参照ガイド
===========

私の願いは、他の誰かが Gnus でできる何か賢いものを考え出し、その上その賢いものを書いてくれるということです。これを容易にするためには、Gnus の内部動作を記述するのが良い方法だろうと私は思いました。あと、そんなに内部じゃない動作をいくつかと、私が今やってることと。

プログラムの内部構造が変更されることはない、などと思ってはいけませんが、 Gnus とそのバックエンド間のインターフェース (これは完全に記述されている) や、スコアファイルの形式 (これも同様)、データ構造 (これは他より変更されやすいものもある)、操作用の一般メソッド、などを (細部にわたって) 定義していきます。

Gnus の有用な関数
-----------

フックなどから実行される小さな関数を書くときは、Gnus の内部関数や変数にアクセスすることは絶対必要です。以下が最もよく使われるものの一覧です。

gnus-newsgroup-name
     この変数は現在のニュースグループの名前を保持しています。

gnus-find-method-for-group
     GROUP の選択方法を返す関数です。

gnus-group-real-name
     正規の (接頭引数付きの) Gnus グループ名を受け取り、接頭引数無しの名前を返します。

gnus-group-prefixed-name
     接頭引数無しのグループ名と選択方法を受け取り、正規の (接頭引数付きの) Gnus グループ名を返します。

gnus-get-info
     GROUP のグループ情報一覧を返します。

gnus-group-unread
     GROUP の未読記事の数か、もしくはそれが分からない場合は t です。

gnus-active
     GROUP の活動登録です。

gnus-set-active
     GROUP に活動登録を設定します。

gnus-add-current-to-buffer-list
     Gnus 終了時に消去するバッファーの一覧に現在のバッファーを追加します。

gnus-continuum-version
     引数として Gnus のバージョン文字列を受け取り、浮動小数点数を返します。古いバージョンは必ず新しいバージョンよりも小さい数になります。

gnus-group-read-only-p
     GROUP が読み出し専用であるかどうかを示します。

gnus-news-group-p
     GROUP がニュースバックエンドであるかどうかを示します。

gnus-ephemeral-group-p
     GROUP が短期グループであるかどうかを示します。

gnus-server-to-method
     SERVER に対応している選択方法を返します。

gnus-server-equal
     二つの仮想サーバーが同一のものであるかどうかを示します。

gnus-group-native-p
     GROUP が基本グループであるかどうかを示します。

gnus-group-secondary-p
     GROUP が二次グループであるかどうかを示します。

gnus-group-foreign-p
     GROUP が外部グループであるかどうかを示します。

gnus-group-find-parameter
     GROUP のパラメーター一覧を返します。二つ目の引数を与えると、 GROUP 用のそのパラメーターの値を返します。

gnus-group-set-parameter
     三つの引数 GROUP, PARAMETER, VALUE を取ります。

gnus-narrow-to-body
     現在のバッファーの記事の本文を制限表示します。

gnus-check-backend-function
     二つの引数 FUNCTION, GROUP を取ります。GROUP バックエンドが FUNCTION をサポートしているなら、nil 以外を返します。

          (gnus-check-backend-function "request-scan" "nnml:misc")
          => t

gnus-read-method
     利用者に選択方法をプロンプト入力してもらいます。

バックエンドインターフェース
--------------

Gnus は NNTP やスプール、メール、仮想グループについては何にも知りません。ただ仮想サーバー virtual servers と対話する方法を知っているだけです。仮想サーバーはバックエンド back end といくつかのバックエンド変数 back end variables からなります。前者の例としては nntp, nnspool, nnmbox などがあります。後者の例としては nntp-port-number や nnmbox-directory があります。

Gnus がバックエンド---例えば nntp---に何かの情報を要求するときは、通常関数の引数として仮想サーバー名を含めます。(もしなければ、バックエンドは ``現在の'' 仮想サーバーを使用します。) 例えば、 nntp-request-list はその唯一の (省略可能な) 引数として仮想サーバーを取ります。もしこの仮想サーバーが開かれていなければ、この関数は失敗します。

仮想サーバー名は、物理的なサーバー名とは何の関係も無いことに注意して下さい。この例を見て下さい。

     (nntp "odd-one"
           (nntp-address "ifi.uio.no")
           (nntp-port-number 4324))

ここで、物理サーバー名は ifi.uio.no であるのに対し、仮想サーバー名は odd-one です。

バックエンドは複数の仮想サーバーを切り替え可能でなければなりません。標準のバックエンドはこれを、仮想サーバー環境を必要なときに取り出し・押し込みを行なう連想リストを保持することによって実現しています。

インターフェース関数は二つのグループがあります。必ず存在しなければならない必須関数 required functions と、Gnus が呼び出しを行なう前にそれが存在するかを常に確認する任意関数 optional functions です。

これらの関数はすべて、その戻り値のデータをを nntp-server-buffer (*nntpd*) バッファーに返すことが求められます。これはちょっと不運な名前付けですが、これで我慢しなければなりません。私が結果のデータ resulting data と言ったときは、そのバッファーの中のデータを指しています。戻り値 return value と言ったときは、関数呼び出しによって返される関数の値のことを言っています。関数が失敗したときは戻り値として nil を返さなくてはいけません。

バックエンドにはサーバー形式 server-forming のバックエンドであると呼ばれるものがあり、またそう呼ばれないものもあります。後者は一般には、同時には一つだけしか操作しないバックエンドで、``サーバー'' の概念がありません。このサーバーとは、グループを持ち、そのグループに情報を配送するもので、それ以上のものではありません。

Gnus はグループ名と記事番号によってそれぞれのメッセージを特定します。それら記事番号に関するちょっとした説明をすることは有益かもしれません。まず第一に、その数値は正の整数です。第二に、Gnus を混乱させることなく古い記事番号を後で ``再使用'' することは普通はできません。それは、もしあるグループがかつて 42 番の記事を持っていたとしたら、その番号で他の記事を持つことはできないか、または Gnus が混乱してしまうかもしれないということです。 (See the function nnchoke-request-update-info, Optional Back End Functions。) 第三に、記事番号はそのグループでの到着順になっていなければならないことです。とは言えメッセージの日付も到着順である必要はありませんが。

すでに前の節で、記事番号は一回使われただけで役目を終わらなければならない ``厳しい'' 制限について説明しました。しかし、記事番号の並びに抜けがあると Gnus はとても混乱してしまうので、通し 番号を付けることが有用なのかもしれません。ただし ``再使用不可'' の制限があるので、いつでも番号の抜けを回避できるとは限りません。また、可能な限り記事番号を 1 から始めることは、番号を使い切ってしまうことを避けるために役立ちます。

慣例として、バックエンドは nnなんたら と名付けられますが、 Gnus には nnheader.el、nnmail.el および nnoo.el のように、いくつかのバックエンドではない nnかんたら があることに注意して下さい。

ここでの例と定義では、想像上のバックエンド nnchoke を引き合いに出すことにします。

必須バックエンド関数
..........

(nnchoke-retrieve-headers ARTICLES &optional GROUP SERVER FETCH-OLD)

     ARTICLES は記事番号の範囲かあるいは Message-ID のリストです。現在のバックエンドではどちらも完全にはサポートしていません---連続した記事番号 (のリスト) だけで、多くのバックエンドでは Message-ID による取得はサポートしていません。でもどちらもサポートしていくべきでしょう。

     結果のデータは HEAD か NOV 行のいずれかであり、戻り値はこれを反映した headers か nov のいずれかでなくてはなりません。これは今後、HEAD と NOV 行が混在する various に拡張されるかもしれませんが、現在の Gnus ではサポートされていません。

     FETCH-OLD が nil 以外であれば、ある意味での ``余分なヘッダー'' を取得しようとします。これは通常、articles の中の最小番号の記事よりも小さい記事から (少なくとも) FETCH-OLD 個の余分なヘッダーを取得し、空所を埋めることを行ないます。もしバックエンドがこの要求に従うことを煩わしいと思った場合には、このパラメーターの存在は無視されることもあります。この値が nil でも数値でもなければ、最大限の取得を行ないます。

     これが HEAD の例です。

          221 1056 Article retrieved.
          Path: ifi.uio.no!sturles
          From: sturles@ifi.uio.no (Sturle Sunde)
          Newsgroups: ifi.discussion
          Subject: Re: Something very droll
          Date: 27 Oct 1994 14:02:57 +0100
          Organization: Dept. of Informatics, University of Oslo, Norway
          Lines: 26
          Message-ID: <38o8e1$a0o@holmenkollen.ifi.uio.no>
          References: <38jdmq$4qu@visbur.ifi.uio.no>
          NNTP-Posting-Host: holmenkollen.ifi.uio.no
          .

     つまり、戻り値が headers であるときは、データバッファーにこれらヘッダーがいくつかあるということを意味します。

     これがそのバッファーの BNF 定義です。

          headers        = *head
          head           = error / valid-head
          error-message  = [ "4" / "5" ] 2number " " <error message> eol
          valid-head     = valid-message *header "." eol
          valid-message  = "221 " <number> " Article retrieved." eol
          header         = <text> eol

     (ここで使った BNF の版は RFC822 で使われているものです。)

     もし戻り値が nov であれば、データバッファーには network overview database 行が含まれてなくてはなりません。これは基本的には複数の欄をタブで区切ったものです。

          nov-buffer = *nov-line
          nov-line   = field 7*8[ <TAB> field ] eol
          field      = <text except TAB>

     これらの欄にどのようなものが含まれるかをより詳しく見たければ、 Headers を参照して下さい。

(nnchoke-open-server SERVER &optional DEFINITIONS)

     ここでの SERVER は仮想サーバー名です。DEFINITIONS はこの仮想サーバーを定義する (VARIABLE VALUE) 組のリストです。

     もしサーバーを開くことができなければ、エラーはシグナルでは通知されません。そしてバックエンドは、それ以後のこのサーバーへの接続要求を拒否することもできます。実際、そうすべきです。

     もしそのサーバーがすでに開いていれば、この関数は nil 以外の値を返さなければなりません。このとき、返される結果のデータはありません。

(nnchoke-close-server &optional SERVER)

     SERVER への接続を閉じ、これに関連するすべてのソースを開放します。もし何らかの理由でサーバーを閉じることができなければ、nil を返します。

     返される結果のデータはありません。

(nnchoke-request-close)

     すべてのサーバーの接続を閉じ、バックエンドが保有しているすべてのソースを開放します。このバックエンドによって作成されたバッファーはすべて削除されます。(nntp-server-buffer は削除されませんが。) この関数は通常 Gnus が終了するときにのみ呼び出されます。

     返される結果のデータはありません。

(nnchoke-server-opened &optional SERVER)

     もし SERVER が現在の仮想サーバーで、その物理サーバーへの接続が生きていれば、この関数は nil 以外の値を返します。この関数はどんな場合でも、接続が失われたサーバーへの再接続を行なうことはありません。

     返される結果のデータはありません。

(nnchoke-status-message &optional SERVER)

     この関数は SERVER からの最後のエラーメッセージを返します。

     返される結果のデータはありません。

(nnchoke-request-article ARTICLE &optional GROUP SERVER TO-BUFFER)

     この関数の結果のデータは、ARTICLE で指定された記事です。この指定は Message-ID か番号のいずれかです。Message-ID による記事の取得を実装するかどうかは任意ですが、可能であると嬉しいですね。

     TO-BUFFER が nil 以外であれば、結果のデータは通常のデータバッファーの代わりに、このバッファーに返されます。これにより多量のデータをあるバッファーから別のバッファーにコピーすることを避けることができ、そして Gnus は通常、記事バッファーに直接記事を挿入するように要求しています。

     もし可能であるのなら、この関数は、car が取得した記事のあるグループ名で、cdr が記事番号である cons セルを返すべきです。これにより Message-ID によって記事を取得したとき、Gnus が本当のグループと記事番号を知ることができるようになるでしょう。これが不可能な場合には、記事の取得が成功したときは t を返します。

(nnchoke-request-group GROUP &optional SERVER FAST)

     GROUP のデータを取得します。この関数は、GROUP を現在のグループにする、という副作用もあります。

     FAST があれば、便利なデータを返す面倒を行なわずに、単に GROUP を現在のグループにします。

     これが結果のデータの例と、それの定義です。

          211 56 1000 1059 ifi.discussion

     最初の数値は状態で、これは 211 でなくてはなりません。次はそのグループにある記事の総数、最小の記事番号、最大の記事番号、そして最後がグループ名です。記事の総数は、最大・最小記事番号から単純に考えられる数よりも小さいことがあることに注意して下さい。いくつかの記事は取り消されているかもしれません。Gnus は総数は単に捨ててしまっているので、(もしそれが問題となるときに) 正しい値を生成する面倒を負うべきかどうかは、読者への課題として残してあります。もしそのグループに記事が無ければ、最小記事番号は 1、最大は 0 として報告されなければなりません。

          group-status = [ error / info ] eol
          error        = [ "4" / "5" ] 2<number> " " <Error message>
          info         = "211 " 3* [ <number> " " ] <string>

(nnchoke-close-group GROUP &optional SERVER)

     GROUP を閉じ、それに接続されているすべてのソースを開放します。これはほとんどのバックエンドでは何もすることがないでしょう。

     返される結果のデータはありません。

(nnchoke-request-list &optional SERVER)

     SERVER 上で利用可能なすべてのグループの一覧を返します。これは 全部 という意味です。

     これが、たった二つしかグループを持っていないサーバーからの例です。

          ifi.test 0000002200 0000002000 y
          ifi.discussion 3324 3300 n

     各行にはグループ名があり、そしてそのグループ内の最大の記事番号、最小の記事番号、そして最後にフラグです。もしそのグループに記事が無ければ、最小記事番号は 1、最大は 0 として報告されなければなりません。

          active-file = *active-line
          active-line = name " " <number> " " <number> " " flags eol
          name        = <string>
          flags       = "n" / "y" / "m" / "x" / "j" / "=" name

     フラグは、そのグループが読み出し専用 (n) であるか、司会者付き (m) であるか、死んでいる (x) か、どこか他のグループの別名 (=other-group) であるか、上記のどれでもない (y) か、ということを示しています。

(nnchoke-request-post &optional SERVER)

     この関数は、現在のバッファーを投稿します。これは投稿が成功したかどうかを返しても構いませんが、必須ではありません。例えば、投稿が非同期に行なわれるのであれば、この関数が終了した時点では投稿は普通完了していません。その場合この関数は、投稿を完了させることができないとき、それをはっきりと利用者に知らせる見張り関数のようなものを設定するべきでしょう。

     この関数から返される結果のデータはありません。

任意バックエンド関数
..........

(nnchoke-retrieve-groups GROUPS &optional SERVER)

     GROUPS はグループのリストであり、この関数はそれら全部のグループのデータを要求します。どうやってそれを行なうかは Gnus の知ったことではありませんが、これはできるだけ迅速な方法で行なわなければなりません。

     この関数の戻り値は active か group のいずれかで、結果のデータの形式が何であるかを示します。前者は nnchoke-request-list によるデータと同じ形式であり、一方後者は nnchoke-request-group が与えるものと同じ形式の行でバッファーは埋められます。

          group-buffer = *active-line / *group-status

(nnchoke-request-update-info GROUP INFO &optional SERVER)

     Gnus グループ情報 (see Group Info) が変更箇所としてバックエンドに渡されます。これはバックエンドが (仮想グループや imap グループの場合のように) 本当にすべての情報を持っている場合に便利になります。この関数は、その要求に適合させる情報を破壊的に置き換え、nil ではない値を返さなければなりません (例外的に、nntp-request-update-info はネットワーク資源を浪費しないように、常に nil を返します)。

     この関数から返される結果のデータはありません。

(nnchoke-request-type GROUP &optional ARTICLE)

     利用者が ``ニュースを送信する'' 命令 (例えば、概略バッファーで F) を実行したとき、Gnus は利用者がフォローアップしようとしている記事がニュースであるかメールであるかを知らなくてはなりません。この関数は GROUP の中の ARTICLE がニュースであれば news を、メールであれば mail を、その種別を決定できなければ unknown を返します。(ARTICLE 引数は、メールグループとニュースグループがごちゃまぜになってるかもしれない nnvirtual において必要です。) GROUP と ARTICLE は両方とも nil であるかもしれません。

     この関数から返される結果のデータはありません。

(nnchoke-request-set-mark GROUP ACTION &optional SERVER)

     記事の印を設定/消去/追加します。普通は Gnus は記事の印 (既読、可視、期限切れ消去など) を内部で扱い、~/.newsrc.eld に保存します。しかし、バックエンドには (IMAP のように) 記事のすべての情報をサーバーに収めるので、Gnus は印の情報をサーバーに伝達しなければならないものがあります。

     ACTION はこのような様式の印設定の要求のリストです:

          (RANGE ACTION MARK)

     RANGE は印を付けたい記事の範囲です。ACTION は add または del で、印を追加したり消します (言及されていないすべての印は保存します)、印の消去 (言及されていない印は保存します) です。 MARK は印のリストです。それぞれの印はシンボルです。現在使われている印は read, tick, reply, expire, killed, dormant, save, download, unsend, forward および recent ですが、もし可能なら、あなたのバックエンドはこれらに制限をするべきではありません。

     矛盾する動作が指定されたとき、リストの最後の動作が効力を持つものになります。すなわち、動作に記事 1 に 可視 印を追加する要求があり、リストの後で同じ記事から印を消去することを要求していれば、印は実際に消去されるべきです。

     動作リストの例です:

          (((5 12 30) 'del '(tick))
           ((10 . 90) 'add '(read expire))
           ((92 94) 'del '(read)))

     関数は印を設定できなかった記事の範囲を返すべきです (現在はまったく使われていません)。

     この関数からは結果のデータはありません。

(nnchoke-request-update-mark GROUP ARTICLE MARK)

     もし利用者が、このバックエンドの気に入らない印を設定しようとしたら、この関数が印を変更することができます。Gnus はもとの MARK の代わりに、この関数が返したものを ARTICLE への印として使います。バックエンドが気にすることが特になければ、元の MARK を返さなければなりません。 nil やその他のゴミを返してはいけません。

     私が知っているこれのこれの利用法は、nnvirtual が行なっていることだけです---もし構成グループが自動期限切れ消去可能であれば、この仮想グループで既読の印を付けると、結果としてその記事に期限切れ消去の印が付けられます。

     この関数から返される結果のデータはありません。

(nnchoke-request-scan &optional GROUP SERVER)

     この関数は、バックエンドが到着記事を確認する要求を行なうときにいつでも (Gnus かそれ以外によって)、あれやこれやと呼び出されることがあります。メールバックエンドはこの関数が起動されたとき、典型的にはスプールファイルを読むか POP サーバーに問い合わせにいきます。GROUP は特に気に留める必要はありません---もしバックエンドが、一つだけのグループを走査するのは大変すぎると判断した場合には、全グループの全走査を行なっても構いません。ですが、実用的にできればそれを局所的に閉じておく方が良いでしょう。

     この関数に返される結果のデータはありません。

(nnchoke-request-group-description GROUP &optional SERVER)

     この関数によって返される結果のデータは、GROUP の説明です。

          description-line = name <TAB> description eol
          name             = <string>
          description      = <text>

(nnchoke-request-list-newsgroups &optional SERVER)

     この関数によって返される結果のデータは、サーバー上で利用できるグループすべての説明です。

          description-buffer = *description-line

(nnchoke-request-newgroups DATE &optional SERVER)

     この関数から返される結果のデータは、date 以降に作成されたすべてのグループです。date は通常の人間が読める日付の形式 (すなわち、メールやニュースのヘッダーで使われる形式で、ディフォルトでは関数 message-make-date から返されたもの) です。データは active バッファーの形式でなければなりません。

     この関数が ``多すぎる'' グループを返してもオーケイです。いくつかのバックエンドは新しいグループを見つけるよりも、楽をしてすべてのグループのリストを返すかもしれません。しかしバックエンドが返す多くのグループに対してこれ (訳注: 新しいグループとして扱うこと) をしてはいけません。普通、利用者自身が作ったグループならば多すぎることはないでしょう。ですから nnml とそれに類するものはたぶん心配ありません。しかし nntp のようなバックエンドではグループはサーバーによって作られていますから、多くのグループが返ってくることがありえます。

(nnchoke-request-create-group GROUP &optional SERVER)

     この関数は、GROUP という名前の空のグループを作成します。

     返される結果のデータはありません。

(nnchoke-request-expire-articles ARTICLES &optional GROUP SERVER FORCE)

     この関数は、ARTICLES の範囲のすべての記事に対して期限切れ消去処理を行ないます。(ARTICLES は現在は記事番号の単純なリストです。) この関数で消去される前の、記事がどれだけ古い記事であるかの決定はバックエンドに任されています。FORCE が nil 以外であれば、それがどんなに新しいものであっても、すべての ARTICLES が消去されます。

     この関数は削除しなかった、あるいは削除することができなかった記事のリストを返します。

     返される結果のデータはありません。

(nnchoke-request-move-article ARTICLE GROUP SERVER ACCEPT-FORM &optional LAST)

     この関数は ARTICLE (番号) を、GROUP から ACCEPT-FORM を呼び出して移動します。

     この関数は、問題の記事を移動させるための準備として、記事に付加されたヘッダー行をすべて削除し、一般に記事を「きれいさっぱり」にします。そして ``きれいな'' 記事のあるバッファーで ACCEPT-FORM を eval します。これは本当に複製を行ないます。もし eval が nil 以外の値を返したら、その記事は削除されません。

     LAST が nil であれば、この直後にさらに要求が発行される見込みが高い、という意味になり、これによって最適化がいくらかできるようになります。

     この関数は、グループ名が car で、その記事の移動先の記事番号が cdr である cons セルを返します。

     そのグループは、バックエンドがそのグループへの記事の収納を要求する前に存在しなけれまなりません。

     返される結果のデータはありません。

(nnchoke-request-accept-article GROUP &optional SERVER LAST)

     この関数は、現在のバッファーを取り、それを GROUP の中に挿入します。 LAST が nil であれば、この関数へのさらなる呼び出しが直ちに行なわれるという意味です。

     この関数はグループ名が car で、その記事の移動先の記事番号が cdr である cons セルを返します。

     返される結果のデータはありません。

(nnchoke-request-replace-article ARTICLE GROUP BUFFER)

     この関数は ARTICLE (番号) を GROUP から削除し、代わりに BUFFER をそこに挿入します。

     返される結果のデータはありません。

(nnchoke-request-delete-group GROUP FORCE &optional SERVER)

     この関数は GROUP を消去します。もし FORCE があれば、そのグループ内のすべての記事を本当に消去し、そしてそのグループ自身を消去します。 (もし ``グループ自身'' というものがあれば。)

     返される結果のデータはありません。

(nnchoke-request-rename-group GROUP NEW-NAME &optional SERVER)

     この関数は GROUP から NEW-NAME に名前を変更します。 GROUP 内にある記事はすべて NEW-NAME に移動します。

     返される結果のデータはありません。

エラーメッセージ表示
..........

バックエンドはエラー状況を報告するのに nnheader-report を使わなくてはなりません---要求を実行できないときにエラーを生起させてはいけません。この関数の最初の引数はバックエンド名のシンボルで、残りは、複数の引数があれば format への引数として解釈され、一つであればただの文字列になります。この関数は常に nil を返さなくてはなりません。

     (nnheader-report 'nnchoke "You did something totally bogus")

     (nnheader-report 'nnchoke "Could not request group %s" group)

一方 Gnus は、サーバーから nil を返されたときに nnheader-get-report を呼び出し、そしてこの関数が問題のバックエンドに対して最後に報告されたメッセージを返します。この関数は一つの引数---サーバーのシンボルを取ります。

内部的には、これらの関数は BACK-END-status-string にアクセスます、つまり nnchoke バックエンドはそのエラーメッセージを nnchoke-status-string に格納します。

新しいバックエンドを書く
............

多くのバックエンドはとても類似しています。 nnml は nnspool にとても似ていますが、サーバー上の記事を編集することができます。nnmh は nnml にとても似ていますが、これはアクティブファイルを使わず、概要データベースも保持しません。 nndir は nnml にとても似ていますが、これには ``グループ'' の概念はなく、記事の修正はできません。

新しいバックエンドを書くときに他のバックエンドから関数を ``継承'' することが可能であってほしい、と思うのは理に適っています。そしてまさに、あなたがそうしたければ、それができるのです。(あなたがそうしたくなければしなくても良いですよ、もちろん。)

すべてのバックエンドは公開変数と公開関数を、nnoo と呼ばれるパッケージを使って宣言します。

他のバックエンドから関数を継承するには (そして現在のバックエンドから他のバックエンドに関数を継承できるようにするには)、以下のマクロを使用しなければなりません。

nnoo-declare
     このマクロは、最初の引数を、その後に続く引数の子供であることを宣言します。例えば、

          (nnoo-declare nndir
            nnml nnmh)

     これで nndir は、nnml と nnmh の両方から関数を継承しようとしていることを宣言します。

defvoo
     このマクロは defvar と同義ですが、その変数を公開サーバー変数として登録します。ほとんどの状態指向型の変数は defvar ではなく defvoo によって宣言するべきです。

     通常の defvar 引数に加えて、このマクロは親バックエンドの変数のリストを取り、この関数がそのバックエンド内で実行されるときに変数を置き換えます。

          (defvoo nndir-directory nil
            "Where nndir will look for groups."
            nnml-current-directory nnmh-current-directory)

     これは nndir のために nnml の関数が呼び出されたときに、 nnml-current-directory は nndir-directory に設定されるという意味です。(nnmh も同様です。)

nnoo-define-basics
     このマクロは、ほとんど全部のバックエンドが持つべき共通関数をいくつか定義します。

          (nnoo-define-basics nndir)

deffoo
     このマクロはまさに defun のようなもので、同一の引数を取ります。通常の defun 処理に加えて、このマクロはその関数を公開しているものとして登録し、他のバックエンドがそれを継承できるようにします。

nnoo-map-functions
     このマクロは現在のバックエンドの関数から親バックエンドの関数への置き換えを行なえるようにします。

          (nnoo-map-functions nndir
            (nnml-retrieve-headers 0 nndir-current-group 0 0)
            (nnmh-request-article 0 nndir-current-group 0 0))

     これは nndir-retrieve-headers が呼び出されたとき、一番目、三番目、四番目の引数が nnml-retrieve-headers に渡され、一方、二番目の引数は nndir-current-group の値として設定される、という意味です。

nnoo-import
     このマクロは他のバックエンドから関数を取り込みます。これは単にまだ定義されていない関数を定義するだけなので、ソースファイルの最後の処理として書かなければなりません。

          (nnoo-import nndir
            (nnmh
             nnmh-request-list
             nnmh-request-newgroups)
            (nnml))

     これは、nndir-request-list への呼び出しは単に nnmh-request-list に引き渡され、一方、nnml の公開関数でまだ nndir で定義されていないものをここで定義します。

以下は nndir バックエンドのちょっと短縮した版です。

     ;;; nndir.el --- single directory newsgroup access for Gnus
     ;; Copyright (C) 1995,96 Free Software Foundation, Inc.

     ;;; Code:

     (require 'nnheader)
     (require 'nnmh)
     (require 'nnml)
     (require 'nnoo)
     (eval-when-compile (require 'cl))

     (nnoo-declare nndir
       nnml nnmh)

     (defvoo nndir-directory nil
       "Where nndir will look for groups."
       nnml-current-directory nnmh-current-directory)

     (defvoo nndir-nov-is-evil nil
       "*Non-nil means that nndir will never retrieve NOV headers."
       nnml-nov-is-evil)

     (defvoo nndir-current-group ""
       nil
       nnml-current-group nnmh-current-group)
     (defvoo nndir-top-directory nil nil nnml-directory nnmh-directory)
     (defvoo nndir-get-new-mail nil nil nnml-get-new-mail nnmh-get-new-mail)

     (defvoo nndir-status-string "" nil nnmh-status-string)
     (defconst nndir-version "nndir 1.0")

     ;;; Interface functions.

     (nnoo-define-basics nndir)

     (deffoo nndir-open-server (server &optional defs)
       (setq nndir-directory
             (or (cadr (assq 'nndir-directory defs))
                 server))
       (unless (assq 'nndir-directory defs)
         (push `(nndir-directory ,server) defs))
       (push `(nndir-current-group
               ,(file-name-nondirectory
                 (directory-file-name nndir-directory)))
             defs)
       (push `(nndir-top-directory
               ,(file-name-directory (directory-file-name nndir-directory)))
             defs)
       (nnoo-change-server 'nndir server defs))

     (nnoo-map-functions nndir
       (nnml-retrieve-headers 0 nndir-current-group 0 0)
       (nnmh-request-article 0 nndir-current-group 0 0)
       (nnmh-request-group nndir-current-group 0 0)
       (nnmh-close-group nndir-current-group 0))

     (nnoo-import nndir
       (nnmh
        nnmh-status-message
        nnmh-request-list
        nnmh-request-newgroups))

     (provide 'nndir)

新しいバックエンドを Gnus に繋げる
....................

あなたの新しいバックエンドを Gnus で使いはじめるのはとても簡単です---単に gnus-declare-backend 関数で宣言するだけです。これはバックエンドを gnus-valid-select-methods 変数に追加します。

gnus-declare-backend は二つの引数を取ります---バックエンドの名前と適当な数の能力 abilities です。

これが例です。

     (gnus-declare-backend "nnchoke" 'mail 'respool 'address)

そして上記の行は nnchoke.el ファイルに入れます。

能力には以下のものがあります。

mail
     これはメール風バックエンドです---フォローアップは (たいていは) メールで送られます。

post
     これはニュース風バックエンドです---フォローアップは (たいていは) ニュースで送られます。

post-mail
     このバックエンドはメールとニュースの両方をサポートします。

none
     これはニュースでもメールでもないバックエンドです---まったく違った何かです。

respool
     これは再スプールをサポートします---というよりは、その元の記事とグループを修正することができます。

address
     仮想サーバー名の中にサーバーの名前が含まるということです。これはほとんど全部のバックエンドで必要になります。

prompt-address
     グループバッファーで B などでこの命令を実行したとき、利用者はアドレスのプロンプト入力を求められます。これは例えば、nntp のようなバックエンドでは必要で、nnmbox では必要ではありません。

メール風バックエンド
..........

メールバックエンドがその他のバックエンドに対して一線を画している点は、ほとんどのメールバックエンドは nnmail.el の中の共通関数に強く依存しているという点です。例えば、nnml-request-scan の定義はこのようになります。

     (deffoo nnml-request-scan (&optional group server)
       (setq nnml-article-file-alist nil)
       (nnmail-get-new-mail 'nnml 'nnml-save-nov nnml-directory group))

単に nnmail-get-new-mail にいくつか引数を与えて呼び出すだけで、 nnmail がメールの移動や分離をすべての面倒を見てくれます。

この関数は四つの引数を取ります。

method
     これは、この呼び出しをどのバックエンドが責任を負うかを指示するシンボルです。

exit-function
     この関数は分離が実行された後に呼び出されます。

temp-directory
     一時ファイルを格納する場所です。

group
     この省略可能な引数は、分離が一つのグループに対してのみ実行されるべきであるときのグループ名です。

nnmail-get-new-mail は各記事を保存するために BACK-END-save-mail を呼び出します。 BACK-END-active-number はこの記事に割り当てられた記事番号を調べるために呼び出されます。

この関数は次の変数も使用します。 BACK-END-get-new-mail (このバックエンドの新着メールを調べるかどうか) と、新しいアクティブファイルを生成するための BACK-END-group-alist および BACK-END-active-file です。 BACK-END-group-alist グループのアクティブ連想リストで、以下のようなものです。

     (("a-group" (1 . 10))
      ("some-group" (34 . 39)))

スコアファイルの構文
----------

スコアファイルは簡単に分析可能で、しかし非常に柔軟なように意図されています。それには Emacs Lisp のリストと同じ読み込み構文な様なものがその指定に合うだろうということが決定されました。

これは良くあるスコアファイルです:

     (("summary"
       ("win95" -10000 nil s)
       ("Gnus"))
      ("from"
       ("Lars" -1000))
      (mark -100))

スコアファイルの BNF 定義です。

     score-file      = "" / "(" *element ")"
     element         = rule / atom
     rule            = string-rule / number-rule / date-rule
     string-rule     = "(" quote string-header quote space *string-match ")"
     number-rule     = "(" quote number-header quote space *number-match ")"
     date-rule       = "(" quote date-header quote space *date-match ")"
     quote           = <ascii 34>
     string-header   = "subject" / "from" / "references" / "message-id" /
                       "xref" / "body" / "head" / "all" / "followup"
     number-header   = "lines" / "chars"
     date-header     = "date"
     string-match    = "(" quote <string> quote [ "" / [ space score [ "" /
                       space date [ "" / [ space string-match-t ] ] ] ] ] ")"
     score           = "nil" / <integer>
     date            = "nil" / <natural number>
     string-match-t  = "nil" / "s" / "substring" / "S" / "Substring" /
                       "r" / "regex" / "R" / "Regex" /
                       "e" / "exact" / "E" / "Exact" /
                       "f" / "fuzzy" / "F" / "Fuzzy"
     number-match    = "(" <integer> [ "" / [ space score [ "" /
                       space date [ "" / [ space number-match-t ] ] ] ] ] ")"
     number-match-t  = "nil" / "=" / "<" / ">" / ">=" / "<="
     date-match      = "(" quote <string> quote [ "" / [ space score [ "" /
                       space date [ "" / [ space date-match-t ] ] ] ] ")"
     date-match-t    = "nil" / "at" / "before" / "after"
     atom            = "(" [ required-atom / optional-atom ] ")"
     required-atom   = mark / expunge / mark-and-expunge / files /
                       exclude-files / read-only / touched
     optional-atom   = adapt / local / eval
     mark            = "mark" space nil-or-number
     nil-or-number   = "nil" / <integer>
     expunge         = "expunge" space nil-or-number
     mark-and-expunge = "mark-and-expunge" space nil-or-number
     files           = "files" *[ space <string> ]
     exclude-files   = "exclude-files" *[ space <string> ]
     read-only       = "read-only" [ space "nil" / space "t" ]
     adapt        = "adapt" [ space "ignore" / space "t" / space adapt-rule ]
     adapt-rule      = "(" *[ <string> *[ "(" <string> <integer> ")" ] ")"
     local           = "local" *[ space "(" <string> space <form> ")" ]
     eval            = "eval" space <form>
     space           = *[ " " / <TAB> / <NEWLINE> ]

スコアファイルの認識不可能な要素は無視されるべきですが、捨てられるわけではありません。

ご覧の通り、空白が必要ですが、空白の量と型は無関係です。これはスコアファイルの様式はプログラマーに任されているということです---すべてを一つの長ーーい行に吐き出すのが簡単であれば、それは構いません。

いろいろなアトムの意味はこのマニュアルのどこかで説明されています (see Score File Format)。

ヘッダー
----

内部的には Gnus は不思議な流儀で、NOV 様式に対応する記事のヘッダーを溜めておく様式を使います。ある人は、作者が NOV の仕様を見て恥じること無くすべてを 盗んだ と思うかもしれませんが、その人は正しいです。

ヘッダー は非常に負担のかけられすぎた語です。 ``ヘッダー'' は RFC1036 では記事の頭の行のこと (例えば、From) を話すのに用いられています。それは多くの人から ``ヘッド''---``ヘッダーと本文'' の同義語として使われています。(これは、私の意見では避けられるべきです。) そして、Gnus は内部では ``ヘッダー'' と呼ぶ様式を使っており、私はここでそれについて説明します。これは九つの要素からなるベクトルで、基本的に、それぞれのヘッダー (あ痛) が一つの空き場所を占めています。

これらの空き場所は、順番に: number, subject, from, date, id, chars, lines, xref, extra です。これらの空き場所に触って設定するマクロがあります---それらはすべて、それぞれ mail-header- と mail-header-set- いう予想される名前を持っています。

extra の場所はヘッダー/値の対の連想リストである以外はこれらのすべての場所は文字列です (see To From Newsgroups)。

範囲
--

GNUS は私には非常に役に立つと思われる概念を導入しましたので、私はそれをたくさん使い、かなり念入りに作り上げてきました。

質問は単純です: もしあなたが大量の数値により同一性を保証される もの (object) (乱暴な 例を挙げると、記事がそうです) を ``含まれている'' として見なしたいときは、普通の連続的行為はあまり役に立ちません。(長さ 200,000 の連続物は少し息が長すぎます。)

これの解決策は質問と同じくらい単純です。単にその連続物を壊せば良いだけです。

     (1 2 3 4 5 6 10 11 12)

は次のものに変形されます。

     ((1 . 6) (10. 12))

あの嫌な (13. 13) のような要素を避けるために、それのみの もの (object) を示すために 13 は有効な要素になっています。

     ((1 . 6) 7 (10 . 12))

これは二つの範囲を比較してそれが等価 (equal) であるかを調べることは少し手のこんだことになります:

     ((1 . 5) 7 8 (10 . 12))

と

     ((1 . 5) (7. 8) (10 . 12))

は等価です。実際のところ、下降しないリストは範囲です:

     (1 2 3 4 5)

は完全に有効な範囲です。とても息の長いものですが。これも有効です:

     (1 . 5)

そして、これは前の範囲と等価です。

これは範囲の BNF 定義です。もちろん、数値の意味上の要求は下降していないということは覚えておく必要があります。(任意の回数の同じ数値の繰り返しは許されていますが、範囲の扱いからは消え去る傾向があります。)

     range           = simple-range / normal-range
     simple-range    = "(" number " . " number ")"
     normal-range    = "(" start-contents ")"
     contents        = "" / simple-range *[ " " contents ] /
                       number *[ " " contents ]

Gnus は現在のところ既読記事と記事の印の情報を付けておくために範囲を使っています。私は 次の権力者 が私にさせてくれるのであれば、C で数の範囲の実装を計画しています。(私はまだその人に尋ねていません。と言うのは、私はそれを普通の連続物に変換し直さないで世の中を完全に範囲に基づいたものにするためにもう少し考える必要があるからです。)

グループ情報
------

Gnus はグループのすべての永続情報を group info リストに保存します。このリストの長さは 3 から 6 (もしくはもっと) の要素で徹底的にグループを記述します。

ここにあるのはグループ情報 (group info) の二つの例です。一つは非常に単純なグループで、二つめはもっと複雑なものです:

     ("no.group" 5 ((1 . 54324)))

     ("nnml:my.mail" 3 ((1 . 5) 9 (20 . 55))
                     ((tick (15 . 19)) (replied 3 6 (19 . 3)))
                     (nnml "")
                     ((auto-expire . t) (to-address . "ding@gnus.org")))

最初の要素は グループ名 です---どのようにしろ、Gnus がそれによってグループを知っているものです。二番目の要素は 購読度 で、普通は小さな整数です。(それは 階級 になることもできます。それは、コンスセルで、car がレベルで、cdr がスコアです。) 三番目の要素は既読記事の範囲のリストです。四番目の要素はいろいろな種類の記事の印のリストのリストです。五番目の要素は選択方法です (もしくは、こちらの方が良いのであれば仮想サーバーです)。六番目の要素は グループパラメーター のリストで、この部分はそのためにあります。

最後の三つの要素はどれでも、必要が無ければ存在しないこともあります。実際、グループの非常に大部分は最初の三つの要素だけを持ち、それはたくさんのコンスセルを節約することができます。

これはグループ情報様式の BNF 定義です:

     info          = "(" group space ralevel space read
                     [ "" / [ space marks-list [ "" / [ space method [ "" /
                     space parameters ] ] ] ] ] ")"
     group         = quote <string> quote
     ralevel       = rank / level
     level         = <integer in the range of 1 to inf>
     rank          = "(" level "." score ")"
     score         = <integer in the range of 1 to inf>
     read          = range
     marks-lists   = nil / "(" *marks ")"
     marks         = "(" <string> range ")"
     method        = "(" <string> *elisp-forms ")"
     parameters    = "(" *elisp-forms ")"

実のところ法則 marks は嘘です。 marks は <string> が range の上に構成されているものですが、疑似 BNF でそれを現すのは不愉快なものです。

もし Gnus 情報を持っていて、要素を調べたいのときは、Gnus はそれらの要素を取得/設定 (get/set) するための一連のマクロを提供しています。

gnus-info-group
gnus-info-set-group
     グループ名を取得/設定 (get/set) します。

gnus-info-rank
gnus-info-set-rank
     グループの階級 (rank) を取得/設定します (see Group Score)。

gnus-info-level
gnus-info-set-level
     グループのレベルを取得/設定します。

gnus-info-score
gnus-info-set-score
     グループスコアを取得/設定します (see Group Score)。

gnus-info-read
gnus-info-set-read
     既読記事の範囲を取得/設定します。

gnus-info-marks
gnus-info-set-marks
     印し付き記事の範囲のリストを取得/設定します。

gnus-info-method
gnus-info-set-method
     グループ選択方法を取得/設定します。

gnus-info-params
gnus-info-set-params
     グループパラメーターを取得/設定します。

すべての取得関数は一つの引数を取ります---情報のリストです。設定関数は二つの引数を取ります---情報リストと新しい値です。

グループ情報の最後の三つの要素は強制的なものではないので、要素を設定する前にグループ情報を拡張する必要があるかもしれません。もしこれが必要な場合は、これが自動的に起こるために nil でない三番目の引数を三つの最終設定関数に与えるだけです。

拡張対話
----

Gnus は Emacs の標準の interactive 指定をシンボル接頭引数を簡単に使えるために少し拡張しています (see Symbolic Prefixes)。これはその使い方の例です:

     (defun gnus-summary-increase-score (&optional score symp)
       (interactive (gnus-interactive "P\ny"))
       ...
       )

最上の方法は gnus-interactive を式 interactive を返すマクロとして実装することでしょうが、これは Emacs は関数が対話的であるかどうかをラムダ式に対して単純に assq を行なうことにより調べることから不可能です。

この関数は (ほとんど) すべての interactive 指定を受付けますが、もう少し加えます。

y
     現在の接頭引数シンボル---変数 gnus-current-prefix-symbol です。

Y
     現在の接頭引数シンボルのリストです---変数 gnus-current-prefix-symbol です。

A
     現在の記事番号です---関数 gnus-summary-article-number です。

H
     現在の記事ヘッダーです---関数 gnus-summary-article-header です。

g
     現在のグループ名です---関数 gnus-group-group-name です。

Emacs/XEmacs コード
----------------

Gnus は Emacs, XEmacs と Mule で動作するので、そのうちの一つを主環境とすることに決めました。私は Emacs を選びました。私が XEmacs や Mule を好きではないということではなく、それがアルファベットで最初に来たからです。

これは Gnus は Emacs でまったく警告なくバイトコンパイルできるのに対して、 XEmacs はバイトコンパイルをしている間にギガバイトくらいの警告を出すということです。私は些細な失敗を見つけ出すことを助けるためにバイトコンパイルの警告を使っているので、それは非常に役に立ちます。

私は継続的に Emacs の関数の界面 (interface) を使ってきましたが、関数には Gnus の別名関数 (alias) を使ってきました。例を出しましょう: Emacs は関数 run-at-time を定義していますが、XEmacs は関数 start-itimer を定義しています。そこで私は gnus-run-at-time と呼ばれる関数を定義し、それは Emacs の run-at-time と同じ引数を取ります。Gnus を Emacs で実行しているときは、前の関数は単に後のものの別名関数 (alias) になっています。しかし、XEmacs で実行したときは、前者は次の関数の別名関数 (alias) となっています:

     (defun gnus-xmas-run-at-time (time repeat function &rest args)
       (start-itimer
        "gnus-run-at-time"
        `(lambda ()
           (,function ,@args))
        time repeat))

この種類のものが多くの関数に対してなされています。Gnus は XEmacs で実行しているときに、元からある Emacs の関数を再定義しません---それは、代わりに Gnus の等価なものと defalias をすることによって実行します。全体的に、よりきれいになります。

XEmacs の関数界面の方が明らかにきれいな場合は、私は代わりにそれを使います。例えば、gnus-region-active-p は XEmacs では region-active-p の別名であるのに対して、Emacs では関数です。

もちろん、私は XEmacs を私の基本プラットフォームに選んで、関数の割り当てを逆にすることもできました。でも、私はそうしませんでした。 XEmacs で Gnus を実行するときに、こういう逆向きのための速度低下は少しでしょう。

いろいろなファイル様式
-----------

アクテイブファイル様式
...........

アクティブファイルは当のサーバーのすべての使用可能なグループの一覧を挙げます。それはそれぞれのグループの最低と最高の記事番号の一覧もあります。

これは普通のアクティブファイルからの抜粋です:

     soc.motss 296030 293865 y
     alt.binaries.pictures.fractals 3922 3913 n
     comp.sources.unix 1605 1593 m
     comp.binaries.ibm.pc 5097 5089 y
     no.general 1000 900 y

これはこのファイルの疑似 BNF 定義です。

     active      = *group-line
     group-line  = group spc high-number spc low-number spc flag <NEWLINE>
     group       = <non-white-space string>
     spc         = " "
     high-number = <non-negative integer>
     low-number  = <positive integer>
     flag        = "y" / "n" / "m" / "j" / "x" / "=" group

このファイルの完全な記述を得るためには、innd のマニュアルページ、特に active(5) を見て下さい。

ニュースグループファイル様式
..............

ニュースグループファイルはグループをその記述と共に一覧を挙げます。サーバーにあるすべてのグループが一覧にされなければならないのではなく、また、ファイルのすべてのグループがサーバーに存在しなければならないのではありません。このファイルは純粋に利用者の情報のためにあります。

様式は非常に簡単です: グループ名、タブ、そして記述です。これは定義です:

     newsgroups    = *line
     line          = group tab description <NEWLINE>
     group         = <non-white-space string>
     tab           = <TAB>
     description   = <string>

異教徒への Emacs
===========

信じるかどうかは知りませんが、Gnus を使う人の中には Gnus Love Boat での旅に搭乗する前にあまり Emacs を使ったことが無いという人がいます。もしあなたが ``C-M-a'' や ``リージョンを切る''、そして ``gnus-flargblossen を連想リストに設定して下さい。そのキーはグループ名に合致するために使われる正規表現です'' が少しの意味かまったく意味の無い魔法の言葉である不幸な人であれば、この付録はあなたのためにあります。もしあなたがすでに Emacs に親しんでいるのであれば、これを無視して車を可愛がりに行って下さい。

打鍵
--

  * Q: 経験のある Emacs の利用者とは何ですか?

  * A: 端末がペダルを持っていたらなぁと願う人のことです。

はい、あなたが Emacs を使うと、あなたはコントロールキー、シフトキー、メタキーをたくさん使うようになるでしょう。これは一部の人 (主に、 vi 利用者) には非常にうるさく感じられるでしょう。残りの人々は、それによりもたらされる地獄を愛します。あきらめて服従して下さい。Emacs は本当は ``Escape-Meta-Alt-Control-Shift'' の略で、他の評判の悪い出所 (Emacs の作者のような) から聞いた ``Editing Macros'' ではありません。

シフトキーは普通は小指の近くに位置しており、普通は大文字やその他のもを得るために使われます。あなたはずっとそれを使うことでしょう。コントロールキーは普通は ``CTRL'' やそのようなもので印が付いています。メタキーは、おもしろいことに、どのキーボードでもそのように印が付けられていません。それは普通はキーボードの左手側に位置していて、普通は最下段にあります。

これから、私たち Emacs 人は、それがあまりに不便なため、 ``meta-control-m キーを押す'' とは言いません。私たちは ``C-M-m を押す'' と言います。M- は ``メタ'' を現す接頭引数で、``C-'' は ``コントロール'' を意味する接頭引数です。ですから、``C-k を押す'' は ``コントロールキーを下に押し、k を押している間、それを下に保ちなさい'' ということです。``C-M-k を押す'' は``メタキーとコントロールキーを押して下に保った後で k を押す'' ということです。簡単でしょ。ね?

これはすべてのキーボードがメタキーを持っているわけではないという事実により少し複雑になっています。そのような場合は、``エスケープ'' キーを使うことができます。それはメタキーを持っているときよりもっと作業が大変になるので、そういう場合は、私はメタキーのあるキーボードを手に入れることを恭しくお勧め致します。それ無しでは生きて行けないでしょう。

Emacs Lisp
----------

Emacs はそれが本当は Lisp インタープリターであることから、エディターの王様です。あなたが叩く、それぞれのすべてのキーは何らかの Emacs Lisp のコードの小片を実行し、Emacs Lisp はインタープリターで実行される言語であることから、それはどんなキーでも任意のいろいろなコードを実行するように設定できるということです。あなたは、単に、そうすれば良いだけです。

Gnus は Emacs Lisp によって書かれていて、それはたくさんの逐次解釈実行される関数により実行されます。(これらは速度のためにバイトコンパイルされていますが、それでもまだ逐次解釈されます。) もし Gnus がするあることを好きではないと思ったなら、違ったように実行させるのは取るに足らないことです。 (えーと、少なくとも Lisp コードの書き方を知っていれば。) しかし、それはこのマニュアルの範囲外なので、私たちは単に Gnus をカスタマイズするために .emacs ファイルで普通使われるいくつかの普通の構文についてだけ話をします。

もし変数 gnus-florgbnize を四 (4) に設定したいのであれば、以下のものを書きます:

     (setq gnus-florgbnize 4)

この関数 setq (本当は ``特殊形式'' (special form)) を使って、変数を何かの値に設定することができます。これは本当にあなたが知るべきすべてのことです。これからは Gnus の動作を変更するために、たくさんのこのようなもので .emacs ファイルを埋め尽くすことができます。

もしあなたがそのようなものを .emacs ファイルに入れたら、それは次回に Emacs を起動したときに読み込まれ 評価 (それは ``実行'' の lisp 語です) されます。もし変数をすぐに変更したいのであれば、閉じ括弧の後で単に C-x C-e とするだけです。それは前にある ``式'' を 評価 し、それはここでは簡単な setq 文です。

がんばって---もしあなたが Emacs の前にあるのであればちょっと試して下さい。 C-x C-e の後で、反響区域 (echo area) に 4 が現われるのが見えるでしょう。それはあなたが 評価 した式の返り値です。

いくつかの落とし穴:

もしマニュアルが ``gnus-read-active-file を some に設定しなさい'' と言ったなら、それは:

     (setq gnus-read-active-file 'some)

ということです。

一方、マニュアルが ``gnus-nntp-server を nntp.ifi.uio.no に設定しなさい'' と言ったなら、それは:

     (setq gnus-nntp-server "nntp.ifi.uio.no")

ということです。

ですから、文字列 (後者) を シンボル (前者) と混同しないように注意して下さい。マニュアルは明確に区別していますが、混乱しやすいかもしれません。

     [file gnus-faq-ja.texi not included]