Sync of Gnus with Emacs

Sync of Gnus with Emacs

[Reiner Steib]

Hi,

I'm working on the integration of Gnus 5.10 into Emacs for the
upcoming 21.4 release.

I'd like to ask all Gnus developers to apply bug fixes and doc
fixes[1] that went into the trunk (No Gnus) also in the v5-10 branch.
I will merge those changes into the branch "gnus-5_10-branch" of Emacs
then.  If you have write access for Emacs, you can apply there
yourself, of course.

In the course of the integration in Emacs, the changes from Emacs'
repository are also synced back to Gnus (trunk and v5-10 branch).

Bye, Reiner.

[1] The usual rules for commits to a stable Gnus series apply here.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: Sync of Gnus with Emacs

[Simon Josefsson]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:

> Hi,
>
> I'm working on the integration of Gnus 5.10 into Emacs for the
> upcoming 21.4 release.

Cool!

> I'd like to ask all Gnus developers to apply bug fixes and doc
> fixes[1] that went into the trunk (No Gnus) also in the v5-10 branch.
> I will merge those changes into the branch "gnus-5_10-branch" of Emacs
> then.  If you have write access for Emacs, you can apply there
> yourself, of course.
>
> In the course of the integration in Emacs, the changes from Emacs'
> repository are also synced back to Gnus (trunk and v5-10 branch).

Maybe when all this is finished would be a good time to release a new
Gnus 5.10 version from the v5-10 branch?

According to 'cvs diff -r v5-10-6 -r v5-10' there seem to be enough
changes to motivate a new release...

That is, assuming everything on v5-10, not already in v5-10-6, is in a
releasable shape; I suspect not many people punch daily on the v5-10
branch?

Re: Sync of Gnus with Emacs

[Reiner Steib]

On Mon, Aug 23 2004, Simon Josefsson wrote:

> Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:
>> I'm working on the integration of Gnus 5.10 into Emacs for the
>> upcoming 21.4 release.
>
> Cool!

Well, it's not really fun. ;-)

> Maybe when all this is finished would be a good time to release a new
> Gnus 5.10 version from the v5-10 branch?
>
> According to 'cvs diff -r v5-10-6 -r v5-10' there seem to be enough
> changes to motivate a new release...

ACK.  But it is not finished yet.  There are several relevant changes
(on Gnus in the Emacs trunk) that should be included.  When this is
done, the "gnus-5_10-branch" is merged into the Emacs trunk (see the
thread[1] on emacs-devel).  It doesn't make much sense to release
5.10.7 before.

BTW, as you are much more familiar with imap.el then me, could you
please look at the following change (and if you don't like it, discuss
a different solution with Stefan)?

,----
| 2004-08-22  Stefan Monnier  <monnier@iro.umontreal.ca>
| [...]
| 	* imap.el (imap-parse-address-list, imap-parse-body-ext):
| 	Disable incorrect use of `assert'.
`----

Bye, Reiner.

[1] http://thread.gmane.org/jwvwu04gc6f.fsf-monnier+emacs@gnu.org
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: Sync of Gnus with Emacs

[Simon Josefsson]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:

>> Maybe when all this is finished would be a good time to release a new
>> Gnus 5.10 version from the v5-10 branch?
>>
>> According to 'cvs diff -r v5-10-6 -r v5-10' there seem to be enough
>> changes to motivate a new release...
>
> ACK.  But it is not finished yet.  There are several relevant changes
> (on Gnus in the Emacs trunk) that should be included.  When this is
> done, the "gnus-5_10-branch" is merged into the Emacs trunk (see the
> thread[1] on emacs-devel).  It doesn't make much sense to release
> 5.10.7 before.

Right.

> BTW, as you are much more familiar with imap.el then me, could you
> please look at the following change (and if you don't like it, discuss
> a different solution with Stefan)?
>
> ,----
> | 2004-08-22  Stefan Monnier  <monnier@iro.umontreal.ca>
> | [...]
> | 	* imap.el (imap-parse-address-list, imap-parse-body-ext):
> | 	Disable incorrect use of `assert'.
> `----

I noticed this, and it looks fine.  The new code wouldn't raise an
error on buggy servers, though, but perhaps that is a bonus...

Re: Sync of Gnus with Emacs

[Ted Zlatanov]

On Mon, 23 Aug 2004, 4.uce.03.r.s@nurfuerspam.de wrote:

> I'd like to ask all Gnus developers to apply bug fixes and doc
> fixes[1] that went into the trunk (No Gnus) also in the v5-10 branch.
> I will merge those changes into the branch "gnus-5_10-branch" of Emacs
> then.  If you have write access for Emacs, you can apply there
> yourself, of course.

You mean that each developer should apply his own fixes to the 5-10
branch?  Some developers are busy and can't do this - should we build
a list of commits, sorted by name and date?  This may depend on an
unresponsive (for whatever reason) developer - we need to either
assign the task to someone else or forget about those fixes.

Ted

Re: Sync of Gnus with Emacs

[Reiner Steib]

On Mon, Aug 23 2004, Ted Zlatanov wrote:

> On Mon, 23 Aug 2004, 4.uce.03.r.s@nurfuerspam.de wrote:
>
>> I'd like to ask all Gnus developers to apply bug fixes and doc
>> fixes[1] that went into the trunk (No Gnus) also in the v5-10 branch.
>> I will merge those changes into the branch "gnus-5_10-branch" of Emacs
>> then.  If you have write access for Emacs, you can apply there
>> yourself, of course.
>
> You mean that each developer should apply his own fixes to the 5-10
> branch?  

Basically yes.  It's more time consuming for someone else to find out
whether the change is relevant for v5-10 and how to redo the change in
v5-10 in case of failed hunks from `patch'.  Because only doc- and
bugfixes should go there, the number of relevant changes should be
quite small.

Here is a suggestion on how to do it rather convenient (suggestions
for improvement very welcome):

- Open the ChangeLog file in the No Gnus directory.

- Goto 2004-01-04 (No Gnus starts here).  Search for your name with
  `C-r'.

