This file documents gnus, the GNU Emacs newsreader.

このファイルは GNU Emacs のニュースリーダである gnus に関する説明書です。

Copyright (C) 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004 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.1 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.1 版またはそれ以降の版が定める条件の下で複製、配布、あるいは変更することを許可します。変更不可部分は指定しません。「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
*******************

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

T-gnus は SEMI API に基づく MIME 機能を提供します。そういう訳で、T-gnus は大きな絵が入っていたりさまざまな形式を用いたりしているちょっと変わった記事を読む権利を擁護します。T-gnus は MULE API に基づく国際化・地域化、および、多字化機能を提供します。よって、T-gnus はさまざまな言語圏を差別しません。ああ、クリンゴンの方は Unicode Next Generation をお待ちください。

この説明書は T-gnus 6.17 に対応します。

gnus の起動
********

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

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

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

この説明書でよくわからない用語がでてきたときは、用語の項 (see 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 "")))

と設定します。

一番初め
====

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

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

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

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

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

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

初期設定 (default) のサーバーが落ちているときは、当然 gnus の起動にいくつかの問題が発生します。しかし、ニュースグループの他にいくつかメールのグループがあれば、それにもかかわらず gnus を起動したいと思うかもしれません。

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

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

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

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

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

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

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

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

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

グループを取得する
=========

時々、“このグループを読みたいのであって、gnus が起動しているかどうかを気にしたくない。”ということができれば便利なことがあります。これは、利用者よりもプログラムのコードを書く人に便利な機能ですが、どちらにしろ、コマンド gnus-fetch-group はこの機能を提供します。そのコマンドは、グループの名前を引数としてとります。

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

新しいニュースグループを全く見ないで満足であるならば、 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 はこれをすべての基本グループに対して行います。そのコマンドは移動先の方法の入力を促します。

個々のグループを命令 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 が使えます (でも気を付けて、それはすべてのグループのキャッシュを移動してしまいますから)。

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

今や、あなたはファイル .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 にすることによって .newsrc とすべての .newsrc-SERVER を作らないようになります。もしあなたが時々 Netscape を使うのならば、こうするのが都合が良いでしょう。

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 を保存する前に実行されます。後の二つは普通は版管理を入れたり切ったりするのに使われます。初期設定では、起動ファイルを保存するときに版管理に入ります。バックアップファイルの作成を止めたいときは、次のようにしてください。

     (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) と gnus-init-file (初期設定では ~/.gnus) のファイルを読み込みます。これらは普通の Emacs Lisp ファイルで、~/.emacs や site-init ファイルを gnus 関係のもので乱雑にしないようにするために使うことができます。 Gnus はこれらと同じ名前のファイルに、接尾語 .elc と .el が付いているものも調べます。言い換えれば、 gnus-init-file を ~/.gnus に設定すると、 gnus は ~/.gnus.elc, ~/.gnus.el を探し、最後に ~/.gnus を (この順番に) 探します。

自動保存
====

何か 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 n
     新しい nnshimbun グループを作成します (gnus-group-make-shimbun-group)。gnus はプロンプトを表示して、サーバーのアドレスを示すシンボル名と記事グループ名の入力を求めてきます。これを使うには emacs-w3m (http://emacs-w3m.namazu.org/) が必要です。 nnshimbun に関する詳細は (see Nnshimbun (Emacs-w3m-ja)) を参照して下さい。

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 Mailing Lists (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)。

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 言語は 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 Manual))。

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 は良く動作しますが、やや遅くなります。そして、std11-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)。

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

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

<
     二十引くスレッドレベルの空白。

U
     未読。See Read Articles.

R
     この紛らわしい名前指定子は 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様式による日付。

o
     YYYYMMDDTHHMMSS様式による日付。

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 ヘッダーが代わりに仕様されます。

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

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

要約すると、普通は以下のようなものを ~/.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 の普通の実装において) 以下のものを

     Newsgroups:full

overview.fmt ファイルの最後に追加してもうらうことができれば、メールグループでの追加ヘッダーのようにそれを使うことができます。

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

概略のモード行の様式も変更することができます (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
     これは概略バッファでの現在の記事をハイライトするために使われるフェイス (face) (もしくは、いくらかの人々が フォント (font) と呼ぶようなもの) です。

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
     記事番号か Message-ID を尋ね、それからその記事を表示すること無く、概略行に行く (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 は概略バッファでのポイントを常に真中に保ちます。これをすると、とてもこぎれいになりますが、遅いネットワーク接続であったり、単にこの Emacsism でない行為を好きになれないのであれば、普通の Emacs のスクロールにするために、この変数を nil にすることができます。これは概略バッファの水平方向の真中への再移動も禁止しますので、非常に長いスレッドを読むときは不便かもしれません。

記事の選択
=====

命令の選択
-----

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

新しい記事を取り込んだり、グループを再表示したいときは 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
     このフックは記事が選択されたときに常に呼ばれます。初期設定では、選択された記事の下に隠れているスレッドを見せるようになっています。あなたが読んだそれぞれの記事をエージェントにセーブさせたい場合は、このフックに 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 で、つまらないと思うものをカスタマイズするか、または nil に設定することによって、この機能を働かないようにすることができます。どんなにうんざりするものでも、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 グループパラメータを設定する必要があり、それは動作するでしょう。

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

S o m
C-c C-f
     誰か他の人に現在の記事を転送します (gnus-summary-mail-forward)。接頭引数があると、転送記事の完全なヘッダーを取り込みます。

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)。接頭引数が与えられたときは、転送記事のヘッダーを完全に取り込みます。

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
     現在の記事を既に存在する Message 作成バッファに貼り付けます (gnus-summaryyank-message)。この命令は貼り付けたいメッセージバッファの入力を促し、プロセス/接頭辞の習慣を理解します (see Process/Prefix)。

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

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

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

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

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

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

Gnus は Cancel-Lock ヘッダー (see Canceling News (Message Manual)) を使って、あなただけがあなたのメッセージをキャンセルできることを保証します。

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

本記事のところへ移動して、S s を押してください (gnus-summary-supersede-article)。普通の方法でそれを送る前に、記事を好きなように編集することができます。代替に関しても、取り消しと同じことが当てはまります。こちらの方がもっとよく当てはまるかもしれません: いくつかのサイトは代替を受け付けません。これらのサイトでは、あなたがほとんど同じ記事を二回投稿したようになります。

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

ちょっと覚えておいてください: '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 を使うことができます。それ以外は (見えるかどうかは別にして)、可視記事 (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.

  * (何らかの方法によって；必ずしも宗教的というわけではなく) 『保存された』記事は、二桁目に 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.

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
     正規表現によって記事に印を付けます (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)。

そして、どうやって記事の本文 (body) の内容を基にプロセス印を付けるかは、 Searching for Articles の & 命令を参照して下さい。

制限をする
=====

概略バッファが現在グループにある記事の一部だけを表示するように制限できれば便利なことがあります。多くの制限命令が持つ効果は概略バッファから少し (もしくは多く) の記事を概略バッファから削除することです。

すべての制限命令はサーバーから既に取得された記事の一部分に作用します。これらの命令はどれもサーバーに追加の記事を要求しません。

/ /
/ s
     概略バッファをいくつかの表題と合致するものだけに制限します (gnus-summary-limit-to-subject)。もし接頭辞が与えられれば、合致する記事を除外します。

/ a
     概略バッファを何人かの著者に合致するものだけに制限します (gnus-summary-limit-to-author)。もし接頭辞が与えられれば、合致する記事を除外します。

/ 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 か数字に設定することができます。もし数字に設定したときは、それより多い追加のヘッダーは取得されません。どちらの場合でも、古いヘッダーの取得が動作するのは、使っているバックエンド(back end) が 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-set-summary-default-charset) です。これは変数 gnus-newsgroup-default-charset-alist で指定されている値から概略バッファの default-mime-charset を設定します。

