Gnus wickelt den Zugriff auf Gruppen ausschliesslich über sog. "Backends" ab. Diese kümmern sich um den phys. Zugriff auf eine bestimmte Quelle für die Nachrichten. Wichtigste Backends: `nntp' für NNTP-Server-Zugriff, `nnspool' für local spool (?). Gnus selber kennt also bspw. das NNTP-Protokoll nicht, sondern nur das Backend namens `nntp'. Dieses übernimmt dann den Zugriff auf den Newsserver über NNTP. Die vollständige Identifikation einer Gruppe in Gnus besteht somit aus dem Backend-Namen, dem "Server-Namen" (identifiziert irgendeine Art von Backend-spezifischem Provider, Beispiel: Hostname des Newsservers bei nntp) und dem Gruppennamen in der Form: Backendname+Servername:Gruppenname Beispiel: nntp+some.where.edu:soc.motss Gruppe `soc.motss' auf dem NNTP-Server `some.where.edu'. Backend-Name und Servername bilden zusammen einen sog. "virtuellen Server". Der virt. Server, von dem man normalerweise seine News holt, wird in `gnus-select-method' eingetragen. Beispiel: (setq gnus-select-method '(nntp "news.cs.tu-berlin.de")) Die Liste der definierten Server wird im Server-Puffer editiert (erreichbar aus dem Group-Puffer mit `^') Das, was im Server-Buffer interaktiv editiert werden kann (Liste der Server), kann ebenso in .gnus in den Variablen "gnus-select-method" (s.o.) ("primäres" Backend, meistens der am häufigsten benutzte Newsserver) und "gnus-secondary-select-methods" (zusätzliche Backends, eingestellt werden. Die Backends können über zugehörige Variablen konfiguriert werden. Beispiele für solche Variablen sind etwa `nntp-server-opened-hook' oder `nnspool-spool-directory'. Genaueres siehe Manual: Select Methods/Getting News/{NNTP,News Spool}. Fragen: Welche Mail-Backends gibt es? nnmh? nnml? AW: `nnbabyl', `nnml', `nnmh', `nnfolder' (Siehe Manual: Select Methods/Getting Mail/Choosing a Mail Backend) nnmail Synonym für nnml? AW: Wohl nicht: nnmail-xxx heißen Variablen, die von allen Mail-Backends gleichermaßen benutzt werden (Select Methods/Getting Mail/Mail Backend Variables). Unterschied zwischen mail-sources und mail-backends? C-h v mail-sources : (mail sources are) "where the mail backends will look for incoming mail." Beispiel für mail-sources: (setq mail-sources '((file :path "/var/spool/mail/olaf" :plugged t))) (andere Möglichkeiten: POP3, Pipe, ...) Jup, Gnus holt Mail aus den in "mail-sources" angegebenen Quellen und schreibt sie in ein Backend hinein. In welches? Die Doku scheint nirgendwo richtig zu sagen, wo geholte Mail hingepackt wird. Irgednwie packt er sie in eines der Backends aus "gnus-secondary-select-methods". Hmm... wahrscheinlich benutzt er einfach die Variable "nnmail-split-methods": (setq nnmail-split-methods '(("mail.4ad" "From:.*4ad") ("mail.junk" "From:.*Lars\\|Subject:.*buy") ("mail.misc" ""))) Da steht drin, in welche Gruppen die aus den "mail-sources" (s.o.) geholten Mails einsortiert werden sollen. Diese Gruppen (im Beispiel: mail.4ad, mail.junk, mail.misc) können dann auf irgendeinem x-beliebigen Backend liegen. Agent-Modus von Gnus (Info-Manual Select Methods/Gnus Unplugged) ---------------------------------------------------------------- - Zum Offline-Lesen von News - Prinzipielles Konzept: - Gnus kann zwischen Online- und Offline-Modus umgeschaltet werden - Konfiguration erfolgt so, als ob Gnus staendig online wäre (z.B. kann man weiterhin den NNTP-Server seines ISPs als Primary Server eintragen) - bei allen Aktionen, die auf virt. Server zugreifen, prüft Gnus, ob der Online-Modus gerade aktiv ist. Wenn nicht, wird nicht wirklich auf den Server zugegriffen(1), sondern auf seine lokale `Vertretung'. Beispiel: Wenn im Offline-Modus eine Gruppe zum Lesen ausgewählt wird, holt Gnus sie nicht von ihrem Server, sondern aus dem lokalen Cache des Agents (in den sie irgendwann vorher im Online-Modus hineingeladen worden sein muss). Wenn im Offline-Modus eine Nachricht abgeschickt wird, wird sie nicht wirklich an den Server geschickt, sondern in eine spezielle Gruppe ("queue") geschrieben. Ist man später wieder im Online-Modus, kann man alle Nachrichten aus der Queue mit `JS' (im Group-Puffer) abschicken. - Gnus-Agent wird mit (gnus-agentize) (i.d.R. in .gnus) aktiviert. - mit J j (gnus-agent-toggle-plugged) wird gnus zwischen On-und Offlinemodus umschaltet - mit J s (gnus-agent-fetch-session) kann man (im Onlinemodus) Artikel herunterladen. Anschließend kann man (mit Jj) in den Offline-Modus schalten und die Verbindung trennen. - für jede Gruppe kann man festlegen, welche Artikel aus dieser Gruppe vollständig heruntergeladen werden sollen. Gnus lädt zunächst die Headerzeilen aller verfügbaren Artikel herunter und entscheidet dann, welche Artikel vollständig (inkl. Body) geladen werden sollen. Entscheidung wird anhand von 2 Kriterien gefällt: - Ein Prädikat (eine Zuordnung der Menge der Headerzeilen zu einem Wahrheitswert), das für Nachrichten, die zum Download vorgemerkt werden sollen, true ergeben muss. Beispiel: (and short (not spam)) ==> Artikel muss kürzer als gnus-agent-short-article Zeilen sein und darf kein Spam-Artikel sein. Man kann sich auch eigene Prädikate definieren, siehe Agent Categories/Category Syntax. - (scoring...) Diese Eigenschaften kann man jeder Gruppe einzeln zuweisen, und zwar über deren group parameters(2). Um z.B. obiges Prädikat einer Gruppe zuzuweisen, wird in den group parameters der Gruppe folgendes eingetragen: (agent-predicate and short (not spam)) Wenn man mehreren Gruppen die gleichen Prädikat- und Scorewerte zuweisen möchte, kann man eine _Kategorie_ anlegen. Eine Kategorie besteht aus einem Prädikats- und einem Scorewert sowie einer Liste von Gruppen, denen diese Dinge zugewiesen werden sollen. Kategorien werden erzeugt, gelöscht und editiert im _Kategoriebuffer_. Er lässt sich vom Group-Buffer aus mit J c aktivieren. Welche Gruppen werden durchsucht? Gnus wendet das obige Verfahren auf alle Gruppen, deren Level kleiner oder gleich `gnus-agent-handle-level' ist, an. `gnus-agent-handle-level' ist defaultmäßig gleich `gnus-level-subscribed', d.h. es werden genau alle abonnierten Gruppen durchsucht. Die immer vorhandene Kategorie `default' bezieht sich auf alle zu durchsuchenden Gruppen, die _nicht_ durch eine benutzerdefinierte Kategorie abgedeckt sind. Die Gruppenliste von `default' ist somit irrelevant (weil implizit vorgegeben) und bleibt deshalb i.d.R. leer. (1) Das gilt nur, wenn der betreffende Server zu den Servern gehört, für die der Agent zuständig ist. Welche das sein sollen, lässt sich im Server-Puffer (erreichbar aus dem Group-Puffer mit `^', s.o.) festlegen: Tastenkombination `Ja' (gnus-agent-add-server). (2) group parameters: Vom Group-Buffer aus mit "Gp" auf dem Gruppennamen aus editierbar. Wichtige Tastenkombinationen ---------------------------- Group-Puffer: Space,Return - Gruppe lesen Mit Prefix-Argument (- Space, - Return): alle Artikel (auch gelesene) anzeigen ^ - Server-Puffer öffnen Jc - Kategoriebuffer (Gnus-Agent) öffnen Tn - Neues Thema erzeugen Tm - akt. Gruppe in ein anderes Thema verschieben C-k - akt. Gruppe oder Thema ausschneiden C-y - zuvor ausgeschnittene(s) Gruppe/Thema an Cursorposition einfügen JS - In der queue-Gruppe zwischengespeicherte Nachrichten absenden Sl - Level der aktuellen Gruppe einstellen m - Mail schreiben Summary-Puffer: Space - Nachricht im Article-Puffer anzeigen d - einzelnen Artikel als gelesen markieren C-w - alle Artikel in der Region als gelesen markieren SF, F - Followup auf akt. Artikel SR, R - Mail-Antwort auf akt. Artikel SW - "wide"-Amtwort auf akt. Artikel, d.h. Mail an alle To - und Cc - Header schicken a - neuen Thread eröffnen B entf - Artikel entfernen (direkt aus dem Backend löschen, er ist dann richtig weg..) M-u - Alle Markierungen vom akt. Artikel entfernen /t - Anzeige limitieren auf Artikel, die älter als die einzugegebene Zahl von Tagen sind. Wenn Präfix angegeben, (`-/t'), auf jüngere Artikel limitieren /a - Anzeige limitieren auf bestimmten Autor /v - Anzeige limitieren auf alles über bet. Score-Wert Die Limit-Funktionen arbeiten inkrementell: die Limits werden in der Reihenfolge, in der sie angegeben wurden, auf einem Stack abgelegt und gemeinsam angewandt. /w - zuletzt angegebenes Limit vom Stack löschen. Wenn Präfix angegeben, alle Limits vom Stack löschen M-g - Die angezeigte Gruppe rescannen (neu einlesen und anzeigen) Mit prefix (- M-g): alle Artikel (auch gelesene) anzeigen Artikel-Puffer: n/p - nächste/vorherige Nachricht aus dem Summary-Puffer im Artikel-Puffer anzeigen Message-Puffer: C-c C-c - Nachricht absenden C-x C-s - Nachricht im Drafts-Ordner abspeichern. Um sie später weiterzubearbeiten: Nachricht im Draft-Ordner markieren und D e drücken. C-c C-t - Für News-Followups: `To'-Header an Mailadresse des Vorposters einfügen (i.e. posting&mailing) C-c C-a - Datei (Attachment) anhängen -- geht irgendwie nicht immer (s.u.) MIME-Kram Im Article-Buffer (Cursor muss auf einem MIME-Part stehen): o (`gnus-mime-save-part') - Part in Datei speichern v (`gnus-mime-view-part') - Part mit externem Viewer anzeigen RET (`gnus-article-press-button') - irgeneinen Callback aufrufen (siehe Manual). Führt normalerweise dazu, dass versucht wird, den Part "inline" anzuzeigen. QU: Wie (z.B.) Bilder automatisch inline anzeigen lassen? Im Message-Buffer: M-m f (`mml-attach-file') - Filename abfragen, als MIME-Part einfügen C-c C-a (s.o.) geht hier nicht (24.12.00) ?? Binding M-m f kommt aus dem mml-mode (mml-mode-map) Offenbar wird beim Start des message-mode das Binding C-c C-a => mail-interactive-insert-alias in message-mode-map eingefügt (und damit das ursprüngliche Binding C-c C-a => mml-attach-file überschrieben. mail-interactive-insert-alias stammt aus mail-abbrevs.elc (gehört zur Xemacs-Distribution, nicht zu Gnus). In der Tat ist hier im Message Mode der Minor-Mode "abbrev-mode" (stammt ebenfalls aus obiger mail-abbrevs.elc) aktiv. Muss irgendein Hook oder sowas sein...