- (If the entry might be relevant:) 
  Open the source file(s) *in the v5-10* directory, browse the log
  with `C-x v l', use `d' (log-view-diff) to view the change.

  If relevant, apply the hunk(s) using `C-c C-a' from the *vc-diff*
  buffer.  Add the ChangeLog entry using the current date.  Commit.

- Do this for the ChangeLogs in texi/ and lisp/.

- Post a message in this thread that you have checked (and installed)
  your changes.

> Some developers are busy and can't do this - should we build a list
> of commits, sorted by name and date?  

I think that the ChangeLogs are sufficient.

> This may depend on an unresponsive (for whatever reason) developer -
> we need to either assign the task to someone else or forget about
> those fixes.

Of course everyone can also apply changes from someone else.

Does this answer your questions?

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: Sync of Gnus with Emacs

[Katsumi Yamaoka]

I switched Gnus to v5-10.  Oh, how old this is!  I flinched.
Although I never make light of it, I like latest version very
much even if there may be some bugs. ;-)

>>>>> In <v9eklwy1s7.fsf@marauder.physik.uni-ulm.de>
>>>>>	Reiner Steib <4.uce.03.r.s@nurfuerspam.de> wrote:

> Here is a suggestion on how to do it rather convenient (suggestions
> for improvement very welcome):

> - Open the ChangeLog file in the No Gnus directory.

> - Goto 2004-01-04 (No Gnus starts here).  Search for your name with
>   `C-r'.

> - (If the entry might be relevant:) 
>   Open the source file(s) *in the v5-10* directory, browse the log
>   with `C-x v l', use `d' (log-view-diff) to view the change.

>   If relevant, apply the hunk(s) using `C-c C-a' from the *vc-diff*
>   buffer.  Add the ChangeLog entry using the current date.  Commit.

> - Do this for the ChangeLogs in texi/ and lisp/.

> - Post a message in this thread that you have checked (and installed)
>   your changes.

Thanks for the guidance.  I have some questions.

Isn't deleting Emacs 20 stuff necessity?  How about XEmacs stuff?
It includes replacing of gnus-point-at-bol with point-at-bol,
using of with-syntax-table and a lot of other things.

mm-inline-text-html-render-with-w3m doesn't work with the latest
released version of emacs-w3m.  May I change it and related stuff?
It is not a bugfix, though.  The emacs-w3m team aren't interested
in maintaining of old versions of emacs-w3m.

What date should we use for the ChangeLog entries?

Thanks in advance.

Re: Sync of Gnus with Emacs

[Reiner Steib]

On Wed, Aug 25 2004, Katsumi Yamaoka wrote:

> I switched Gnus to v5-10.  Oh, how old this is!  I flinched.
> Although I never make light of it, I like latest version very
> much even if there may be some bugs. ;-)

Are all the goodies you are missing from No Gnus mentioned in
texi/gnus-news.texi?

> Isn't deleting Emacs 20 stuff necessity?  How about XEmacs stuff?
> It includes replacing of gnus-point-at-bol with point-at-bol,
> using of with-syntax-table and a lot of other things.

I would leave those things in as they are.  Maybe there will be a
5.10.7 from this branch as Simon suggested (I don't know about Lars'
opinion, though).  I don't think that any XEmacs compatibility code in
the Emacs-bundled Gnus versions has been erased in the past.

> mm-inline-text-html-render-with-w3m doesn't work with the latest
> released version of emacs-w3m.  May I change it and related stuff?
> It is not a bugfix, though.  The emacs-w3m team aren't interested
> in maintaining of old versions of emacs-w3m.

If `mm-inline-text-html-render-with-w3m' doesn't work in v5-10, I
would consider it as a bug that should be fixed.

> What date should we use for the ChangeLog entries?

The date when you install the change in the branch.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: Sync of Gnus with Emacs

[Katsumi Yamaoka]

>>>>> In <v93c2baa45.fsf@marauder.physik.uni-ulm.de>
>>>>>	Reiner Steib <4.uce.03.r.s@nurfuerspam.de> wrote:

> On Wed, Aug 25 2004, Katsumi Yamaoka wrote:

>> I switched Gnus to v5-10.  Oh, how old this is!  I flinched.
>> Although I never make light of it, I like latest version very
>> much even if there may be some bugs. ;-)

> Are all the goodies you are missing from No Gnus mentioned in
> texi/gnus-news.texi?

I was being dizzy by the absence of some new features. ;-)

>> Isn't deleting Emacs 20 stuff necessity?  How about XEmacs stuff?
>> It includes replacing of gnus-point-at-bol with point-at-bol,
>> using of with-syntax-table and a lot of other things.

> I would leave those things in as they are.  Maybe there will be a
> 5.10.7 from this branch as Simon suggested (I don't know about Lars'
> opinion, though).  I don't think that any XEmacs compatibility code in
> the Emacs-bundled Gnus versions has been erased in the past.

I see.  I decided to leave them for the time being.

>> mm-inline-text-html-render-with-w3m doesn't work with the latest
>> released version of emacs-w3m.  May I change it and related stuff?
>> It is not a bugfix, though.  The emacs-w3m team aren't interested
>> in maintaining of old versions of emacs-w3m.