gnus-alter-header-function
     これが nil でないと、ヘッダー構造の交換を可能にするようにこの関数が呼ばれます。関数は一つの引数、記事ヘッダーのベクトル、とともに呼ばれ、それが何らかの方法で交換されます。例えば、(接頭語やその他のものを付け加えることによる) 体系的な方法で 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))))

スレッドの命令
-------

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 でないと (これがディフォルトですが)、スレッドの命令を実行しているときに表題は無視されます。この変数が fuzzy であると、あいまいに等しい表題を持つ記事だけが含まれます (see Fuzzy Matching)。

並び替え
====

もしスレッドの概略表示を使っているのであれば、 gnus-thread-sort-functions を設定することでスレッドを並び替えることができます。それは、単独の関数、関数のリスト、関数と (関数でないもの) の要素であることができます。ディフォルトでは、並び替えは記事番号によってなされます。既に作られている並び替え述語関数は gnus-thread-sort-by-number, gnus-thread-sort-by-author, 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 はサーバーに二つの (それは 2 と数えてください) 接続を張ることができます。これはあまりして良いことではないと考える人もいるでしょうが、私には実際の代替手段が見つからないのです。余分な接続をするためには何らかの時間がかかりますので、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-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 ファイルを (再) 作成し、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 が既に読んだ記事を一時保存しておくところです。これはもちろん、あなたに最近読んだ記事を再び選択する癖があるときだけに役立ちます。もし絶対にそれをしないのであれば、バックログをすることは gnus を少し遅くし、メモリーの使用量をいくらか増やします。

もし gnus-keep-backlog を数字 N に設定すると、gnus は最大で N の古い記事を後の再取得のためにバッファに溜めておきます。この変数が nil ではなく、数字でもない場合、gnus は全ての既読記事をたくわえます。これはあなたの Emacs が、暴発してあなたのマシンが落ちるまで制限なく膨れ上がるということです。私はあなた方全てが元気でいられるようにここに書き加えました。

ディフォルト値は 20 です。

記事の保存
=====