> If `mm-inline-text-html-render-with-w3m' doesn't work in v5-10, I
> would consider it as a bug that should be fixed.

I've commited the changes.  I'll ask the emacs-w3m team also for
confirming of it.

>> What date should we use for the ChangeLog entries?

> The date when you install the change in the branch.

I did so.  I'll investigate other things from now on.

Thank you,

Re: Sync of Gnus with Emacs

[Katsumi Yamaoka]

>>>>> In <b9ybrgz8t5x.fsf@jpl.org> Katsumi Yamaoka wrote:

> I'll investigate other things from now on.

I've installed all my changes that can be regarded as bugfixes
into the v5-10 branch.  I wish I hadn't done overkill.

Re: Sync of Gnus with Emacs

[Reiner Steib]

On Tue, Aug 24 2004, Reiner Steib wrote:

> Here is a suggestion on how to do it rather convenient (suggestions
> for improvement very welcome):

Because cvs unable to show diffs on a branch, we should generously add
tags before and after merging:

- Update and tag the v5-10 branch with a pre-merge tag:

  cd /path/to/v5-10
  cvs update
  cvs tag "gnus-5_10-pre-merge-whatever"

> - Open the ChangeLog file in the No Gnus directory.
>
> - Goto 2004-01-04 (No Gnus starts here).  Search for your name with
>   `C-r'.
>
> - (If the entry might be relevant:) 
>   Open the source file(s) *in the v5-10* directory, browse the log
>   with `C-x v l', use `d' (log-view-diff) to view the change.
>
>   If relevant, apply the hunk(s) using `C-c C-a' from the *vc-diff*
>   buffer.  Add the ChangeLog entry using the current date.  Commit.
                                               ^^^^^^^^^^^^

According to RMS' advice, I changed the ChangeLog dates to the date of
the installation of the change in the respective branch.  The dates in
the ChangeLog file should be monotonic.

> - Do this for the ChangeLogs in texi/ and lisp/.

- Tag the v5-10 branch with a post-merge tag:

  cd /path/to/v5-10
  cvs tag "gnus-5_10-post-merge-whatever"


In this way, we can create whatever.patch using...

  cvs diff -r "gnus-5_10-pre-merge-whatever" \
    -r "gnus-5_10-post-merge-whatever" > whatever.patch

... and apply it in Emacs' repository.

> - Post a message in this thread that you have checked (and installed)
>   your changes.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Sync of Gnus with Emacs

[Simon Josefsson]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:

> - Post a message in this thread that you have checked (and installed)
>   your changes.

I've back ported a bunch of fixes from HEAD to the v5-10 branch.  I
believe the only non-trivial part was the change of canlock.el and
sha1-el.el, which mostly was done to remove the use of OpenSSL.  The
code has been untouched on HEAD for several months, so I believe it is
safe though.  Of course, if someone feels otherwise, just revert that
part.

If somebody is syncing this with Emacs CVS, I think sha1-el.el should
be renamed to sha1.el, and the callers updated.  The old name doesn't
make sense now that sha1.el isn't around.  (The story used to be that
sha1.el was a generic front end to sha1-el.el and sha1-dl.el, the
latter which used dynamically loaded Emacs modules.)

I was worried that some Emacs20->21 fixes in HEAD might accidentally
been committed to v5-10 (which should work on Emacs 20 as well, IIUC),
but I was able to build v5-10 using emacs20, so I guess it is fine.

Re: Sync of Gnus with Emacs

[Reiner Steib]

On Wed, Sep 01 2004, Simon Josefsson wrote:

> I've back ported a bunch of fixes from HEAD to the v5-10 branch.

Thanks.

> If somebody is syncing this with Emacs CVS, I think sha1-el.el should
> be renamed to sha1.el, and the callers updated.  The old name doesn't
> make sense now that sha1.el isn't around.  (The story used to be that
> sha1.el was a generic front end to sha1-el.el and sha1-dl.el, the
> latter which used dynamically loaded Emacs modules.)

The file is already in the gnus-5_10-branch of Emacs, but not in the
trunk, yet.  Miles offered to do the merge, maybe he can consider
this.

I think renaming it is okay (but IMHO it should be renamed in Gnus'
repository, too).

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Sync of Gnus with Emacs

[Simon Josefsson]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:

> I think renaming it is okay (but IMHO it should be renamed in Gnus'
> repository, too).

Right, done, thanks.

Re: Sync of Gnus with Emacs

[Miles Bader]

On Wed, Sep 01, 2004 at 06:04:38PM +0200, Reiner Steib wrote:
> > If somebody is syncing this with Emacs CVS, I think sha1-el.el should
> > be renamed to sha1.el, and the callers updated.  The old name doesn't
> > make sense now that sha1.el isn't around.  (The story used to be that
> > sha1.el was a generic front end to sha1-el.el and sha1-dl.el, the
> > latter which used dynamically loaded Emacs modules.)
> 
> The file is already in the gnus-5_10-branch of Emacs, but not in the
> trunk, yet.  Miles offered to do the merge, maybe he can consider
> this.
> 
> I think renaming it is okay (but IMHO it should be renamed in Gnus'
> repository, too).

Yes, though since it's a fairly minor cosmetic thing, it can safely wait
until things have settled down a bit I think.

-Miles
-- 
.Numeric stability is probably not all that important when you're guessing.

Re: Sync of Gnus with Emacs

[Katsumi Yamaoka]

>>>>> In <iluisaydow4.fsf@latte.josefsson.org> Simon Josefsson wrote:

> If somebody is syncing this with Emacs CVS, I think sha1-el.el should
> be renamed to sha1.el, and the callers updated.  The old name doesn't
> make sense now that sha1.el isn't around.  (The story used to be that
> sha1.el was a generic front end to sha1-el.el and sha1-dl.el, the
> latter which used dynamically loaded Emacs modules.)

There are still sha1.el, sha1-el.el and sha1-dl.el in FLIM.  But
now that's ok even if a user accidentally loads sha1.elc of FLIM.
I've made changes in sha1-dl.el yesterday so that it can be used
with Gnus.  I think people using the dynamically loaded module
are rare, though.

Please note, the released FLIM version can't be used with Gnus
because of the old sha1 modules.  So, I recommend those who use
FLIM for the particular purpose upgrade it to the CVS version.
The snapshot which I made unofficially is there:

http://www.jpl.org/ftp/pub/m17n/flim-1_14-************.tar.gz
 or ftp://ftp.jpl.org/pub/m17n/flim-1_14-************.tar.gz

(Where `************' is a timestamp which will vary.)

XEmacs users had better also use the latest ecrypto package or
Sumo.

Another solution is to rearrange the order of load-path.  Those
packages are apt to be preceded than Gnus by default.

Re: Sync of Gnus with Emacs

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 381 bytes --]

See the attached patch, which is mostly spam.el-related changes to
gnus.texi, plus a small bug fix in gnus-registry.el and the 'imaps'
synonym to 'imap' in nnimap.el.

For the docs, I kept changelog entries as they were originally - same
date, same order (interleaved with others).  For the code, I made a
new changelog entry.

Sorry for the delay, I was on vacation.

Thanks
Ted


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: tzz.5-10.patch --]
[-- Type: text/x-patch, Size: 26042 bytes --]

? tzz.5-10.patch
Index: lisp/ChangeLog
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/ChangeLog,v
retrieving revision 6.2771.2.25
diff -u -r6.2771.2.25 ChangeLog
--- lisp/ChangeLog	3 Sep 2004 06:05:23 -0000	6.2771.2.25
+++ lisp/ChangeLog	7 Sep 2004 19:54:46 -0000
@@ -1,3 +1,11 @@
+2004-09-07  Teodor Zlatanov  <tzz@lifelogs.com>
+
+	* nnimap.el (nnimap-open-connection): allow 'imaps' as a synonym
+	for the 'imap' port in netrc files
+
+	* gnus-registry.el (gnus-registry-trim): watch out for negatives
+	in gnus-registry-trim
+
 2004-09-03  Katsumi Yamaoka  <yamaoka@jpl.org>
 
 	* gnus-sum.el (gnus-summary-insert-subject): Remove list
Index: lisp/gnus-registry.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/gnus-registry.el,v
retrieving revision 6.39.2.1
diff -u -r6.39.2.1 gnus-registry.el
--- lisp/gnus-registry.el	20 May 2004 06:13:11 -0000	6.39.2.1
+++ lisp/gnus-registry.el	7 Sep 2004 19:54:46 -0000
@@ -266,25 +266,27 @@
 (defun gnus-registry-trim (alist)
   "Trim alist to size, using gnus-registry-max-entries."
   (if (null gnus-registry-max-entries)
-      alist				; just return the alist
+      alist                             ; just return the alist
     ;; else, when given max-entries, trim the alist
-    (let ((timehash (make-hash-table 			    
-		     :size 4096
-		     :test 'equal)))
+    (let* ((timehash (make-hash-table
+		      :size 4096
+		      :test 'equal))
+	   (trim-length (- (length alist) gnus-registry-max-entries))
+	   (trim-length (if (natnump trim-length) trim-length 0)))
       (maphash
        (lambda (key value)
-	 (puthash key (gnus-registry-fetch-extra key 'mtime) timehash))
+         (puthash key (gnus-registry-fetch-extra key 'mtime) timehash))
        gnus-registry-hashtb)
 
       ;; we use the return value of this setq, which is the trimmed alist
       (setq alist
-	    (nthcdr
-	     (- (length alist) gnus-registry-max-entries)
-	     (sort alist 
-		   (lambda (a b)
-		     (time-less-p 
-		      (cdr (gethash (car a) timehash))
-		      (cdr (gethash (car b) timehash))))))))))
+            (nthcdr
+             trim-length
+             (sort alist 
+                   (lambda (a b)
+                     (time-less-p 
+                      (cdr (gethash (car a) timehash))
+                      (cdr (gethash (car b) timehash))))))))))
 
 (defun alist-to-hashtable (alist)
   "Build a hashtable from the values in ALIST."
Index: lisp/nnimap.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/nnimap.el,v
retrieving revision 6.71.2.2
diff -u -r6.71.2.2 nnimap.el
--- lisp/nnimap.el	30 Aug 2004 18:25:38 -0000	6.71.2.2
+++ lisp/nnimap.el	7 Sep 2004 19:54:46 -0000
@@ -723,10 +723,15 @@
 		     (int-to-string nnimap-server-port)
 		   "imap"))
 	   (alist (or (gnus-netrc-machine list server port "imap")
+		      (gnus-netrc-machine list server port "imaps")
 		      (gnus-netrc-machine list
 					  (or nnimap-server-address
 					      nnimap-address)
-					  port "imap")))
+					  port "imap"))
+		      (gnus-netrc-machine list
+					  (or nnimap-server-address
+					      nnimap-address)
+					  port "imaps")))
 	   (user (gnus-netrc-get alist "login"))
 	   (passwd (gnus-netrc-get alist "password")))
       (if (imap-authenticate user passwd nnimap-server-buffer)
Index: texi/ChangeLog
===================================================================
RCS file: /usr/local/cvsroot/gnus/texi/ChangeLog,v
retrieving revision 6.643.2.5
diff -u -r6.643.2.5 ChangeLog
--- texi/ChangeLog	31 Aug 2004 16:11:51 -0000	6.643.2.5
+++ texi/ChangeLog	7 Sep 2004 19:54:47 -0000
@@ -22,10 +22,35 @@
 	* gnus.texi (Mail Source Specifiers): Describe
 	`pop3-leave-mail-on-server'.
 
+2004-08-17  Teodor Zlatanov  <tzz@lifelogs.com>
+
+	* gnus.texi (IMAP): add comments about imaps synonym to imap in
+	netrc syntax
+
+2004-08-15  Simon Josefsson  <jas@extundo.com>
+
+	* gnus.texi (IMAP): Add example.  Suggested and partially written
+	by Steinar Bang <sb@dod.no>.
+
 2004-05-19  Reiner Steib  <Reiner.Steib@gmx.de>
 
 	* gnus.texi (Oort Gnus): Mention new behavior of `F' and `R' when
 	the region is active.
+
+2004-03-29  Teodor Zlatanov  <tzz@lifelogs.com>
+
+	* gnus.texi (Spam ELisp Package Sequence of Events): some clarifications
+	(Spam ELisp Package Global Variables)
+	(Spam ELisp Package Global Variables): more clarifications
+
+2004-01-23  Teodor Zlatanov  <tzz@lifelogs.com>
+
+	* gnus.texi (Spam ELisp Package Filtering of Incoming Mail):
+	mention spam-split does not modify incoming mail
+
+2004-01-22  Teodor Zlatanov  <tzz@lifelogs.com>
+
+	* gnus.texi (Spam ELisp Package Sequence of Events): fix typo
 
 2004-01-04  Reiner Steib  <Reiner.Steib@gmx.de>
 
Index: texi/gnus.texi
===================================================================
RCS file: /usr/local/cvsroot/gnus/texi/gnus.texi,v
retrieving revision 6.603.2.5
diff -u -r6.603.2.5 gnus.texi
--- texi/gnus.texi	31 Aug 2004 16:11:50 -0000	6.603.2.5
+++ texi/gnus.texi	7 Sep 2004 19:54:48 -0000
@@ -14011,8 +14011,8 @@
 @code{save-excursion} and @code{save-restriction} in the example
 above.  Also note that with the nnimap backend, message bodies will
 not be downloaded by default.  You need to set
-@code{nnimap-split-download-body} to t to do that (@pxref{Splitting in
-IMAP}).
+@code{nnimap-split-download-body} to @code{t} to do that
+(@pxref{Splitting in IMAP}).
 
 @item (! @var{func} @var{split})
 If the split is a list, and the first element is @code{!}, then
@@ -16209,7 +16209,17 @@
 A file containing credentials used to log in on servers.  The format is
 (almost) the same as the @code{ftp} @file{~/.netrc} file.  See the
 variable @code{nntp-authinfo-file} for exact syntax; also see
-@ref{NNTP}.
+@ref{NNTP}.  An example of an .authinfo line for an IMAP server, is: 
+
+@example
+machine students.uio.no login larsi password geheimnis port imap
+@end example
+
+Note that it should be @code{port imap}, or @code{port 143}, if you
+use a @code{nnimap-stream} of @code{tls} or @code{ssl}, even if the
+actual port number used is port 993 for secured IMAP.  For
+convenience, Gnus will accept @code{port imaps} as a synonym of
+@code{port imap}.
 
 @item nnimap-need-unselect-to-notice-new-mail
 @vindex nnimap-need-unselect-to-notice-new-mail
@@ -22249,16 +22259,18 @@
 messages per day from @samp{random-address@@vmadmin.com}, you block
 @samp{vmadmin.com}.  If you get 200 messages about @samp{VIAGRA}, you
 discard all messages with @samp{VIAGRA} in the message.  If you get
-lots of spam from China, for example, you try to filter all mail from
-Chinese IPs.
+lots of spam from Bulgaria, for example, you try to filter all mail
+from Bulgarian IPs.  
 
-This, unfortunately, is a great way to discard legitimate e-mail.  For
-instance, the very informative and useful RISKS digest has been
-blocked by overzealous mail filters because it @strong{contained}
-words that were common in spam messages.  The risks of blocking a
-whole country from contacting you should also be obvious, so don't do
-it if you have the choice.  Nevertheless, in isolated cases, with
-great care, direct filtering of mail can be useful.
+This, unfortunately, is a great way to discard legitimate e-mail.  The
+risks of blocking a whole country (Bulgaria, Norway, Nigeria, China,
+etc.) or even a continent (Asia, Africa, Europe, etc.) from contacting
+you should be obvious, so don't do it if you have the choice.
+
+In another instance, the very informative and useful RISKS digest has
+been blocked by overzealous mail filters because it @strong{contained}
+words that were common in spam messages.  Nevertheless, in isolated
+cases, with great care, direct filtering of mail can be useful.
 
 Another approach to filtering e-mail is the distributed spam
 processing, for instance DCC implements such a system.  In essence,
@@ -22435,8 +22447,8 @@
 
 Note that with the nnimap backend, message bodies will not be
 downloaded by default.  You need to set
-@code{nnimap-split-download-body} to t to do that (@pxref{Splitting in
-IMAP}).
+@code{nnimap-split-download-body} to @code{t} to do that
+(@pxref{Splitting in IMAP}).
 
 That is about it.  As some spam is likely to get through anyway, you
 might want to have a nifty function to call when you happen to read
@@ -22672,8 +22684,8 @@
 @code{ham-process-destination} or the @code{spam-process-destination}
 depending on the article's classification.  If the
 @code{ham-process-destination} or the @code{spam-process-destination},
-whichever is appropriate, are nil, the article is left in the current
-group.
+whichever is appropriate, are @code{nil}, the article is left in the
+current group.
 
 If a spam is found in any group (this can be changed to only non-spam
 groups with @code{spam-move-spam-nonspam-groups-only}), it is
@@ -22685,11 +22697,11 @@
 @code{spam-log-to-registry} variable if you want spam to be processed
 no more than once.  Thus, spam is detected and processed everywhere,
 which is what most people want.  If the
-@code{spam-process-destination} is nil, the spam is marked as
+@code{spam-process-destination} is @code{nil}, the spam is marked as
 expired, which is usually the right thing to do.
 
-If spam can not be moved - because of a read-only backend such as NNTP,
-for example, it will be copied.
+If spam can not be moved---because of a read-only backend such as
+@acronym{NNTP}, for example, it will be copied.
 
 If a ham mail is found in a ham group, as determined by the
 @code{ham-marks} parameter, it is processed as ham by the active ham
@@ -22703,11 +22715,11 @@
 necessary, which is what most people want.  More on this in
 @xref{Spam ELisp Package Configuration Examples}.
 
-If ham can not be moved - because of a read-only backend such as NNTP,
-for example, it will be copied.
+If ham can not be moved---because of a read-only backend such as
+@acronym{NNTP}, for example, it will be copied.
 
 If all this seems confusing, don't worry.  Soon it will be as natural
-as typing Lisp one-liners on a neural interface... err, sorry, that's
+as typing Lisp one-liners on a neural interface@dots{} err, sorry, that's
 50 years in the future yet.  Just trust us, it's not so bad.
 
 @node Spam ELisp Package Filtering of Incoming Mail
@@ -22728,6 +22740,8 @@
 @code{nnimap-split-fancy}, depending on whether you use the nnmail or
 nnimap back ends to retrieve your mail.
 
+Also, @code{spam-split} will not modify incoming mail in any way.
+
 The @code{spam-split} function will process incoming mail and send the
 mail considered to be spam into the group name given by the variable
 @code{spam-split-group}.  By default that group name is @samp{spam},
@@ -22741,7 +22755,7 @@
 work depending on your server's tolerance for strange group names.
 
 You can also give @code{spam-split} a parameter,
-e.g. @samp{'spam-use-regex-headers} or @samp{"maybe-spam"}.  Why is
+e.g. @code{spam-use-regex-headers} or @code{"maybe-spam"}.  Why is
 this useful?
 
 Take these split rules (with @code{spam-use-regex-headers} and
@@ -22751,7 +22765,7 @@
  nnimap-split-fancy '(|
                       (any "ding" "ding")
                       (: spam-split)
-                      ;; default mailbox
+                      ;; @r{default mailbox}
                       "mail")
 @end example
 
@@ -22767,14 +22781,15 @@
 regex-headers check) will be after the ding rule:
 
 @example
- nnimap-split-fancy '(|
-;;; all spam detected by spam-use-regex-headers goes to "regex-spam"
-                      (: spam-split "regex-spam" 'spam-use-regex-headers)
-                      (any "ding" "ding")
-;;; all other spam detected by spam-split goes to spam-split-group
-                      (: spam-split)
-                      ;; default mailbox
-                      "mail")
+nnimap-split-fancy
+      '(|
+        ;; @r{all spam detected by @code{spam-use-regex-headers} goes to @samp{regex-spam}}
+        (: spam-split "regex-spam" 'spam-use-regex-headers)
+        (any "ding" "ding")
+        ;; @r{all other spam detected by spam-split goes to @code{spam-split-group}}
+        (: spam-split)
+        ;; @r{default mailbox}
+        "mail")
 @end example
 
 This lets you invoke specific @code{spam-split} checks depending on
@@ -22827,7 +22842,7 @@
 will be detected later.
 
 The format of the spam or ham processor entry used to be a symbol,
-but now it is a cons cell.  See the individual spam processor entries
+but now it is a @sc{cons} cell.  See the individual spam processor entries
 for more information.
 
 @vindex gnus-spam-newsgroup-contents
@@ -22905,18 +22920,16 @@
 determined by either the @code{ham-process-destination} group
 parameter or a match in the @code{gnus-ham-process-destinations}
 variable, which is a list of regular expressions matched with group
-names (it's easiest to customize this variable with
-@code{customize-variable gnus-ham-process-destinations}).  Each
-newsgroup specification has the format (REGEXP PROCESSOR) in a
-standard Lisp list, if you prefer to customize the variable manually.
-The ultimate location is a group name or names.  If the
-@code{ham-process-destination} parameter is not set, ham articles are
-left in place.  If the
+names (it's easiest to customize this variable with @kbd{M-x
+customize-variable @key{RET} gnus-ham-process-destinations}).  Each
+group name list is a standard Lisp list, if you prefer to customize
+the variable manually.  If the @code{ham-process-destination}
+parameter is not set, ham articles are left in place.  If the
 @code{spam-mark-ham-unread-before-move-from-spam-group} parameter is
-set, the ham articles are marked as unread before being moved.  
+set, the ham articles are marked as unread before being moved.
 
-If ham can not be moved - because of a read-only backend such as NNTP,
-for example, it will be copied.
+If ham can not be moved---because of a read-only backend such as
+@acronym{NNTP}, for example, it will be copied.
 
 Note that you can use multiples destinations per group or regular
 expression!  This enables you to send your ham to a regular mail
@@ -22944,18 +22957,16 @@
 the @code{spam-process-destination} group parameter or a match in the
 @code{gnus-spam-process-destinations} variable, which is a list of
 regular expressions matched with group names (it's easiest to
-customize this variable with @code{customize-variable
-gnus-spam-process-destinations}).  Each newsgroup specification has
-the repeated format (REGEXP GROUP) and they are all in a standard Lisp
-list, if you prefer to customize the variable manually.  The ultimate
-location is a group name or names.  If the
+customize this variable with @kbd{M-x customize-variable @key{RET}
+gnus-spam-process-destinations}).  Each group name list is a standard
+Lisp list, if you prefer to customize the variable manually.  If the
 @code{spam-process-destination} parameter is not set, the spam
 articles are only expired.  The group name is fully qualified, meaning
 that if you see @samp{nntp:servername} before the group name in the