Gnus はたくさんの方法で記事を保存する事ができます。以下のものは非常に率直な方法 (例えば、記事が保存する前にほとんど何もなされない) で記事を保存するための説明です。違った手段 (uudecodeする、shar ファイルを展開する) については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
     現在の記事の本文 (body) を普通のファイル様式で保存します (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)) ; to get a hierarchy
     (setq gnus-default-article-saver
           'gnus-summary-save-in-file) ; no encoding

それから o によって記事を保存するだけです。それからこの階層を短命な nneething グループによって読む事ができます――グループバッファで G D とし、一番上のディレクトリーを引数 (~/News/) として渡します。

記事の復号化
======

ときどき利用者は何らかの方法で符号化された記事 (もしくは記事群) を投稿します。Gnus はあなたのためにそれらを復号化する事ができます。

これらすべての関数はプロセス/接頭引数の習慣 (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 に記事を投稿します。この機能を使わないようにする事はできません。

シェルアーカイブ
--------

シェルアーカイブ (『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 は記事からすべてのキャリッジリターン (carriage return) を取り去るという事です。

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 内容の型に取り替えるという事です。その結果は閲覧のために metamail にかけられます。

gnus-uu-save-in-digest
     nil でないのは、gnus-uu が復号化をしないで保存をするように言われたときに、要約を保存するという事です。この変数が 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
     現在の記事をもっとハイライト (highlight) します。この関数は、ヘッダー、引用文、署名をハイライトし、本体 (body) と頭 (head) にボタンを加えます。

W H h
     ヘッダーをハイライトします (gnus-article-highlight-headers)。ハイライトは変数 gnus-header-face-alist にしたがってなされ、それはそれぞれの要素が (正規表現 名前 内容) という様式のリストです。正規表現はヘッダーに合致する正規表現、名前はヘッダーの名前をハイライトするのに使われるフェイス (face) (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 です。記事を自動的にハイライトする方法については see Customizing Articles を参照して下さい。

記事のフォント変更
---------

人々はよくニュースの記事で _これ_ や *これ* または /これ/ のようなものを使って単語を強調します。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 グループパラメータを使うこともできます。

記事を自動的にフォンと変更させるためには 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-opend-text-button-line-format
     gnus-cited-closed-text-button-line-format

          Gnus はどこの引用文が隠されているかを示すためにボタンを付け加え、文章の隠蔽を切り替えられるようにします。この変数の様式はこれらのフォーマットのような変数によって指定されます (see Formatting Variables)。次の指定は有効です:

          b
               隠された文の最初のポイントです。

          e
               隠された文の最後のポイントです。

          l
               隠されたリージョンの文字の数です。

          n
               隠された文の行の数です。

     gnus-cited-lines-visible
          引用文の最初からの表示される行数です。

W W C
     根本でない記事の引用文を隠します (gnus-article-hide-citation-in-followups)。これは対話的命令としてはあまり役に立たないかもしれませんが、自動的に起こる手軽な関数であるでしょう (see Customizing Articles)。

W W C-c

     以下の二つの変数に基づいて引用を隠します (gnus-article-hide-citation-maybe):

     gnus-cite-hide-percentage
          もし引用文がこの変数 (初期値は 50) より大きい割合であれば、引用文を隠します。

     gnus-cite-hide-absolute
          隠される引用文は少なくともこの長さ (初期値 10) でなければなりません。

これらの全ての『隠蔽』命令は切り替え命令ですが、これらの命令に負の接頭引数を与えると、それらは前に隠されていたものを表示します。正の接頭引数を与えれば、それらは常に隠します。

引用カスタマイズのための他の変数の情報のために Article Highlighting も参照してください。

自動的に記事の要素を隠すための方法は Customizing Articles を参照して下さい。

記事洗濯
----

私たちはこれをもっともな理由の下で『記事洗濯』(article washing) と呼んでいます。すなわち、キー A は使われているので、代わりにキー W を使う必要があるのです。

私たちは 洗濯 を『何かの何かを何か別のものに変換する』と定義していますが、普通はもっと良く見える何かに落ち着きます。それにもっときれいです、たぶん。

gnus が記事を表示する既定のやり方を変えたいときは Customizing Articles を参照して下さい。

C-u g
     これは記事洗濯ではなくて、その逆です。これをタイプすると、ディスクやサーバーにあるがままの記事が見えます。

g
     現在の記事の再表示を強制します (gnus-summary-show-article)。これもまた本当の洗濯ではありません。これをタイプすると、以前に適用された対話的な洗濯機能はご破算にされ、すべてのディフォルトの扱い (treatments) を受けた記事が表示されます (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 t

t
     記事バッファにすべてのヘッダーを表示するかどうかを切り替えます (gnus-summary-toggle-header)。

W v
     記事バッファにすべてのヘッダーを永遠に表示するかどうかを切り替えます (gnus-summary-verbose-headers)。

W m
     表示する前に記事に MIME 処理を実行するかどうかを切り換えます (gnus-summary-toggle-mime)。

W o
     オーバーストライクを処理します (gnus-article-treat-overstrike)。

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)。

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 によって自動的に行なわれることに注意して下さい。

     接頭辞が与えられると、何の文字集合 (charset) として扱うかを尋ねられます。

     ディフォルトでは HTML の変換に mm-text-html-renderer (see Display Customization (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 に含まれている) を使います。

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 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)。

記事のボタン
------

よく記事の中に他のものへの参照が入れられる事があります。そして、gnus がそれに関する事を、それらの参照の上で RET を打つか、マウスの真中のボタンを使う事によって、最小限の努力で取得する事ができれば素敵でしょう。

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 のような名前の変数が使われますが、他のどんな形式でも使うことができます。

     function
          この関数 (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
see 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 を参照して下さい。

記事の日付
-----

日付は聞いた事の無い何か辺鄙な時間帯 (timezone) で作成されている事が良くあるので、記事が送られたときに何時であったかを知る事ができるのは非常に良い事でしょう。

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)。

記事の署名
-----

それぞれの記事は二つの部分に分けられます――見出し (header) と本体 (body) です。本体は署名部分と文章部分に分けられます。どれが署名とみなされるかを決める変数は 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)。

記事命令
====

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-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-^ (概略)
     どのグループに属しているかに関わらず、任意の記事を NNTP サーバーに尋ねる事ができます。 M-^ (gnus-summary-refer-article) は Message-ID、それはあの長く、なかなか読む事のできない <38o6up$6f2@hymir.ifi.uio.no> のような参照をあなたに尋ねます。あなたはすべてを正確に打ち込まなければなりません。残念ながら、あいまいな検索はできないのです。

ニュースでない選択方法から Message-ID で取得するときには現在の選択方法が使われますが、この命令に接頭引数を与える事でこれを上書きする事ができます。

もしあなたの読んでいるグループが 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 でもそうであるので、我々は概略バッファーのためのマイナーモード (minor mode) に少しの選択肢を与えてあります。

選んで読む
-----

いくつかのニュースリーダー (nn や、あのぉ、VM/CMS での Netnews など) は二相の読むための界面を使います。利用者はまず概略バッファで読みたい記事に印を付けます。それから、記事バッファだけを表示して記事を読みます。

Gnus はこれをするための概略バッファマイナーモードを提供します―― gnus-pick-mode です。これは基本的には簡単に印を付けられるように少しのプロセス印命令が一打鍵命令になり、概略バッファへ切り替えるための追加命令を一つ提供します。

これが pick mode を使ったときに使用可能なキーです:

.
     現在の行の記事かスレッドを選択します (gnus-pickd-article-or-thread)。もし変数 gnus-thread-hide-subtree が true であれば、このキーはスレッドの最初の記事で使われたときはスレッド全体を選択します。そうでなければ、それはその記事だけを選択します。もし数値接頭引数を与えられればそのスレッドか記事へと生んでいき、それを選択します。(行数は普通は概略選択行の最初に表示されています。)

SPACE
     概略バッファを一ページ次にスクロールします (gnus-pick-next-page)。もしバッファの最後であれば、選択記事を読み始めます。

u
     スレッドか記事を未選択にします (gnus-pick-unmark-article-or-thread)。変数 gnus-thread-hide-subtree が true であれば、このキーはスレッドの最初で使われればスレッドを未選択にします。そうでない場合はそれは記事だけを未選択にします。その行にあるスレッドか記事を未選択にするためにこのキーに数値接頭引数を与える事ができます。

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 マイナーモードバッファで実行されます。

pick モードでの概略行の様式は標準の様式とは少し違います。それぞれの行の最初に行数が表示されます。Pick モードの行の様式は変数 gnus-summary-pick-line-format で制御されます (see Formatting Variables)。これは gnus-summary-line-format と同じ様式指定を受け付けます (see Summary Buffer Lines)。

バイナリーグループ
---------

もし多くの時間をバイナリーグループ (binary group) で過ごしているのなら、いつも 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 です。使用可能な指定は see 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 ではないならば (これが初期値ですが)、マークは保存されます。

B w
e
     現在の記事を編集します (gnus-summary-edit-article)。編集を終了して変更を永遠にするために C-c C-c (gnus-summary-edit-article-done) を打ちます。もし命令 C-c C-c に数値接頭引数を与えると、gnus は記事を再ハイライトしません。

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 から) 取得しようとし、記事を発見できたかどうかを報告します。それが記事を発見しなかったとしても、それはとにかく投稿されているかもしれません――メールの伝達はニュースの伝達よりもずっと速く、ニュースの複製がまだ到着していないだけかもしれないのです。

もし、規則的に記事を移動 (もしくは複製) するのであれば、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 だったら、現在の記事を指し示すためにフリンジに矢印を表示します。

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:")))

     see Group Parameters も参照して下さい。

概略グループ情報
--------

H f
     現在のグループの FAQ (frequently asked questions (頻繁にされる質問) のリスト) を取得しようとします (gnus-summary-fetch-faq)。 gnus は普通は遠隔マシンのディレクトリである gnus-group-faq-directory から FAQ を取得しようとします。この変数はディレクトリーのリストである事もできます。その場合は、この命令に接頭引数を与える事でいろいろなサイト (site) から選ぶ事ができます。おそらく 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
     もし現在のグループが他の記事の集まりであるならば (例えば、摘要 (digest))、そのような記事でできているグループに入るためにこの命令を使うかもしれません(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)。これはおそらく概略バッファの行中央表示関数を混乱させますので、記事を読んでいる間に切断を切っているのは良い考えではないでしょう。

=
     概略バッファのウィンドウを拡大します (gnus-summary-expand-window)。接頭引数を与えられれば、記事 ウィンドウを拡大します。

C-M-e
     現在のグループのグループの媒介変数 (parameter) (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 article) に既読の印を付けて、それから抜けます (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 も保存します。この命令を使うと、更新なしで抜け出る事 (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) 記事は既読の印が付き、それが相互投稿 (cross post) された他の購読しているグループでも既読の印が付きます。この変数が nil でも t でなければ、記事は購読と未購読の両方のグループで既読の印が付きます (see Crosspost Handling)。

相互投稿の扱い
=======

相互投稿 (cross post) された記事に既読の印を付ける事は、同じ記事を二回以上読まないですむという事を保証します。もちろん、だれかがそれをいくつかのグループに別々に投稿しない限りは。同じ記事をいくつかのグループに投稿する事 (相互投稿でなくて) は spamming と呼ばれ、あなたはそのような憎むべき犯罪を行なうものに対して、法律によって不快な記事を送ることが義務づけられています。spam を選別するためには、NoCeM の取扱を試してみる必要があるかもしれません (see NoCeM)。

覚えてください: 相互投稿は構いませんが、同じ記事を別々にいくつかのグループに投稿するのは許されません。大量の相互投稿 (velveeta) はどうしても避けられるべきで、過剰相互投稿に対して不満を言うために命令 gnus-summary-mail-crosspost-complaint を使うことさえできます。

相互投稿を gnus が正しく扱えないようになる原因の一つは、NOV 行に Xref 欄を含まない、XOVER (これは非常に良いです、というのはそれは速度をとても速くするからです) の使用可能な NNTP サーバーを使っていることです。これは害悪なのですが、あぁ、悲しいかな、非常に良くある事です。Gnus はあなたが読んだ全ての記事に Xref 行を登録する事で、正しい事をしようとしますが、記事を削除するか、読まないで既読の印を付けると、gnus はこれらの記事に Xref の行をのぞきまわる機会を得る事が無く、相互参照機構を用いる事ができません。

あなたの NNTP サーバーがその概観ファイル (overview file) に Xref 欄を含んでいるかを調べるには、 telnet your.nntp.server nntp として、inn サーバーで More 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 は RFC 2369 で既定された各種のメーリングリストで使われるフィールドを理解します。これを有効にするには to-list グループパラメータ (see Group Parameters) を追加して、概略バッファで A M (gnus-mailing-list-insinuate) を使って下さい。

これによって概略バッファでの以下の命令が使えるようになります。

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-article-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 は gnus-article-display-method-for-mime に記事を押し付けることで MIME を扱います。この初期値は gnus-article-display-mime-message です。この関数は SEMI MIME-View プログラムを呼び出して実際の処理を行います。 SEMI MIME-View に関する詳しい情報は、マニュアルを参照してください (まだないけど (;_;))。

MIME を常に使用したければ、 gnus-show-mime を t に設定してください。 gnus-show-mime を設定していると、運が悪いと記事バッファには故障したような画面が見えることもあるでしょう。これは避けようがありません。

GNUS や Gnus では、このたちの悪い問題で驚かされないようにするには、概略バッファにおいて切り替え機能を使うというのが最善かも知れません (例えば、 alt.sing-a-long グループに入ると、あなたの気づかないうちに MIME は記事中のサウンドファイルを復号して、何やら怪しげな長い長い歌があなたのスピーカーから大音響で流れ出し、あなたはボリュームボタンを見つけられず、というのはそんなものはもともとついてないからで、みんなはあなたの方を睨みはじめ、あなたはプログラムを止めようとするけどできなくて、ボリュームを制御するプログラムも見つけられなくて、そして部屋中の全員は突然あなたのことを軽蔑の眼差しで見るようになってしまい、あなたはちょっと面白くない思いをする、とか)。

現実の出来事と実在の人物に類似しているかもしれませんが、これは全てホントのことです。げほげほ。

まあ、そういう訳で、gnus では metamail-buffer を使うのを止めた訳です。そういう訳で、今では常に gnus-show-mime を nil 以外にしておき、周りに人がいない時を見計らって記事バッファに現われるボタンを押しましょう。

記事のカスタマイズ
=========

記事がどのように存在しているかをカスタマイズするためのたくさんの関数です。これらの関数を対話的に呼ぶこともできますし (see Article Washing)、記事を選択したときに自動的に選択することもできます。

自動的に呼ばれるようにするためには、対応する ``treatment'' 変数を設定します。例えば、ヘッダーを隠すためには、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)

gnus-treat-decode-article-as-default-mime-charset (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 記事を復号化するときに使用されるフックです。

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
               記事バッファにおいて、ヘッダーが隠されている場合に表示されます。

          s
               記事バッファにおいて、署名が隠されている場合に表示されます。

          o
               記事バッファに重ね打ち文字がある場合に表示されます。

          e
               記事バッファに強調された文字列がある場合に表示されます。

     m
          記事の MIME 部分の数です。

gnus-break-pages
     改頁 page breaking を行うかどうかを制御します。この変数が nil 以外であれば、記事中に頁区切り文字が現れた場所ごとに頁分割します。この変数が nil であれば頁分けは行われません。

gnus-page-delimiter
     これが上で触れた区切り文字です。ディフォルトでは ^L (フォームフィード、改頁) です。

gnus-use-idna
     この変数は From:、To: および Cc: ヘッダーにある国際化ドメイン名を、gnus が IDNA デコードするかどうかを制御します。これには 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 を返す、唯一のパラメータとしてグループ名を受け取る関数であることもできます。あるいは、確認を求めるべきグループ名に合致する正規表現です。

     メールで返信する気は無いのに時たまぞんざいに R を押してしまう癖があるならば、この変数はそんなあなたのためにあります。

gnus-confirm-treat-mail-like-news
     非-nil だったら、gnus はメールへの返信時にも gnus-confirm-mail-reply-to-news に基づいた確認を求めます。これはメーリングリストをニューズグループのように扱うのに便利です。

投稿するサーバー
========

最新の (もちろん、非常に知的な) 記事を送り出すために、あの魔法のような C-c C-c キーを押した時、それはどこにいくのでしょう?

尋ねてくれてありがとう。あなたを恨みます。

それは非常に複雑になり得ます。

ニュースを投稿するとき、通常 Message は message-send-news を呼び出します (see News Variables (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")
     ;; Version 1.14.6 より古い FLIM に付属している smtpmail.el を使う
     ;; 場合、以下の変数を設定する必用があります。
     (setq smtp-default-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) と同じ＋システムタイプ)、 gnus-mime-edit (Gnus と MIME Edit などのバージョン)、または好みの文字列。これを文字列にするときは、正しいフォーマットになっていることを確かめて下さい (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 はあなたが送ったメールとニュースを貯めておくためのいくつかの違った方法を提供します。ディフォルトの方法はメッセージを保存するために 事実上の書庫サーバー(archive virtual server) を使います。これを完全に禁止したいのであれば、変数 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/")))

Gnus は外へ出て行く全てのメッセージに、一つかそれ以上のそのサーバーのグループへ向かう Gcc 欄を挿入します。どのグループを使うかは変数 gnus-message-archive-group によって決まります。

この変数は次のような事をするために使われます:

文字列
     メッセージはそのグループに保存されます。

     あなたはグループ名に選択方法を含めることができますが、そうするとそのメッセージは gnus-message-archive-method で指定した選択方法ではなくて、代わりにグループ名の選択方法で保存されることに注意しましょう。上に示したように gnus-message-archive-method は、ディフォルト値を持つものであると考えて下さい。ですから gnus-message-archive-group を "foo" にしておけば、外へ出て行くメッセージは nnfolder+archive:foo に保存されますが、もしあなたが "nnml:foo" という値を使うと、nnml:foo に保存されます。

文字列のリスト
     メッセージはそれらの全てのグループに保存されます。

正規表現、関数、様式の連想リスト
     キーが『合致』すると、結果が使われます。

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-gcc-mark-as-read
     もし非nilなら、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 と Organization ヘッダー What me? を持ちます。

それぞれの様式の最初の要素は 合致 (match) と呼ばれます。もしそれが文字列であれば、gnus はそれをグループ名に正規表現として合致操作を行います。(header 合致 正規表現) という様式であれば、gnus は元の記事の中から名前が合致するヘッダーを探し、それを正規表現と比較します。合致と正規表現は文字列です。(元の記事とは返信またはフォローアップしようとしているものです。返信あるいはフォローアップを作成していなければ、合致するものは何もありません。) もし 合致 が関数のシンボルであれば、その関数が引数無しで呼ばれます。それが変数のシンボルであれば、その変数が参照されます。それがリストであれば、そのリストが 評価 されます。どの場合でも、これが nilでない値を帰せば、様式は 合致した と言います。

それぞれの様式は任意の量の 属性 を持つ事ができます。それぞれの属性は (NAME VALUE) の対により成り立っています。加えて、 (NAME :file VALUE) の形式か (NAME :value VALUE) の形式を使うこともできます。ここで :file は VALUE がファイル名を表して、その内容が属性値として使用されるべきであることを示し、:value は VALUE がファイル名を表わさないことを明示的に示します。属性名は、以下のどれかである事ができます。

  * signature

  * signature-file

  * x-face-file

  * address, user-mail-address を上書きします

  * name, (user-full-name) を上書きします

  * body

属性名は文字列またはシンボルである事もできます。その場合は、これはヘッダー名として使われ、その値が記事のヘッダーに挿入されます。もし属性名が nil だったらそのヘッダー名は削除されます。もし属性名が eval だったらその様式が評価され、結果は捨てられます。

属性値は文字列 (そのまま使われます)、引数の無い関数 (返り値が使われます)、変数 (その値が使われます) またはリスト (それは 評価 されて、返り値が使われます) である事ができます。関数はセットアップされたメッセージバッファで呼ばれ (eval され) ます。現在の記事のヘッダーは変数 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-named-posting-styles を設定することで、よく利用する投稿様式に名前をつけられます。概略バッファで S P とすることで、投稿時に任意の様式を選択します。gnus-named-posting-styles は名前と様式からなる連想リストです。gnus-posting-styles に含まれる属性名が import だったら、その値で gnus-named-posting-styles を引いて、属性値をそこに展開します。

これは例です:

     (setq gnus-named-posting-styles
           '(("Default"
              (signature-file "~/.signature")
              (name "User Name")
              ("X-Home-Page" (getenv "WWW_HOME"))
              (organization "People's Front Against MWM"))
             ("Emacs"
              (import "Default")
              (organization "The Church of Emacs"))))

"Emacs" と名付けられた様式は、organization 以外の属性を "Default" から引き継ぎます。

下書き
===

もしメッセージ (メールもしくはニュース) を書いているときに、突然オーブンにステーキが入っている (もしくはあなたがとーってもすごい菜食主義者で、何かのペーストがフードプロセッサーに入っている) 事を思い出したなら、書いているメッセージを保存する方法があれば良いと思うでしょう。そうすれば、いつか別の日に編集を続ける事ができ、それが完成したと思ったときに送る事ができます。

えぇ、心配しないでください。Gnus のメールと投稿命令を使う何らかのメッセージを書き始めたときに手に入るバッファは、自動的に特別な draft グループに関連付けられます。普通の方法でバッファを保存すれば (たとえば、 C-x C-s)、その記事はそこに保存されます。(自動保存ファイルも下書きグループ (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) に入れられます。サーバーが戻ってきたなら、普通はそのグループに入って全ての記事を送ります。

選択方法
****

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

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

選択方法は 事実上のサーバー を定義すると言うことができるかもしれません---ですから私たちはちょうどそれをしました (see Server Buffer)。

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

たとえば、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) で指定します。

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

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

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

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

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

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

n
     サーバーの名前。

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

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

モード行も変数 gnus-server-mode-line-format を使う事によってカスタマイズする事ができます (see Mode Line Formatting)。以下の指定は理解されます:

S
     サーバー名。

M
     サーバー方法。

see Formatting Variables も参照してください。

サーバー命令
------

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

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

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

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 の例です。

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

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

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

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

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

防壁 (firewall) の中にいて、防壁マシンからの NNTP サーバーへの接続しかないのであれば、gnus に防壁マシンに rlogin して、そこから NNTP サーバーに telnet をするように指示する事ができます。これをする事は少しばからしいですが、事実上のサーバーの定義はおそらくこのようなものになるべきです:

     (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 はサーバーを 拒否 として印を付けます。これはその後のそのサーバーとの接続をはかるどのような試みも無視されるという事です。Gnus は接続が開けないことが本当であるかどうかを少しも確かめず、``It can't be opend,'' (接続を開く事ができません) と告げます。

それは行儀が悪いと思う事があるかもしれませんが、それはたいていのときには良い方法です。例えば、サーバー nephelococcdyia.com に 10 個購読しているグループがあるとしましょう。サーバーはどこか非常に遠くにあり、マシンはとても遅いので、それが今日はあなたとの接続を拒否するかどうかを調べるだけで一分かかります。もし gnus がそれを 10 回試すようになっていたなら、あなたは非常にうるさく思うでしょう。ですから、gnus はそれを試そうとはしません。一度 ``connection refused'' (接続は拒否されました) を受け取ると、それはサーバーが ``down'' (落ちている) であるとみなします。

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

サーバーバッファに飛び移って (see Server Buffer)、以下の命令でつつくだけでできます:

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

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

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

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

R
     Gnus がどれかのサーバーから接続拒否を受けたかどうかの全ての印を消去します (gnus-server-remove-denials)。

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

ニュースの取得
=======

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

NNTP
----

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

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

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

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

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

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

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

      2. それぞれの行は任意の数の 区切り印/値 の対を含む事ができます。

          有効な区切り印は 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-list-options
     LIST コマンドのオプションに使って、(サーバーの) リスト出力を設定したニュースグループだけに制限するための、ニュースグループ名のリストです。それぞれのニュースグループ名には fj.* や japan.* のような、シェル形式のワイルドカードを使うことができます。もし幸運にもサーバーがそのようなオプションを受け付けてくれれば、gnus を速く動作させることができるかもしれません。これは、以下のようにサーバー変数として使うことができます。

          (setq gnus-select-method
                '(nntp "news.somewhere.edu"
                       (nntp-list-options ("fj.*" "japan.*"))))

nntp-options-subscribe
     合致したら無条件で講読するニュースグループ名の正規表現です。正規表現の文字列では $ の代わりに   を使って下さい。サーバーが LIST コマンドのオプションにシェル形式のワイルドカードを受け付けてくれない場合でも、 nntp-list-options と同様の効果があるでしょう。これは、以下のようにサーバー変数として使うことができます。

          (setq gnus-select-method
                '(nntp "news.somewhere.edu"
                       (nntp-options-subscribe "^fj\\.\\|^japan\\.")))

nntp-options-not-subscribe
     合致しなかったら無条件で講読するニュースグループ名の正規表現です。正規表現の文字列では $ の代わりに   を使って下さい。サーバーが LIST コマンドのオプションにシェル形式のワイルドカードを受け付けてくれない場合でも、nntp-list-options と同様の効果があるでしょう。これは、以下のようにサーバー変数として使うことができます。

          (setq gnus-select-method
                '(nntp "news.somewhere.edu"
                       (nntp-options-not-subscribe "\\.binaries\\.")))

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

これらの関数は、あなたのマシンと 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") です。

ニューススプール
--------

ローカルスプールから外部グループを購読する事は非常に簡単で、役に立ちます。たとえば、非常に大きな記事があるグループ---例えば 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 でない値を帰す必要があります。

これらの最後は常に総合的なものであるべきで、他の正規表現に合致しないメールに合致するために、この正規表現は いつも *であるべきです。 (これらの法則は連想リストの初めから終わりまで順番に実行されます。相互投稿 (crosspost) を使用可能にしていない限り、最初の合致した法則が ``勝ちます''。相互投稿を使用可能にしている場合、全ての合致した法則が ``勝ちます''。) メール分割によって新しいグループが作られた場合は、それらを見るために gnus-group-find-new-groups を実行する必要があるでしょう。

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

全てのメールバックエンドは、入って来た貧乏で純粋なヘッダーを乱暴に扱っても良い事に注意してください。それらはすべて 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 が使用されます。

     これはいくつかの例です。初期利用者名で、初期 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 メールボックスから記事を取得します。詳しくは see 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 は圧縮されたメッセージファイルを使うことを考慮に入れます。

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 はこれらのソースへの界面を提供するバックエンド群を少し備えつつあります。

Web Newspaper を除くすべてのウェブソースは、動作させるために 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
     ウェブサーバーでのアカウントのパスワードです。

Web Newspaper
-------------

ウェブに基づいたバックエンドである nnshimbun は、2003年6月18日を以て emacs-w3m パッケージに移籍されました。今までのように T-gnus でウェブの新聞を閲覧したいのであれば、最新版の emacs-w3m をインストールする必要があります。その際、必ず T-gnus 由来の nnshimbun.el と nnshimbun.elc ファイルを消して下さい。 Emacs-w3m は外部コマンド w3m への Emacs のインターフェースです。詳細情報については以下のページを訪ねてみて下さい。

     http://emacs-w3m.namazu.org/
     http://w3m.sourceforge.net/

あなたのシステムにすでに emacs-w3m がインストールされているのならば、 (see Nnshimbun (Emacs-w3m-ja)) を参照して下さい。

RSS
---

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

RSS はとても規則的かつ良質なインターフェースで、gnus がグループを常に新しくしておくための情報を得ることができます。

Feed を講読するには、概略バッファから G R を使って下さい---feed の所在の入力を求められるでしょう。

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

あなたの講読目録を 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-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 部分メッセージ (multipart)。

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 ファイルから削除されます。

Namazu を使ってメールの山から記事を取り出す
-------------------------

メールは日々貯まっていくばかりです。流量の多いメーリングリストを購読している場合には、特に。でも、大抵の場合、価値ある記事はごく少数で、その記事を大量の記事の山から見つけ出すのは、とても困難なことです。

こういったことこそ、コンピュータがしてくれるべき仕事ですよね。Gnus は、 Namazu を使って、メールの山からあなたの好きなキーワードを含む記事を見つけ出す方法を提供します。

最初に悲しいお知らせがひとつ。gnus-namazu.el は、現時点では、 nnml バックエンドあるいは nnmh バックエンドによって保存されている記事と、gnus-cache-enter-article によって永続化された記事しか、取り扱うことができません。nnimap バックエンドや nnmbox バックエンドを使っている人は、ごめんなさい。

それでは気を取り直して、まず、Namazu を使えるようにしましょう。詳しいことは、次のページで知ることができます。

       http://namazu.org/

次に、あなたの秘蔵のメールと永続記事の山の索引を作るために、 M-x gnus-namazu-create-index としてください。さあ、これで準備ができたはずです。

グループバッファでC-c C-nと入力すると、検索式を尋ねられますから、適当な単語を入力してください。例えば:

       C-c C-n gnus namazu RET

こうすると、gnus と namazu の双方のキーワードを同時に含むメールを全て探し出し、それらのメールからなる仮想グループを作成します (see Virtual Groups)。

C-c C-nによって呼び出される命令 gnus-namazu-search は、 gnus の通常の数字接頭辞や、プロセス接頭辞を理解します。ですから、あなたが、あるグループだけを対象として検索を実行したいならば、そのグループの行に移動して、次のように検索することができます。

       1 C-c C-n namazu RET

また、概略バッファから、いきなり検索することもできます。この場合、検索対象は、自動的にそのグループに限定されます。例えば、あなたがあるグループを閲覧中に、そのグループにおける自分の過去を振り返りたくなったら、次のようにすれば良いのです。

       C-c C-n +from:"Your E-Mail Address" RET

Namazu は、事前に準備された索引を用いて検索を行うように設計された検索エンジンなので、索引に登録されていないファイルは完全に無視されます。つまり、定期的に mknmz を呼び出して、新たなメールの索引を追加しないと、新しいメールはいつまでたっても検索対象にならないことになります。 gnus-namazu.el は、gnus-namazu-index-update-interval に指定された期間毎に自動的に索引を更新する機能を提供しています。ディフォルトの設定では、3日おきに索引を更新するようになっていますが、もっと頻繁に (例えば1日おき) に更新するようにしたいならば、以下の設定を ~/.gnus.el に追加してください。

     (setq gnus-namazu-index-update-interval 86400)

逆に、索引の更新を自動的に行いたくないならば、以下の指定を ~/.gnus.el に追加してください。

     (setq gnus-namazu-index-update-interval nil)

この場合、索引を手動で更新するために M-x gnus-namazu-update-all-indices とする必要があるかもしれません。

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)。

     Use a customization buffer to set all of the selected category's parameters at one time (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, see Agent Variables 参照)。 Gnus が切り離されている場合、ニュースは常に queue されるだけです。