-group buffer then you need it here as well.  
+group buffer then you need it here as well.
 
-If spam can not be moved - because of a read-only backend such as NNTP,
-for example, it will be copied.
+If spam can not be moved---because of a read-only backend such as
+@acronym{NNTP}, for example, it will be copied.
 
 Note that you can use multiples destinations per group or regular
 expression!  This enables you to send your spam to multiple @emph{spam
@@ -22971,15 +22982,15 @@
 
 @vindex spam-mark-only-unseen-as-spam
 Set this variable if you want only unseen articles in spam groups to
-be marked as spam.  By default, it is set.  If you set it to nil,
-unread articles will also be marked as spam.
+be marked as spam.  By default, it is set.  If you set it to
+@code{nil}, unread articles will also be marked as spam.
 
 @vindex spam-mark-ham-unread-before-move-from-spam-group
 Set this variable if you want ham to be unmarked before it is moved
 out of the spam group.  This is very useful when you use something
-like the tick mark @samp{!} to mark ham - the article will be placed
-in your ham-process-destination, unmarked as if it came fresh from
-the mail server.
+like the tick mark @samp{!} to mark ham---the article will be placed
+in your @code{ham-process-destination}, unmarked as if it came fresh
+from the mail server.
 
 @vindex spam-autodetect-recheck-messages
 When autodetecting spam, this variable tells @code{spam.el} whether
@@ -22997,87 +23008,86 @@
 
 From Ted Zlatanov <tzz@@lifelogs.com>.
 @example
-
-;; for gnus-registry-split-fancy-with-parent and spam autodetection
-;; see gnus-registry.el for more information
+;; @r{for @code{gnus-registry-split-fancy-with-parent} and spam autodetection}
+;; @r{see @file{gnus-registry.el} for more information}
 (gnus-registry-initialize)
 (spam-initialize)
 
-;; I like control-S for marking spam
+;; @r{I like @kbd{C-s} for marking spam}
 (define-key gnus-summary-mode-map "\C-s" 'gnus-summary-mark-as-spam)
 
 (setq
- spam-log-to-registry t ;; for spam autodetection
+ spam-log-to-registry t     ; @r{for spam autodetection}
  spam-use-BBDB t
- spam-use-regex-headers t               ; catch X-Spam-Flag (SpamAssassin)
- ;; all groups with "spam" in the name contain spam
- gnus-spam-newsgroup-contents '(("spam" gnus-group-spam-classification-spam))
- ;; see documentation for these
+ spam-use-regex-headers t   ; @r{catch X-Spam-Flag (SpamAssassin)}
+ ;; @r{all groups with @samp{spam} in the name contain spam}
+ gnus-spam-newsgroup-contents
+  '(("spam" gnus-group-spam-classification-spam))
+ ;; @r{see documentation for these}
  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
- ;; understand what this does before you copy it to your own setup!
+ ;; @r{understand what this does before you copy it to your own setup!}
  nnimap-split-fancy '(|
-                      ;; trace references to parents and put in their group
+                      ;; @r{trace references to parents and put in their group}
                       (: gnus-registry-split-fancy-with-parent)
-                      ;; this will catch server-side SpamAssassin tags
+                      ;; @r{this will catch server-side SpamAssassin tags}
                       (: spam-split 'spam-use-regex-headers)
                       (any "ding" "ding")
-                      ;; note that spam by default will go to "spam"
+                      ;; @r{note that spam by default will go to @samp{spam}}
                       (: spam-split)
-                      ;; default mailbox
+                      ;; @r{default mailbox}
                       "mail"))
 
-;; my parameters, set with `G p'
+;; @r{my parameters, set with @kbd{G p}}
 
-;; all nnml groups, and all nnimap groups except
-;; "nnimap+mail.lifelogs.com:train" and
-;; "nnimap+mail.lifelogs.com:spam": any spam goes to nnimap training,
-;; because it must have been detected manually
+;; @r{all nnml groups, and all nnimap groups except}
+;; @r{@samp{nnimap+mail.lifelogs.com:train} and}
+;; @r{@samp{nnimap+mail.lifelogs.com:spam}: any spam goes to nnimap training,}
+;; @r{because it must have been detected manually}
 
 ((spam-process-destination . "nnimap+mail.lifelogs.com:train"))
 
-;; all NNTP groups
-;; autodetect spam with the blacklist and ham with the BBDB
+;; @r{all @acronym{NNTP} groups}
+;; @r{autodetect spam with the blacklist and ham with the BBDB}
 ((spam-autodetect-methods spam-use-blacklist spam-use-BBDB)
-;; send all spam to the training group
+;; @r{send all spam to the training group}
  (spam-process-destination . "nnimap+mail.lifelogs.com:train"))
 
-;; only some NNTP groups, where I want to autodetect spam
+;; @r{only some @acronym{NNTP} groups, where I want to autodetect spam}
 ((spam-autodetect . t))
 
-;; my nnimap "nnimap+mail.lifelogs.com:spam" group
+;; @r{my nnimap @samp{nnimap+mail.lifelogs.com:spam} group}
 
-;; this is a spam group
+;; @r{this is a spam group}
 ((spam-contents gnus-group-spam-classification-spam)
 
- ;; any spam (which happens when I enter for all unseen messages,
- ;; because of the gnus-spam-newsgroup-contents setting above), goes to
- ;; "nnimap+mail.lifelogs.com:train" unless I mark it as ham
+ ;; @r{any spam (which happens when I enter for all unseen messages,}
+ ;; @r{because of the @code{gnus-spam-newsgroup-contents} setting above), goes to}
+ ;; @r{@samp{nnimap+mail.lifelogs.com:train} unless I mark it as ham}
 
  (spam-process-destination "nnimap+mail.lifelogs.com:train")
 
- ;; any ham goes to my "nnimap+mail.lifelogs.com:mail" folder, but
- ;; also to my "nnimap+mail.lifelogs.com:trainham" folder for training
+ ;; @r{any ham goes to my @samp{nnimap+mail.lifelogs.com:mail} folder, but}
+ ;; @r{also to my @samp{nnimap+mail.lifelogs.com:trainham} folder for training}
 
  (ham-process-destination "nnimap+mail.lifelogs.com:mail" 
                           "nnimap+mail.lifelogs.com:trainham")
- ;; in this group, only '!' marks are ham
+ ;; @r{in this group, only @samp{!} marks are ham}
  (ham-marks
   (gnus-ticked-mark))
- ;; remembers senders in the blacklist on the way out - this is
- ;; definitely not needed, it just makes me feel better
+ ;; @r{remembers senders in the blacklist on the way out---this is}
+ ;; @r{definitely not needed, it just makes me feel better}
  (spam-process (gnus-group-spam-exit-processor-blacklist)))
 
-;; Later, on the IMAP server I use the "train" group for training
-;; SpamAssassin to recognize spam, and the "trainham" group for
-;; recognizing ham - but Gnus has nothing to do with it.
+;; @r{Later, on the @acronym{IMAP} server I use the @samp{train} group for training}
+;; @r{SpamAssassin to recognize spam, and the @samp{trainham} group fora}
+;; @r{recognizing ham---but Gnus has nothing to do with it.}
 
 @end example
 
 @subsubheading Using @file{spam.el} on an IMAP server with a statistical filter on the server
-
 From Reiner Steib <reiner.steib@@gmx.de>.
 
 My provider has set up bogofilter (in combination with @acronym{DCC}) on
@@ -23115,7 +23125,7 @@
 messages are marked as spam (with @code{$}).  When I find a false
 positive, I mark the message with some other ham mark (@code{ham-marks},
 @ref{Spam ELisp Package Global Variables}).  On group exit, those
-messages are copied to both groups, @samp{INBOX} (were I want to have
+messages are copied to both groups, @samp{INBOX} (where I want to have
 the article) and @samp{training.ham} (for training bogofilter) and
 deleted from the @samp{spam.detected} folder.
 
@@ -23147,7 +23157,7 @@
     (spam-process (gnus-group-spam-exit-processor-report-gmane)))
 @end lisp
 
-Additionally, I use `(setq spam-report-gmane-use-article-number nil)'
+Additionally, I use @code{(setq spam-report-gmane-use-article-number nil)}
 because I don't read the groups directly from news.gmane.org, but
 through my local news server (leafnode).  I.e. the article numbers are
 not the same as on news.gmane.org, thus @code{spam-report.el} has to check
@@ -23702,7 +23712,7 @@
 Add this symbol to a group's @code{spam-process} parameter by
 customizing the group parameter or the
 @code{gnus-spam-process-newsgroups} variable.  When this symbol is added
-to a grup's @code{spam-process} parameter, the ham-marked articles in
+to a group's @code{spam-process} parameter, the ham-marked articles in
 @emph{ham} groups will be sent to the SpamOracle as samples of ham
 messages.  Note that this ham processor has no effect in @emph{spam} or
 @emph{unclassified} groups.
@@ -23742,7 +23752,7 @@
 @enumerate
 
 @item
-code
+Code
 
 @lisp
 (defvar spam-use-blackbox nil
@@ -23750,32 +23760,34 @@
 @end lisp
 
 Add
-@example
-    (spam-use-blackbox   . spam-check-blackbox)
-@end example
+@lisp
+(spam-use-blackbox   . spam-check-blackbox)
+@end lisp
 to @code{spam-list-of-checks}.
 
 Add
-@example
-    (gnus-group-ham-exit-processor-blackbox     ham spam-use-blackbox)
-    (gnus-group-spam-exit-processor-blackbox    spam spam-use-blackbox)
-@end example
+@lisp
+(gnus-group-ham-exit-processor-blackbox  ham spam-use-blackbox)
+(gnus-group-spam-exit-processor-blackbox spam spam-use-blackbox)
+@end lisp
+
 to @code{spam-list-of-processors}.
 
 Add
-@example
-    (spam-use-blackbox  spam-blackbox-register-routine
-                 nil
-                 spam-blackbox-unregister-routine
-                 nil)
-@end example
+@lisp
+(spam-use-blackbox spam-blackbox-register-routine
+                   nil
+                   spam-blackbox-unregister-routine
+                   nil)
+@end lisp
+
 to @code{spam-registration-functions}.  Write the register/unregister
 routines using the bogofilter register/unregister routines as a
 start, or other restister/unregister routines more appropriate to
 Blackbox.
 
 @item
-functionality
+Functionality
 
 Write the @code{spam-check-blackbox} function.  It should return
 @samp{nil} or @code{spam-split-group}, observing the other
@@ -23794,7 +23806,7 @@
 @enumerate
 
 @item
-code
+Code
 
 Note you don't have to provide a spam or a ham processor.  Only
 provide them if Blackbox supports spam or ham processing.
@@ -23819,18 +23831,18 @@
 Gnus parameters
 
 Add
-@example
-                   (const :tag "Spam: Blackbox"   (spam spam-use-blackbox))
-                   (const :tag "Ham: Blackbox"    (ham spam-use-blackbox))
-@end example
+@lisp
+(const :tag "Spam: Blackbox" (spam spam-use-blackbox))
+(const :tag "Ham: Blackbox"  (ham spam-use-blackbox))
+@end lisp
 to the @code{spam-process} group parameter in @code{gnus.el}.  Make
 sure you do it twice, once for the parameter and once for the
 variable customization.
 
 Add
-@example
-          (variable-item spam-use-blackbox)
-@end example
+@lisp
+(variable-item spam-use-blackbox)
+@end lisp
 to the @code{spam-autodetect-methods} group parameter in
 @code{gnus.el}.
 

Re: Sync of Gnus with Emacs

[Reiner Steib]

On Tue, Sep 07 2004, Ted Zlatanov wrote:

> See the attached patch, which is mostly spam.el-related changes to
> gnus.texi, plus a small bug fix in gnus-registry.el and the 'imaps'
> synonym to 'imap' in nnimap.el.
>
> For the docs, I kept changelog entries as they were originally - same
> date, same order (interleaved with others).  For the code, I made a
> new changelog entry.

Thanks.  Could you please install the changes in the v5-10 branch?

The ChangeLog dates should be when the patch is installed in the
respective branch.  Please put them at the beginning of the ChangeLog
file with the current date.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Sync of Gnus with Emacs

[Miles Bader]

Katsumi Yamaoka <yamaoka@jpl.org> writes:
> I switched Gnus to v5-10.  Oh, how old this is!  I flinched.
> Although I never make light of it, I like latest version very
> much even if there may be some bugs. ;-)

Of course for those of us who were still using the old version
previously bundled with Emacs, Gnus 5.10 seems incredibly
advanced... :-)

BTW, I don't read the ding list frequently; is there any rough timeline
for making No Gnus stable?  I'm thinking that perhaps Emacs 22 will be
released relatively quickly after 21.4 (though including the delay until
21.4 gets released, that probably would still be sometime in 2005), and
it might be nice to plan on getting No Gnus into that...

-Miles
-- 
`Suppose Korea goes to the World Cup final against Japan and wins,' Moon said.
`All the past could be forgiven.'   [NYT]

Re: Sync of Gnus with Emacs

[Katsumi Yamaoka]

>>>>> In <873c1rf1x5.fsf@tc-1-100.kawasaki.gol.ne.jp> Miles Bader wrote:

> BTW, I don't read the ding list frequently; is there any rough timeline
> for making No Gnus stable?  I'm thinking that perhaps Emacs 22 will be
> released relatively quickly after 21.4 (though including the delay until
> 21.4 gets released, that probably would still be sometime in 2005), and
> it might be nice to plan on getting No Gnus into that...

Let me say irresponsibly, No Gnus seems stable enough to me. ;-)
It is said that there is no program without bugs, though.
AFAIK, the modules not merged into Emacs yet are compface.el and
rfc2047.el in which I made major changes.  I think I inspected
all angles of them, and now I'm watching for bug reports.

Re: Sync of Gnus with Emacs

[Ted Zlatanov]

On Wed, 08 Sep 2004, 4.uce.03.r.s@nurfuerspam.de wrote:

> Thanks.  Could you please install the changes in the v5-10 branch?

Done.

> The ChangeLog dates should be when the patch is installed in the
> respective branch.  Please put them at the beginning of the ChangeLog
> file with the current date.

Done.  Sorry again for the delay.

I added Simon Josefsson's example of a netrc file because I consider
it a bug in the manual to lack that example, and my 'imaps' patch
needs it.  If you disagree, feel free to remove it.

Ted

Re: Sync of Gnus with Emacs

[Reiner Steib]

On Fri, Sep 10 2004, Ted Zlatanov wrote:

> On Wed, 08 Sep 2004, 4.uce.03.r.s@nurfuerspam.de wrote:
>> Thanks.  Could you please install the changes in the v5-10 branch?
> Done.

Thanks.  (The changes will propagate to Emacs' CVS semi-automatically,
see Miles' posting.)

> Sorry again for the delay.

No need to hurry, yet.  We should only be finished (with backporting
bugfixes from No to v5-10) before Emacs 21.4 will be released or goes
into pretest.  This will still take some time.
 
> I added Simon Josefsson's example of a netrc file because I consider
> it a bug in the manual to lack that example, and my 'imaps' patch
> needs it.

Improvements in the documentation should always be included in the
stable branch (v5-10).

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Sync of Gnus with Emacs

[Kevin Greiner]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:

> - Post a message in this thread that you have checked (and installed)
>   your changes.

I just made a fairly substantial check-in.  It addresses all of the
bugs fixed in the agent and cache since No Gnus was started.

I'm now working on the documentation updates.

Kevin