メッセージを送信するために、下書きグループから、そこで使える特別な命令を使って送ることも、グループバッファ内で J S を使って、下書きグループ内のすべての送信可能なメッセージ送信することもできます。ニュースの投稿は Gnus が差し込まれているときだけできますが、メールはいつでも送信することができます。

切り離されているときにメールの送信ができず、かつ切り離されているときにうっかり J S を叩いてしまうことが心配ならば、Gnus にあなたの行動を確認させることができます (gnus-agent-prompt-send-queue, see 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 環境を Control する
-------------------------

ここまで読んで来られて、エージェントが非常に便利な機能である事が分かったと思います。ただ、不満な点があるとすると、毎回 J j や J S 等をキーで作業しなければならないことでしょう。オンラインと同じような操作でやりとりできたら、と考えた事はありませんか? gnus-offline はその機能を提供します。(筆者の趣味で gnus-agent を使用する事を推奨します。MIEE については後述参照)

*Group* バッファで g を押す事で

      (Dialup の必要な環境では Dialup) ->
       Mail の取得 ->
       Spool に溜った message の送信 ->
       News の送信 ->
       不要な記事の expire

までを行います。

インストールはいたって簡単。(ここまでで gnus-agent の設定は終っていると仮定します) ~/.emacs の gnus-agent の設定のちょいと前に

     (load "gnus-ofsetup")
     (gnus-setup-for-offline)
     (load gnus-offline-setting-file)

POP といれ、Emacs を再起動してください。すると、さまざまな質問をされると思います。そこでは、あなたの環境にあった答えをしてください。質問が終ると、設定用のファイル ~/.gnus-offline.el が作成されます。ここに、必要な設定全てが書かれています。Gnus の起動が終り、(多分 POP サーバーのパスワードを聞かれると思いますが) *Group* バッファになったら、J j や J S 等の操作は必要ありません。 News/Mail を新規で取得したければ、*Group* バッファで g を押すだけです。

MIEE = Message Intercepting and Entrusting Emacs library. Message を横取りして、offline で post/send するための汎用ライブラリです。

この MIEE を使うと gnus-offline を用いてnnspool もコントロールする事ができます(ここでは述べませんが…)。(もちろん gnus-agent + MIEE という組合せも可能です) MIEE は http://www.shiojiri.ne.jp/%7Et-ichi/lisp/miee.el から取って来る事ができます。gnus-setup-for-offline で設定した場合には、MIEE の設定はいっさいしなくてもかまいません。

gnus-offline-articles-to-fetch
     この変数は取得する記事の種類を指定します。'mail の場合は、Mail だけを取得します。'news の場合は、News だけを取得します。'both の場合は、 Mail/News 両方を取得します。

gnus-offline-load-hook
     この変数は gnus-offline が load される前に評価される hook です。

gnus-offline-before-online-hook
     この変数は Gnus が Online(Plugged) 状態になる直前に評価される hook です。

gnus-offline-after-online-hook
     この変数は Gnus が Offline(UnPlugged) 状態になった後に評価される hook です。

gnus-offline-interval-time
     この変数で指定された間隔 (秒数) で gnus-offline-articles-to-fetch で指定された article を取得します。動作にはgnus-daemon を使用しています。

gnus-offline-dialup-function
     この変数で指定された関数が dialup 時に実行され、Dialup しサーバーに接続します。

gnus-offline-hangup-function
     この変数で指定された関数が hangup 時に実行され、サーバーとの回線を切断します。

エージェントの問題点
----------

Gnus Agent はよくある他のオフラインニュースリーダーのようには動作しません。これらは想像的な人からの良くある質問です:

接続されているときに記事を読んだら、それは 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
          本体 (body) にスコアを付けます。

     h
          ヘッダー (head) にスコアを付けます。

     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, CharsDate です。これらのヘッダーに加えて、 gnus に記事全体を取得して,記事のより大きな部分で合致を行うようにする三つの文字列があります: Body は記事の本体 (Body) で合致を実行し、 Head は記事のヘッダー (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-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)

可能性は無限大です。

上級スコアのちょっとした秘訣
--------------

& と | 論理作用子は、短縮回路論理を行います。すなわち、その作用の結果が明らかになって時点で、引数を実行過程にかける事を止めます。例えば、& の引数の評価が 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-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-compile-user-specs を nil にしていて (初期値はt)、これらの上級参照をたくさん使っているなら、T-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-* 変数は文字列か文字列を返す関数を指すシンボルのどちらかである必要があります。マウスがプロパティの設定されているテキストの上を通過すると、バルーンウィンドウが現れて、文字列を表示します。これの詳しい情報は Tooltips (The Emacs Manual) (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 などなどです。通常 T-gnus はこれらの変数をバイトコンパイルして使うので、速度低下は最小限に食い止められます。しかし gnus-compile-user-specs を nil (初期値は t) にした場合は、不運な事にそれらを変更すると大変重大な速度低下を引き起こす事になります。(これらの変数の初期値はそれらに関連付けられたバイトコンパイルされた関数を持っていますが、利用者作成のものはもちろんそうではありません。)

これを改善するために、変数を弄りまわして、(なんとなく) 満足したと感じた後で、M-x gnus-compile を実行する事ができます。これは新しい指定がバイトコンパイルされ、もう一度最高速度に復帰できるという事です。ただし T-gnus はこれらのバイトコンパイルされた指定をファイル .newsrc.eld に保存しません。

gnus-compile-user-specs
     この値を nil 以外にしておくと、利用者が作成した行書法仕様変数を自動的にコンパイルします。初期値は t で、 gnus-*-line-format-spec の各内部変数の値に影響します。

モード行
====

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 発行者が誰であるかと言っているかを証明する関数でなくてはなりません。初期設定では mc-verify であり、これは Mailcrypt 関数です。もしこれが非常に遅くて、あなたが証明結果を気にしない (これはたぶん危険です) のであれば、この変数を nil にすることができます。

     もし署名済みの NoCeM メッセージを証明済み、未署名のメッセージを未証明 (でもそれを使う) としたいのなら、以下のようにすることができます。

          (setq gnus-nocem-verifyer 'my-gnus-mc-verify)

          (defun my-gnus-mc-verify ()
            (not (eq 'forged
                     (ignore-errors
                       (if (mc-verify)
                           t
                         'forged)))))

     まあ、これはたぶん危険でしょうけどね。

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$")

画像の拡張
=====

XEmacs それに Emacs 21 (MS ウィンドウズの Emacs 21 はまだ画像をサポートしていません。) は絵やその他のものを表示することができるので、 gnus はこれを利用することにします。

X-Face
------

X-Face ヘッダーは、メッセージの著者を表わすことになっている 48× 48 画素の白黒 (1 bit の深さ) の絵を描きます。これは進化し続けるあまたのメールとニュースリーダーによってサポートされるでしょう。

今や Gnus は X-Face ヘッダーをデコードするために、通常 Emacs では ELisp で書かれた内部 uncompface プログラムを使います。それはどんな外部プログラムも必要としない一方、遅いマシンを使っている場合はそれを遅く感じるかもしれません。そんな場合は、以下の変数を変更することができます:

uncompface-use-external
     内部デコーダと外部デコーダのどちらが使われるべきかを指定します。 nil は ELisp で書かれた内部 uncompface プログラムを使うことを意味し、t は外部デコーダを使うことを意味します。ディフォルト値はホストマシンが遅いかどうかを検査してそれを決めることを意味する undecided で、uncompface-use-external-threshold (それを参照) によって制御されます。

uncompface-use-external-threshold
     ホストマシンが遅いかどうかを検査するための秒数です。ELisp で書かれた内部 uncompface プログラムを使って X-Face をデコードするのにかかる時間がこの値より大きい場合は、外部デコーダの使用に変更されます。ディフォルトは 0.1 秒です。

内部デコーダが無効にされる場合、あるいは XEmacs を使っている場合は、 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 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 のファイル名をパラメータとして受け取り、shell コマンド 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-database
     Picon データベースの場所です。これは news, domains, users (などなど) のサブディレクトリーが含まれているディレクトリーのリストです。("/usr/lib/picon" "/usr/local/faces") がディフォルトです。

gnus-picon-news-directories
     gnus-picon-database からニュースグループ用のフェースを探すためのサブディレクトリーのリストです。ディフォルトは ("news") です。

gnus-picon-user-directories
     gnus-picon-database からユーザのフェースを探すためのサブディレクトリーのリストです。("local" "users" "usenix" "misc") がディフォルトです。

gnus-picon-domain-directories
     gnus-picon-database からドメイン名のフェースを探すためのサブディレクトリーのリストです。ディフォルトは ("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.cypherspace.org/~adam/hashcash/ を参照して下さい。さらなる情報が http://www.camram.org/ で見つかるでしょう。

送信するメッセージのそれぞれについて hashcash を呼ぼうと思うなら、こんなふうにして下さい:

     (require 'hashcash)
     (add-hook 'message-send-hook 'mail-add-payment)

hashcash.el ライブラリは http://users.actrix.gen.nz/mycroft/hashcash.el か開発版の gnus の contrib ディレクトリにあります。

いくつかの追加の変数の設定もしなければなりません:

hashcash-default-payment
     この変数はハッシュの衝突を成すディフォルトのビット数を示します。規定値は 0 で、何も行なわれないことを意味します。提案されている有効な値は 17 から 29 までの数です。

hashcash-payment-alist
     何人かの受取人は、あなたにディフォルトより多くの CPU 時間を費やすことを要求するかもしれません。この変数は (ADDR AMOUNT) の形式の要素のリストで、ADDR は受取人 (メールアドレスかニュースグループ)、AMOUNT は必要とされる衝突のビット数です。これはまた (ADDR STRING AMOUNT) の要素を持つことも可能で、STRING は文字列 (通常はメールアドレスかニュースグループ名) として使われます。

hashcash
     hashcash バイナリがインストールされている場所を示します。

今のところ gnus に hashcash クッキーを認証する手段はありません。あなたが手作業でメールをふるいにかけるスクリプトをカスタマイズすることが求められています。しかし、この分野における改良は有用な貢献になるでしょう。

Spam ELisp パッケージを使った Spam の濾過
-----------------------------

spam.el の真の目的は spam 検出と濾過のための官制センターを gnus の中に持つことです。そのために spam.el は二つのことを行ないます: 新しいメールを濾過し、spam または ham として知られるメールを分析することです。Ham は spam.el のいたる所で spam ではないメッセージを示すために使う名前です。

第一に、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 のために新着メールを検査するとき、およびグループを抜けるときです。

新着メールの取得は、二つの方法の一方で行なわれます。新着メールを分割するか、グループに入るときに新しい記事を ham と spam に分類するかの、どちらでも可能です。

新着メールの分割は、nnml や nnimap のように、新しいメールが Spool File と呼ばれる一つのファイルになるバックエンドに、より適しています。See 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.

TODO: spam.el はすべての統計データベースをトレーニングするための一定不変の方法を提供する必要があります。いくつかはその機能を自前で持っていますが、そうでないものもあります。

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 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.ham に移されます。

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 として分類されます。

 -- 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) を使います。spam-use-hashcash が正しく働くようにするために、hashcash.el を読み込んでおかなければなりません。 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 backend
....................

 -- 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 にする。")

     spam-list-of-checks に

          (spam-use-blackbox . spam-check-blackbox)

     を追加。spam-list-of-processors に

          (gnus-group-ham-exit-processor-blackbox  ham spam-use-blackbox)
          (gnus-group-spam-exit-processor-blackbox spam spam-use-blackbox)

     を追加。spam-registration-functions に

          (spam-use-blackbox spam-blackbox-register-routine
                             nil
                             spam-blackbox-unregister-routine
                             nil)

     を追加。

     手始めに bogofilter の登録/削除ルーチンを使って登録/削除ルーチンを、またはもっと Blackbox に適切な他の登録/削除ルーチンを書いて下さい。

 2. 関数

     spam-check-blackbox 関数を書いて下さい。それは他の習慣に倣って nil か spam-split-group を返さなければなりません。あなたにできることの例は、既存の spam-check-* 関数を参照してください。また、あなたがそうでない理由を完全に理解していないならば、テンプレートに齧り付いて下さい。

     ブラックボックスが、それが動作するためにメッセージ全体を必要とする統計的メール分析器であるのならば、 spam-list-of-statistical-checks に spam-use-blackbox を追加することを忘れないで下さい。

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))

     を加えて下さい。それをパラメータと変数のカスタマイズの二回について行なうことを確かめて下さい。

     gnus.el のグループパラメータ spam-autodetect-methods に

          (variable-item spam-use-blackbox)

     を加えて下さい。

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 は梅田政信氏によって書かれました。94年の夏が忍び寄ってくるころ、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 は受信者に開封確認を要求することができます。

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
-------

T-gnus は以下のもので動作します:

  * Emacs 21.1 とそれ以上。

  * XEmacs 21.4 以上の Mule 機能付き

  * Meadow 1.00 以上。(Mule for Windows では動きません。)

この Gnus の版はこれより古いどんな Emacsen でも完全に動作しないでしょう。少なくとも、信頼できる動作はしないでしょう。古い版の gnus は古い Emacs の版でも動作するでしょう。とは言うものの、T-gnus はバージョン 21.1.1 未満の XEmacs, 例えば 20.4 でも使えるかもしれません。詳しいことは T-gnus の配布に含まれている README ファイルを読んで下さい。

いろいろなプラットフォームの 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 と see 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 の多くの部分に影響していて、たくさんの新しいコマンドが追加されています。詳細はマニュアルを参照して下さい。(訳注: T-gnus は SEMI および FLIM の諸機能に基づいています。)

  * Gnus はまた各国語対応になりました。ここでは要約できないくらいに Gnus の多くの部分に影響していて、新しいたくさんの変数が追加されています。(訳注: T-gnus は SEMI および FLIM の諸機能に基づいています。)

  * 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 の新しい機能:

訳注: Gnus は独自に MIME の機能を持っているのに対して、 T-gnus は SEMI や FLIM に頼っています。したがって、以下で説明されているいくつかの機能は T-gnus では使えないことに注意して下さい。

  * 領域が活性化されている場合、 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. (訳注: T-gnus のための FAQ は永らく改定されていません。)

  * 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 Mail Variables (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 Security (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.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)
     サーバーにグループの情報を尋ね、未読記事の数を演算する行為は グループを活動化する と呼ばれています。非活動グループはグループバッファに * とともに一覧表示されます。

サーバー (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-activie-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 は X-Face ヘッダーをデコードするために、通常 Emacs では ELisp で書かれた内部 uncompface プログラムを使います。それが遅く感じる場合は、uncompface-use-external を t に設定して下さい。See X-Face.

問題解決
====

Gnus は箱から出してすぐに 非常に よく動作します---何も問題の起こることは想像できません、本当に。

オッホン。

 1. あなたのコンピュータのスイッチが入っている事を確かめて下さい。

 2. 本当に現行の gnus 版を読み込んでいる事を確認して下さい。今まで GNUS を実行してきたのであれば、gnus が動作するように一度 Emacs を終了して再起動する必要があります。

 3. M-x gnus-version を試して下さい。もし、 T-gnus 6.17.* (based on Gnus v5.10.*; for SEMI 1.1*, FLIM 1.1*) のようなものが出てきたなら、正しいファイルが読み込まれています。そうならない場合は、古い .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 ではない値を返さなければなりません。

     この関数から返される結果のデータはありません。

(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]