[Bug, Debian(?)] "g" goes not refresh nnimap groups!

[Bug, Debian(?)] "g" goes not refresh nnimap groups!

[Marcus Frings]

[CC to Manoj, the Debian maintainer of Gnus]

Hello,

I'm suffering from a strange problem (bug?) which shatters my nerves
since about 4 weeks. I sent a report to ding 2 weeks ago but nobody has
answered yet so I have spent the days with extensive testing in the
meantime.

This is the situation:

- My server (Debian woody) at home running Courier IMAP which offers
  IMAP over SSL.
- My client at home running both Debian sid and Win2000 with GNU Emacs +
  Gnus on both OSes.

The problem:

On my Debian client Gnus doesn't refresh nnimap groups in the group
buffer by hitting "g". New mails don't show up. This happens since about
4 weeks. When I use "C-u g" in the group buffer this seems to fix it
(read: Gnus recognizes that new mails are available and updates the
group buffer) /sometimes/ whereas "3g" seems to fix it /always/. I
should also note that I haven't changed my configuration files.

I have done some testing to track down what might cause this
behaviour. Here are my results:

(a) Debian with Debian's (old) official package Gnus 5.10.2: "g" works
    as expected and nnimap groups are updated.
(b) Debian with Debian's (current) official package Gnus 5.10.6: "g"
    fails to update nnimap groups. "3g" works.
(c) Debian with Manoj's nightly Gnus CVS snapshots (as native Debian
    package): "g" fails to update nnimap groups. "3g" works.
(d) Debian with a nightly Gnus snapshot from www.gnus.org (Debian's
    official Gnus package being removed of course): "g" fails to update
    nnimap groups. "3g" works.
(e) Now IMAP over SSL disabled, plain IMAP enabled, repeat (b)-(d): "g"
    fails to update nnimap groups for. "3g" works.
(f) Win2000 (same client as the Debian client and connecting to the same
    Courier IMAP server over SSL): "g" works with all tested versions,
    i.e. 5.10.2, 5.10.6, different nightly snapshots from www.gnus.org.
(g) Win2000 (PC at work, connecting to MS Exchange via IMAP): "g" works
    with all tested versions, i.e. 5.10.2, 5.10.6, different nightly
    snapshots from www.gnus.org.
(h) Debian with Manoj's nightly Gnus CVS snapshots (with minimum
    personal configuration: everything disabled except for [1]): "g"
    fails to update nnimap groups. "3g" works.

I have done all tests with full IMAP debugging (imap-debug, nnimap-debug
and imap-log) but haven't seen anything special in the logs. Maybe I
missed something...

Summary:

- It doesn't seem to be IMAP-specific because of a), e), f) and g).
- It doesn't seem to be caused by my configuration because of a), f), g)
  and h).
- It doesn't seem to be a problem of current Gnus versions in general
  because of f) and g).
- In fact it seems to happen only on Debian and it's not important if a
  Debian package is used or an original tarball from www.gnus.org.
  Strange enough that the old Debian 5.10.2 release seems to be okay
  whereas everything else fails on Debian.

I'm really out of ideas now -- I couldn't find anything special in my
imap debug logs. The last Gnus changelogs also seem to be fine.

I hope someone of you is going to have a flash of genius because I'm
almost giving up.

Regards,
Marcus

PS: I'm using "X-Archive: encrypt" for this report in order to protect
Manoj's address from spam.
______________
[1]
(setq gnus-select-method '(nntp "iridium.home.local"))
(setq gnus-secondary-select-methods
      '((nnimap "192.168.0.1"
		(nnimap-address "192.168.0.1")
		(nnimap-authinfo-file "~/.authinfo")
		(nnimap-stream ssl)
		(nnimap-list-pattern "INBOX.*")
		)))
-- 
"Und selbst für die Verlorenen, denen Leben und Tod nur noch ein Spott ist,
gibt es Dinge, die sie nicht zu ihrem Gespött machen wollen."

Re: [Bug, Debian(?)] "g" goes not refresh nnimap groups!

[Simon Josefsson]

Marcus Frings <iam-est-hora-surgere@despammed.com> writes:

> (a) Debian with Debian's (old) official package Gnus 5.10.2: "g" works
>     as expected and nnimap groups are updated.
> (b) Debian with Debian's (current) official package Gnus 5.10.6: "g"
>     fails to update nnimap groups. "3g" works.
> (c) Debian with Manoj's nightly Gnus CVS snapshots (as native Debian
>     package): "g" fails to update nnimap groups. "3g" works.
> (d) Debian with a nightly Gnus snapshot from www.gnus.org (Debian's
>     official Gnus package being removed of course): "g" fails to update
>     nnimap groups. "3g" works.

With this amount of detail, you should be able to pinpoint the exact
patch that introduce the damage by doing a binary search in CVS.  That
is, check out Gnus 5.10.2 from CVS and then use 'cvs upd -D 2003-x-y'
to move forward a week or so (you need to figure out which date 5.10.2
was release on first, and use that as the starting point) until it
stops working, then track it down to the day it stopped working, and
then hour, and then send a diff of the minimal patch that break
things.

Re: [Bug, Debian(?)] "g" goes not refresh nnimap groups!

[Marcus Frings]

* Simon Josefsson <jas@extundo.com> wrote:

> With this amount of detail, you should be able to pinpoint the exact
> patch that introduce the damage by doing a binary search in CVS. [...]
> and then send a diff of the minimal patch that break things.

Hooray! I have done further tests and I was able to find out when the
problem was introduced. Gnus 5.10.3 is the last working version and
since Gnus 5.10.4 updating nnimap groups fails when I hit "g".
Then I took a closer look at the changelog and realized that Larsi is
the evildoer:

,----[ 2003-12-30  Lars Magne Ingebrigtsen  <larsi@gnus.org> ]
| * gnus-start.el (gnus-get-unread-articles): Inline gnus-server-get-method. 
|   (gnus-get-unread-articles): Cache methods.
|   (gnus-get-unread-articles-in-group): Indent.
| 
| * gnus.el (gnus-version-number): Bump.
|   (gnus-secondary-method-p): Extend servers to methods before comparing. 
|   (gnus-secondary-method-p): Revert.
`----

This is Lars' code which causes the whole problem:

--8<---------------cut here---------------start------------->8---
Index: gnus-group.el
diff -u gnus/lisp/gnus-group.el:6.121 gnus/lisp/gnus-group.el:6.122
--- gnus-group.el:6.121	Sat Nov 29 11:38:58 2003
+++ gnus-group.el	Tue Dec 30 04:58:14 2003
@@ -1464,7 +1464,7 @@
 	 (active (gnus-active group))
 	 (total (if active (1+ (- (cdr active) (car active))) 0))
 	 (info (nth 2 entry))
-	 (method (gnus-server-get-method group (gnus-info-method info)))
+	 (method (inline (gnus-server-get-method group (gnus-info-method info))))
 	 (marked (gnus-info-marks info))
 	 (mailp (apply 'append
 		       (mapcar
Index: gnus-start.el
diff -u gnus/lisp/gnus-start.el:6.86 gnus/lisp/gnus-start.el:6.87
--- gnus-start.el:6.86	Mon Dec 22 15:06:54 2003
+++ gnus-start.el	Tue Dec 30 04:58:14 2003
@@ -1532,7 +1532,7 @@
       ;; If the agent is enabled, we may have to alter the active info.
       (when (and gnus-agent info)
 	(gnus-agent-possibly-alter-active
-		 (gnus-info-group info) active))
+	 (gnus-info-group info) active))
 
       ;; Modify the list of read articles according to what articles
       ;; are available; then tally the unread articles and add the
@@ -1620,7 +1620,10 @@
 		  gnus-activate-foreign-newsgroups)
 		 (t 0))
 	   level))
-	 scanned-methods info group active method retrieve-groups)
+	 (methods-cache nil)
+	 (type-cache nil)
+	 scanned-methods info group active method retrieve-groups cmethod
+	 method-type)
     (gnus-message 6 "Checking new news...")
 
     (while newsrc
@@ -1639,12 +1642,25 @@
       ;; nil for non-foreign groups that the user has requested not be checked
       ;; t for unchecked foreign groups or bogus groups, or groups that can't
       ;;   be checked, for one reason or other.
-      (if (and (setq method (gnus-info-method info))
-	       (not (inline
-		      (gnus-server-equal
-		       gnus-select-method
-		       (setq method (gnus-server-get-method nil method)))))
-	       (not (gnus-secondary-method-p method)))
+      (when (setq method (gnus-info-method info))
+	(if (setq cmethod (assoc method methods-cache))
+	    (setq method (cdr cmethod))
+	  (setq cmethod (inline (gnus-server-get-method nil method)))
+	  (push (cons method cmethod) methods-cache)
+	  (setq method cmethod)))
+      (when (and method
+		 (not (setq method-type (cdr (assoc method type-cache)))))
+	(setq method-type
+	      (cond
+	       ((gnus-secondary-method-p method)
+		'secondary)
+	       ((inline (gnus-server-equal gnus-select-method method))
+		'primary)
+	       (t
+		'foreign)))
+	(push (cons method method-type) type-cache))
+      (if (and method
+	       (eq method-type 'foreign))
 	  ;; These groups are foreign.  Check the level.
 	  (when (and (<= (gnus-info-level info) foreign-level)
 		     (setq active (gnus-activate-group group 'scan)))
Index: gnus.el
diff -u gnus/lisp/gnus.el:6.215 gnus/lisp/gnus.el:6.216
--- gnus.el:6.215	Tue Dec 30 04:19:13 2003
+++ gnus.el	Tue Dec 30 04:58:14 2003
@@ -3490,11 +3490,11 @@
 (defsubst gnus-secondary-method-p (method)
   "Return whether METHOD is a secondary select method."
   (let ((methods gnus-secondary-select-methods)
-	(gmethod (gnus-server-get-method nil method)))
+	(gmethod (inline (gnus-server-get-method nil method))))
     (while (and methods
 		(not (gnus-method-equal
-		      (gnus-server-get-method nil (car methods))
-		      (gnus-server-get-method nil gmethod))))
+		      (inline (gnus-server-get-method nil (car methods)))
+		      gmethod)))
       (setq methods (cdr methods)))
     methods))
--8<---------------cut here---------------end--------------->8---

I have undone all these changes and now "g" works again for nnimap
groups (as you can see I'm using 5.10.4 with the reverted patches for
this mail).
I'm not familiar enough with Lisp to understand what exactly is causing
this problem (the indent patch in gnus-start.el is just a cosmetic fix
of course) but the code above is definitely the malicious one which
leads to all my problems. Besides I don't understand why this only
affects my Gnus on Debian but not Gnus on my Windows system.

Nevertheless I would like to propose to undo these changes and switch
back to the old code.

Regards,
Marcus
-- 
"anger thought so no thought touched inside crazy
(disembodied guttural noise need not make sense)"

Re: [Bug, Debian(?)] "g" goes not refresh nnimap groups!

[Simon Josefsson]

Marcus Frings <iam-est-hora-surgere@despammed.com> writes:

> Besides I don't understand why this only affects my Gnus on Debian
> but not Gnus on my Windows system.

Nor why only you have seen this.  Were you able to reproduce the
problem by building from CVS as well?

I'm not really sure of the purpose of the patch, so I'll let Lars look
at it..

Re: [Bug, Debian(?)] "g" goes not refresh nnimap groups!

[Marcus Frings]

* Simon Josefsson <jas@extundo.com> wrote:
> Marcus Frings <iam-est-hora-surgere@despammed.com> writes:

>> Besides I don't understand why this only affects my Gnus on Debian
>> but not Gnus on my Windows system.

> Nor why only you have seen this.  Were you able to reproduce the
> problem by building from CVS as well?

No, I didn't use CVS as you suggested. Instead I downloaded the release
tarballs from the official Gnus mirror sites. I started with 5.10.2
(worked), took 5.10.3 (worked) then and continued with 5.10.4
(failed). Afterwards I looked at the changes between 5.10.3 and 5.10.4
and saw what could have caused it. Then I have undone Lars' changes for
5.10.4 and was happy to see that "g" works again for nnimap.

Like you I am also curious to know why only I am suffering from this
problem and why it only happens on my Debian system whereas Gnus on
Windows is not affected.

> I'm not really sure of the purpose of the patch, so I'll let Lars look
> at it..

Thanks a lot! I hope Lars is able to explain it.

Regards,
Marcus
-- 
"Ich glaube zwar nicht an Gott - aber ich fürchte mich vor ihm."

Re: [Bug, Debian(?)] "g" goes not refresh nnimap groups!

[Raymond Scholz]

· Marcus Frings <iam-est-hora-surgere-lDxpuoTbsqf2eFz/2MeuCQ@public.gmane.org> wrote:

> Like you I am also curious to know why only I am suffering from this
> problem and why it only happens on my Debian system whereas Gnus on
> Windows is not affected.

Do you remember how the nnimap groups got subscribed? Via the Server
Buffer or via `B' (Browse foreign server).  I remember having had some
glitches with the second opportunity but I'm unable to reproduce this.

Cheers, Ray
-- 
/* Halley */ (Halley's comment.)

Re: [Bug, Debian(?)] "g" goes not refresh nnimap groups!

[Marcus Frings]

* Raymond Scholz <ray-2004@zonix.de> wrote:
> · Marcus Frings <iam-est-hora-surgere@despammed.com> wrote:

>> Like you I am also curious to know why only I am suffering from this
>> problem and why it only happens on my Debian system whereas Gnus on
>> Windows is not affected.

> Do you remember how the nnimap groups got subscribed? Via the Server
> Buffer or via `B' (Browse foreign server).  I remember having had some
> glitches with the second opportunity but I'm unable to reproduce this.

Well, IIRC I subscribed some directly via the server buffer and others
via "A A" (and these groups had been subscribed long before Gnus 5.10.x
was released). And it only affects Debian, no other system! And as I
said I can fix it by removing the changes which Larsi introduced between
5.10.3 and 5.10.4.

Regards,
Marcus
-- 
Spook words for the NSA: President, Military Intelligence, PGP, Defense, SASR,
CDC, DOE, FMS, HPCC, NTIS, SEL, USCODE, CISE, SIRC, CIM, ISN, DJC, SGC, CDA,
M-14, Infowar, Attack, EloAufkl, Chemical, Activist, CRYPT, Lacrosse, Control,
Communications, VX, Assassin, Sniper, Ingram, Industrial, Plutonium, Nuclear

Re: [Bug, Debian(?)] "g" goes not refresh nnimap groups!

[Marcus Frings]

Sorry for producing this full quotation but I talked to Larsi and he
suggested that one of the regular Gnus committers should have a look at
it because he doesn't have time at the moment.

Would anyone please undo Lars' changes or put the patch into Gnus if I
do the work and send the diff? And isn't really anyone using Gnus on
Debian sid with the regular Debian Emacs package? This bug appears since
5.10.4 and it is still in No Gnus. And I'm of the very strong opinion
that my configuration is alright and not responsible for this bug.

This is the code I'm talking about:

* Marcus Frings <iam-est-hora-surgere@despammed.com> wrote:

> Hooray! I have done further tests and I was able to find out when the
> problem was introduced. Gnus 5.10.3 is the last working version and
> since Gnus 5.10.4 updating nnimap groups fails when I hit "g".
> Then I took a closer look at the changelog and realized that Larsi is
> the evildoer:

> ,----[ 2003-12-30  Lars Magne Ingebrigtsen  <larsi@gnus.org> ]
> | * gnus-start.el (gnus-get-unread-articles): Inline gnus-server-get-method. 
> |   (gnus-get-unread-articles): Cache methods.
> |   (gnus-get-unread-articles-in-group): Indent.
> | 
> | * gnus.el (gnus-version-number): Bump.
> |   (gnus-secondary-method-p): Extend servers to methods before comparing. 
> |   (gnus-secondary-method-p): Revert.
> `----

> This is Lars' code which causes the whole problem:

> --8<---------------cut here---------------start------------->8---
> Index: gnus-group.el
> diff -u gnus/lisp/gnus-group.el:6.121 gnus/lisp/gnus-group.el:6.122
> --- gnus-group.el:6.121	Sat Nov 29 11:38:58 2003
> +++ gnus-group.el	Tue Dec 30 04:58:14 2003
> @@ -1464,7 +1464,7 @@
>  	 (active (gnus-active group))
>  	 (total (if active (1+ (- (cdr active) (car active))) 0))
>  	 (info (nth 2 entry))
> -	 (method (gnus-server-get-method group (gnus-info-method info)))
> +	 (method (inline (gnus-server-get-method group (gnus-info-method info))))
>  	 (marked (gnus-info-marks info))
>  	 (mailp (apply 'append
>  		       (mapcar
> Index: gnus-start.el
> diff -u gnus/lisp/gnus-start.el:6.86 gnus/lisp/gnus-start.el:6.87
> --- gnus-start.el:6.86	Mon Dec 22 15:06:54 2003
> +++ gnus-start.el	Tue Dec 30 04:58:14 2003
> @@ -1532,7 +1532,7 @@
>        ;; If the agent is enabled, we may have to alter the active info.
>        (when (and gnus-agent info)
>  	(gnus-agent-possibly-alter-active
> -		 (gnus-info-group info) active))
> +	 (gnus-info-group info) active))

>        ;; Modify the list of read articles according to what articles
>        ;; are available; then tally the unread articles and add the
> @@ -1620,7 +1620,10 @@
>  		  gnus-activate-foreign-newsgroups)
>  		 (t 0))
>  	   level))
> -	 scanned-methods info group active method retrieve-groups)
> +	 (methods-cache nil)
> +	 (type-cache nil)
> +	 scanned-methods info group active method retrieve-groups cmethod
> +	 method-type)
>      (gnus-message 6 "Checking new news...")

>      (while newsrc
> @@ -1639,12 +1642,25 @@
>        ;; nil for non-foreign groups that the user has requested not be checked
>        ;; t for unchecked foreign groups or bogus groups, or groups that can't
>        ;;   be checked, for one reason or other.
> -      (if (and (setq method (gnus-info-method info))
> -	       (not (inline
> -		      (gnus-server-equal
> -		       gnus-select-method
> -		       (setq method (gnus-server-get-method nil method)))))
> -	       (not (gnus-secondary-method-p method)))
> +      (when (setq method (gnus-info-method info))
> +	(if (setq cmethod (assoc method methods-cache))
> +	    (setq method (cdr cmethod))
> +	  (setq cmethod (inline (gnus-server-get-method nil method)))
> +	  (push (cons method cmethod) methods-cache)
> +	  (setq method cmethod)))
> +      (when (and method
> +		 (not (setq method-type (cdr (assoc method type-cache)))))
> +	(setq method-type
> +	      (cond
> +	       ((gnus-secondary-method-p method)
> +		'secondary)
> +	       ((inline (gnus-server-equal gnus-select-method method))
> +		'primary)
> +	       (t
> +		'foreign)))
> +	(push (cons method method-type) type-cache))
> +      (if (and method
> +	       (eq method-type 'foreign))
>  	  ;; These groups are foreign.  Check the level.
>  	  (when (and (<= (gnus-info-level info) foreign-level)
>  		     (setq active (gnus-activate-group group 'scan)))
> Index: gnus.el
> diff -u gnus/lisp/gnus.el:6.215 gnus/lisp/gnus.el:6.216
> --- gnus.el:6.215	Tue Dec 30 04:19:13 2003
> +++ gnus.el	Tue Dec 30 04:58:14 2003
> @@ -3490,11 +3490,11 @@
>  (defsubst gnus-secondary-method-p (method)
>    "Return whether METHOD is a secondary select method."
>    (let ((methods gnus-secondary-select-methods)
> -	(gmethod (gnus-server-get-method nil method)))
> +	(gmethod (inline (gnus-server-get-method nil method))))
>      (while (and methods
>  		(not (gnus-method-equal
> -		      (gnus-server-get-method nil (car methods))
> -		      (gnus-server-get-method nil gmethod))))
> +		      (inline (gnus-server-get-method nil (car methods)))
> +		      gmethod)))
>        (setq methods (cdr methods)))
>      methods))
> --8<---------------cut here---------------end--------------->8---

> I have undone all these changes and now "g" works again for nnimap
> groups (as you can see I'm using 5.10.4 with the reverted patches for
> this mail).
> I'm not familiar enough with Lisp to understand what exactly is causing
> this problem (the indent patch in gnus-start.el is just a cosmetic fix
> of course) but the code above is definitely the malicious one which
> leads to all my problems. Besides I don't understand why this only
> affects my Gnus on Debian but not Gnus on my Windows system.

> Nevertheless I would like to propose to undo these changes and switch
> back to the old code.

Regards,
Marcus
-- 
"Hol mein Geschenk zurück, hol es ab, ich bin Prometheus, nur meine Leber
wächst nicht nach. Zerstörte Zelle. Der Adler muss verhungern. Ich leg heut
nacht den Zellenbrand. Zerstörte Zelle. Der Adler muss verhungern, darf
verhungern, wird verhungern. Das abgemagerte Federvieh stürzt ab."

Re: [Bug, Debian(?)] "g" goes not refresh nnimap groups!

[Simon Josefsson]

Marcus Frings <iam-est-hora-surgere@despammed.com> writes:

> Sorry for producing this full quotation but I talked to Larsi and he
> suggested that one of the regular Gnus committers should have a look at
> it because he doesn't have time at the moment.
>
> Would anyone please undo Lars' changes or put the patch into Gnus if I
> do the work and send the diff?

Does anyone know what the motivation for the patch was?  If we revert
the patch, we might re-introduce an old bug...  Of course, if there is
agreement to revert the patch, I think all committers could do it.

Hm.  To make things easier to evaluate: if someone thinks reverting
this is wrong, please say so.

Re: [Bug, Debian(?)] "g" goes not refresh nnimap groups!

[Marcus Frings]

* Simon Josefsson <jas@extundo.com> wrote:
> Marcus Frings <iam-est-hora-surgere@despammed.com> writes:

> Does anyone know what the motivation for the patch was?  If we revert
> the patch, we might re-introduce an old bug...  Of course, if there is
> agreement to revert the patch, I think all committers could do it.

In my private mail exchange with Lars I asked him what actually the
difference between the old and new code is. I hope Lars doesn't mind
that I'm going to publish his answer here:

,----[ Lars in a private mail ]
| Finding out whether two select methods are "equal" is actually kinda
| tricky in Gnus since I was way too sloppy back when I started doing
| that stuff.  So the functions are complicated, and there a lot that
| might go wrong...
`----

I would also be happy if there is any person who can disprove my opinion
that the new code introduces a bug. Isn't really anyone out there using
Debian Sid with a recent Gnus + standard Debian Emacs package and reads
mail via Courier IMAP?

As mentioned many times before this bug _only_ shows up on Debian Sid
(tested on two different W2k machines) and can be removed by undoing
Lars' changes (I have successfully tested this!). I can hardly believe
that I'm the only one world-wide who discovered this... :-)

Regards,
Marcus
-- 
"Schwer ist es, sich des Zorns zu erwehren, denn
der Mensch erkauft sich Rache mit seiner Seele."
                                      (Heraklit)

Re: [Bug, Debian(?)] "g" goes not refresh nnimap groups!

[Mark Plaksin]

Marcus Frings <iam-est-hora-surgere@despammed.com> writes:

> As mentioned many times before this bug _only_ shows up on Debian Sid
> (tested on two different W2k machines) and can be removed by undoing
> Lars' changes (I have successfully tested this!). I can hardly believe
> that I'm the only one world-wide who discovered this... :-)

As I've mentioned before, me and a friend have the same problem :)  I
*think* I saw the problem in Debian Woody too.

Re: [Bug, Debian(?)] "g" goes not refresh nnimap groups!

[Kevin Greiner]

Mark Plaksin <happy@mcplaksin.org> writes:

> Marcus Frings <iam-est-hora-surgere@despammed.com> writes:
>
>> As mentioned many times before this bug _only_ shows up on Debian Sid
>> (tested on two different W2k machines) and can be removed by undoing
>> Lars' changes (I have successfully tested this!). I can hardly believe
>> that I'm the only one world-wide who discovered this... :-)
>
> As I've mentioned before, me and a friend have the same problem :)  I
> *think* I saw the problem in Debian Woody too.

Well, since it was my code change that prompted Lars to make his, it
is probably appropriate that I try to come up with a fix.  Don't look
for anything quick as I don't want to simply back out Lars change
(it's a performance enhancement for everyone else).

Kevin

Re: [Bug, Debian(?)] "g" goes not refresh nnimap groups!

[Marcus Frings]

* Kevin Greiner <kgreiner@xpediantsolutions.com> wrote:
> Mark Plaksin <happy@mcplaksin.org> writes:

>> Marcus Frings <iam-est-hora-surgere@despammed.com> writes:

>>> As mentioned many times before this bug _only_ shows up on Debian Sid
>>> (tested on two different W2k machines) and can be removed by undoing
>>> Lars' changes (I have successfully tested this!). I can hardly believe
>>> that I'm the only one world-wide who discovered this... :-)

>> As I've mentioned before, me and a friend have the same problem :)  I
>> *think* I saw the problem in Debian Woody too.

> Well, since it was my code change that prompted Lars to make his, it
> is probably appropriate that I try to come up with a fix.  Don't look

By the way, this is also a bug on my FreeBSD system. Both on Debian and
FreeBSD I use GNU Emacs 21.3.1 (and `g' fails on all systems) but on two
different Windoze boxes I use a CVS Emacs (and there `g' works without
any problems). So the new code seems to work for CVS Emacs but fails on
the current stable Emacs. Can this really be Emacs-specific?

> for anything quick as I don't want to simply back out Lars change

Oh. If you hadn't written this today I would have sent the patch to the
list this evening (removing Lars' new code and putting back the old
one). Do you know how long it will take to fix this?

> (it's a performance enhancement for everyone else).

Huh? I haven't seen that there is a performance boost when I press `g'
(even for newsgroups). How can I measure this?

Regards,
Marcus

Re: [Bug, Debian(?)] "g" goes not refresh nnimap groups!

[Mark Plaksin]

Marcus Frings <iam-est-hora-surgere@despammed.com> writes:

> By the way, this is also a bug on my FreeBSD system. Both on Debian and
> FreeBSD I use GNU Emacs 21.3.1 (and `g' fails on all systems) but on two
> different Windoze boxes I use a CVS Emacs (and there `g' works without
> any problems). So the new code seems to work for CVS Emacs but fails on
> the current stable Emacs. Can this really be Emacs-specific?

I have the problem with both CVS Emacs and the wonderful multi-tty
(http://lorentey.web.elte.hu/project/emacs.html) Emacs which is CVS
Emacs plus patches.

PATCH (for testing only): [Bug, Debian(?)] "g" goes not refresh nnimap groups!

[Kevin Greiner]

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

Mark Plaksin <happy@mcplaksin.org> writes:

> Marcus Frings <iam-est-hora-surgere@despammed.com> writes:
>
>> By the way, this is also a bug on my FreeBSD system. Both on Debian and
>> FreeBSD I use GNU Emacs 21.3.1 (and `g' fails on all systems) but on two
>> different Windoze boxes I use a CVS Emacs (and there `g' works without
>> any problems). So the new code seems to work for CVS Emacs but fails on
>> the current stable Emacs. Can this really be Emacs-specific?
>
> I have the problem with both CVS Emacs and the wonderful multi-tty
> (http://lorentey.web.elte.hu/project/emacs.html) Emacs which is CVS
> Emacs plus patches.

This patch should be applied to rev 7.8 (CVS head) of gnus-start.el.
Please let me know what the outcome is.  Finally, if this doesn't
help, please revert to CVS head.

Kevin


[-- Attachment #2: Patch for gnus-start.el --]
[-- Type: text/plain, Size: 2229 bytes --]

--- ../lisp.cvs_ref/gnus-start.el	Tue Mar  9 01:07:19 2004
+++ gnus-start.el	Tue Mar  9 20:16:21 2004
@@ -1636,7 +1636,8 @@
 	   level))
 	 (methods-cache nil)
 	 (type-cache nil)
-	 scanned-methods info group active method retrieve-groups cmethod
+	 scanned-methods info group active method retrieve-groups
+	 cache-entry name-or-method
 	 method-type)
     (gnus-message 6 "Checking new news...")
 
@@ -1656,25 +1657,32 @@
       ;; nil for non-foreign groups that the user has requested not be checked
       ;; t for unchecked foreign groups or bogus groups, or groups that can't
       ;;   be checked, for one reason or other.
-      (when (setq method (gnus-info-method info))
-	(if (setq cmethod (assoc method methods-cache))
-	    (setq method (cdr cmethod))
-	  (setq cmethod (inline (gnus-server-get-method nil method)))
-	  (push (cons method cmethod) methods-cache)
-	  (setq method cmethod)))
-      (when (and method
-		 (not (setq method-type (cdr (assoc method type-cache)))))
-	(setq method-type
-	      (cond
-	       ((gnus-secondary-method-p method)
-		'secondary)
-	       ((inline (gnus-server-equal gnus-select-method method))
-		'primary)
-	       (t
-		'foreign)))
-	(push (cons method method-type) type-cache))
-      (if (and method
-	       (eq method-type 'foreign))
+      (setq name-or-method (gnus-info-method info))
+      (setq method 
+	    (cdr
+	     (if (setq cache-entry (assoc name-or-method methods-cache))
+		 cache-entry
+	       (setq cache-entry (if name-or-method
+				      (gnus-server-get-method nil name-or-method)
+				   gnus-select-method))
+	       (car (push (cons name-or-method cache-entry)
+			  methods-cache)))))
+	    
+      (setq method-type
+	    (cdr (or (assoc method type-cache)
+		     (car (push 
+			   (cons method 
+				 (cond ((not method)
+					'unknown)
+				       ((gnus-secondary-method-p method)
+					'secondary)
+				       ((gnus-server-equal gnus-select-method method)
+					'primary)
+				       (t
+					'foreign)))
+			   type-cache)))))
+
+      (if (eq method-type 'foreign)
 	  ;; These groups are foreign.  Check the level.
 	  (when (and (<= (gnus-info-level info) foreign-level)
 		     (setq active (gnus-activate-group group 'scan)))

Re: PATCH (for testing only): [Bug, Debian(?)] "g" goes not refresh

[Mark Plaksin]

Kevin Greiner <kgreiner@xpediantsolutions.com> writes:

> Mark Plaksin <happy@mcplaksin.org> writes:
>
>> Marcus Frings <iam-est-hora-surgere@despammed.com> writes:
>>
>>> By the way, this is also a bug on my FreeBSD system. Both on Debian and
>>> FreeBSD I use GNU Emacs 21.3.1 (and `g' fails on all systems) but on two
>>> different Windoze boxes I use a CVS Emacs (and there `g' works without
>>> any problems). So the new code seems to work for CVS Emacs but fails on
>>> the current stable Emacs. Can this really be Emacs-specific?
>>
>> I have the problem with both CVS Emacs and the wonderful multi-tty
>> (http://lorentey.web.elte.hu/project/emacs.html) Emacs which is CVS
>> Emacs plus patches.
>
> This patch should be applied to rev 7.8 (CVS head) of gnus-start.el.
> Please let me know what the outcome is.  Finally, if this doesn't
> help, please revert to CVS head.

Thanks for the patch!

It doesn't change the behavior for me.  Testing this I was also
reminded that the problem affects my nnvirtual groups too.

After patching, I exited Emacs, started up again, started Gnus (which
automatically checks groups at level 1), and then did 5 G.  Gnus
checked all groups at level 4 and below but no groups at level 5.  I
have both nnimap and nnvirtual groups at level 5.  As before, going to
the top topic and hitting ESC g (i.e., ESC < ESC g) checks all groups at
all levels.

Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not

[Kevin Greiner]

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

Mark Plaksin <happy@mcplaksin.org> writes:

> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>
>> Mark Plaksin <happy@mcplaksin.org> writes:
>>
>>> Marcus Frings <iam-est-hora-surgere@despammed.com> writes:
>>>
>>>> By the way, this is also a bug on my FreeBSD system. Both on Debian and
>>>> FreeBSD I use GNU Emacs 21.3.1 (and `g' fails on all systems) but on two
>>>> different Windoze boxes I use a CVS Emacs (and there `g' works without
>>>> any problems). So the new code seems to work for CVS Emacs but fails on
>>>> the current stable Emacs. Can this really be Emacs-specific?
>>>
>>> I have the problem with both CVS Emacs and the wonderful multi-tty
>>> (http://lorentey.web.elte.hu/project/emacs.html) Emacs which is CVS
>>> Emacs plus patches.
>>
>> This patch should be applied to rev 7.8 (CVS head) of gnus-start.el.
>> Please let me know what the outcome is.  Finally, if this doesn't
>> help, please revert to CVS head.
>
> Thanks for the patch!
>
> It doesn't change the behavior for me.  Testing this I was also
> reminded that the problem affects my nnvirtual groups too.
>
> After patching, I exited Emacs, started up again, started Gnus (which
> automatically checks groups at level 1), and then did 5 G.  Gnus
> checked all groups at level 4 and below but no groups at level 5.  I
> have both nnimap and nnvirtual groups at level 5.  As before, going to
> the top topic and hitting ESC g (i.e., ESC < ESC g) checks all groups at
> all levels.

Well, I tried being a little smarter and did learn one fact.  The code
that Lars patched in gnus-start and that I re-patched in my previous
patch is never used when you do ESC < ESC g as you described.

That would appear to indicate that your problems are being caused by
the rather innocuous addition of two inline declarations in gnus.el.
If so, the problem is more of an emacs bug that gnus, which would help
explain why it is only seen on certain platforms.

All right, enough talk.  Here's the patch for gnus.el.  As before,
apply it to the current revision of gnus.el.  What is different is
that you MUST delete all *.elc files before compiling gnus.  The
reason is that gnus-secondary-method-p is an inline function (a
defsubst) which, like a macro, is expanded at compilation time.

Kevin


[-- Attachment #2: Test patch for gnus.el --]
[-- Type: text/plain, Size: 608 bytes --]

--- ../lisp.cvs_ref/gnus.el	Sat Mar  6 00:05:56 2004
+++ gnus.el	Wed Mar 10 12:40:31 2004
@@ -3506,10 +3506,10 @@
 (defsubst gnus-secondary-method-p (method)
   "Return whether METHOD is a secondary select method."
   (let ((methods gnus-secondary-select-methods)
-	(gmethod (inline (gnus-server-get-method nil method))))
+	(gmethod (gnus-server-get-method nil method)))
     (while (and methods
 		(not (gnus-method-equal
-		      (inline (gnus-server-get-method nil (car methods)))
+		      (gnus-server-get-method nil (car methods))
 		      gmethod)))
       (setq methods (cdr methods)))
     methods))

Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not

[Mark Plaksin]

Kevin Greiner <kgreiner@xpediantsolutions.com> writes:

> Mark Plaksin <happy@mcplaksin.org> writes:
>
>> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>>
>>> Mark Plaksin <happy@mcplaksin.org> writes:
>>>
>>>> Marcus Frings <iam-est-hora-surgere@despammed.com> writes:
>>>>
>>>>> By the way, this is also a bug on my FreeBSD system. Both on Debian and
>>>>> FreeBSD I use GNU Emacs 21.3.1 (and `g' fails on all systems) but on two
>>>>> different Windoze boxes I use a CVS Emacs (and there `g' works without
>>>>> any problems). So the new code seems to work for CVS Emacs but fails on
>>>>> the current stable Emacs. Can this really be Emacs-specific?
>>>>
>>>> I have the problem with both CVS Emacs and the wonderful multi-tty
>>>> (http://lorentey.web.elte.hu/project/emacs.html) Emacs which is CVS
>>>> Emacs plus patches.
>>>
>>> This patch should be applied to rev 7.8 (CVS head) of gnus-start.el.
>>> Please let me know what the outcome is.  Finally, if this doesn't
>>> help, please revert to CVS head.
>>
>> Thanks for the patch!
>>
>> It doesn't change the behavior for me.  Testing this I was also
>> reminded that the problem affects my nnvirtual groups too.
>>
>> After patching, I exited Emacs, started up again, started Gnus (which
>> automatically checks groups at level 1), and then did 5 G.  Gnus
>> checked all groups at level 4 and below but no groups at level 5.  I
>> have both nnimap and nnvirtual groups at level 5.  As before, going to
>> the top topic and hitting ESC g (i.e., ESC < ESC g) checks all groups at
>> all levels.
>
> Well, I tried being a little smarter and did learn one fact.  The code
> that Lars patched in gnus-start and that I re-patched in my previous
> patch is never used when you do ESC < ESC g as you described.
>
> That would appear to indicate that your problems are being caused by
> the rather innocuous addition of two inline declarations in gnus.el.
> If so, the problem is more of an emacs bug that gnus, which would help
> explain why it is only seen on certain platforms.
>
> All right, enough talk.  Here's the patch for gnus.el.  As before,
> apply it to the current revision of gnus.el.  What is different is
> that you MUST delete all *.elc files before compiling gnus.  The
> reason is that gnus-secondary-method-p is an inline function (a
> defsubst) which, like a macro, is expanded at compilation time.

Same results with this patch.  Can I provide more information or help
in some other way?

Re: PATCH (for testing only): [Bug, Debian(?)] "g" goes not refresh

[Marcus Frings]

* Kevin Greiner <kgreiner@xpediantsolutions.com> wrote:

> This patch should be applied to rev 7.8 (CVS head) of gnus-start.el.
> Please let me know what the outcome is.  Finally, if this doesn't
> help, please revert to CVS head.

I have also tried your patch. Like Mark said: It doesn't show any
changes. I'm going to try your second patch as well now.

Regards,
Marcus
-- 
"Ich weiß einfach alles über sie... Wir könnten sie alle umbringen. Na,
was denkst du?" - "Ach, weißt du, warum nicht..." 

Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not

[Marcus Frings]

* Kevin Greiner <kgreiner@xpediantsolutions.com> wrote:

> That would appear to indicate that your problems are being caused by
> the rather innocuous addition of two inline declarations in gnus.el.
> If so, the problem is more of an emacs bug that gnus, which would help
> explain why it is only seen on certain platforms.

Yes, it doesn't cause any problems with the CVS Emacs for Windows
(downloaded from <http://www.crasseux.com/>). Only my lovely Linux and
FreeBSD systems fail.

> All right, enough talk.  Here's the patch for gnus.el.  As before,
> apply it to the current revision of gnus.el.  What is different is
> that you MUST delete all *.elc files before compiling gnus.  The
> reason is that gnus-secondary-method-p is an inline function (a
> defsubst) which, like a macro, is expanded at compilation time.

Unfortunately I have to say that the second patch doesn't work
either. :-( 

Do you have any other idea?

Regards,
Marcus
-- 
"Do we take prisoners?" - "No. Kill all they send... And they will stop coming!"

Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not

[Kevin Greiner]

Mark Plaksin <happy@mcplaksin.org> writes:

> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>
>> Mark Plaksin <happy@mcplaksin.org> writes:
>>
>>> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>>>
>>>> Mark Plaksin <happy@mcplaksin.org> writes:
>>>>
>>>>> Marcus Frings <iam-est-hora-surgere@despammed.com> writes:
>>>>>
>>>>>> By the way, this is also a bug on my FreeBSD system. Both on Debian and
>>>>>> FreeBSD I use GNU Emacs 21.3.1 (and `g' fails on all systems) but on two
>>>>>> different Windoze boxes I use a CVS Emacs (and there `g' works without
>>>>>> any problems). So the new code seems to work for CVS Emacs but fails on
>>>>>> the current stable Emacs. Can this really be Emacs-specific?
>>>>>
>>>>> I have the problem with both CVS Emacs and the wonderful multi-tty
>>>>> (http://lorentey.web.elte.hu/project/emacs.html) Emacs which is CVS
>>>>> Emacs plus patches.
>>>>
>>>> This patch should be applied to rev 7.8 (CVS head) of gnus-start.el.
>>>> Please let me know what the outcome is.  Finally, if this doesn't
>>>> help, please revert to CVS head.
>>>
>>> Thanks for the patch!
>>>
>>> It doesn't change the behavior for me.  Testing this I was also
>>> reminded that the problem affects my nnvirtual groups too.
>>>
>>> After patching, I exited Emacs, started up again, started Gnus (which
>>> automatically checks groups at level 1), and then did 5 G.  Gnus
>>> checked all groups at level 4 and below but no groups at level 5.  I
>>> have both nnimap and nnvirtual groups at level 5.  As before, going to
>>> the top topic and hitting ESC g (i.e., ESC < ESC g) checks all groups at
>>> all levels.
>>
>> Well, I tried being a little smarter and did learn one fact.  The code
>> that Lars patched in gnus-start and that I re-patched in my previous
>> patch is never used when you do ESC < ESC g as you described.
>>
>> That would appear to indicate that your problems are being caused by
>> the rather innocuous addition of two inline declarations in gnus.el.
>> If so, the problem is more of an emacs bug that gnus, which would help
>> explain why it is only seen on certain platforms.
>>
>> All right, enough talk.  Here's the patch for gnus.el.  As before,
>> apply it to the current revision of gnus.el.  What is different is
>> that you MUST delete all *.elc files before compiling gnus.  The
>> reason is that gnus-secondary-method-p is an inline function (a
>> defsubst) which, like a macro, is expanded at compilation time.
>
> Same results with this patch.  Can I provide more information or help
> in some other way?

Definitely.  I'll admit that right now, I'm skeptical that unpatching
Lars code change actually fixes this problem.

So, let's go back to the beginning.  The problem as I understand is
that your nnimap, nnvirtual, perhaps other, groups are not fetching
new articles.  As an example, the command 'ESC < ESC g' was provided.

ESC < is move point OK
ESC g gnus-topic-get-new-news-this-topic

gnus-topic-get-new-news-this-topic is a fairly simple function that
selects a set of groups then calls gnus-group-get-new-news-this-group.
Hmmm.  That's identical to turning off the topic mode, marking several
groups with '#', then pressing 'ESC g'.  Does this work for you or is
it also broken?  (This will determine whether the problem is in selecting
or processing the groups).

Assuming that it is still broken...

gnus-group-get-new-news-this-group loops over each group
calling... gnus-activate-group then, if it returned non-nil,
gnus-get-unread-articles-in-group appears to be the workhorse.

This is interesting... gnus-get-unread-articles-in-group does NOTHING
if (gnus-active group) returns nil.

So, here's the next test.  In your group buffer, type

M-: (gnus-activate-group "GROUP")<RET> {where GROUP is the group name
                        as shown in the group buffer.  Obviously pick
                        a group that is not updating.}

What does this function return in the minibuffer?  If it is nil, your
group isn't activating.

If it returned a cons, something like (2 . 1000), activation was
successful.

If the group activated, try this:

M-: (gnus-active "GROUP")<RET> {where GROUP is the same group as before}

Did you get the same cons or nil?

OK, last chance with the easy stuff.  Set both gnus-use-cache and
gnus-agent to nil.  Fetch new news again.  Does this fix the problem?

If you haven't seen any nil values by now, you're probably best off
debugging the gnus-get-unread-articles-in-group function.  Don't
bother stepping into the backend functions until certain that it will
be necessary.  That is, step over the gnus-request-update-info and
gnus-activate-group calls, until you have verified that
gnus-get-unread-articles-in-group does the right thing with the given
active range and list of read articles.

Kevin

Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not

[Marcus Frings]

* Kevin Greiner <kgreiner@xpediantsolutions.com> wrote:

>> Same results with this patch.  Can I provide more information or help
>> in some other way?

Well, I'm not Mark but I dare to answer. :-)

> Definitely.  I'll admit that right now, I'm skeptical that unpatching
> Lars code change actually fixes this problem.

I promise you: It does! I used 5.10.4 (where it was introduced) with the
new code: Not working! Then I unpatched 5.10.4 back to the old code:
It's working!

> So, here's the next test.  In your group buffer, type

> M-: (gnus-activate-group "GROUP")<RET> {where GROUP is the group name
>                         as shown in the group buffer.  Obviously pick
>                         a group that is not updating.}

M-: (gnus-activate-group "INBOX")<RET>

> What does this function return in the minibuffer?  If it is nil, your
> group isn't activating.

It returns `nil'.

> If it returned a cons, something like (2 . 1000), activation was
> successful.

> If the group activated, try this:

Nope.

> M-: (gnus-active "GROUP")<RET> {where GROUP is the same group as before}

> Did you get the same cons or nil?

> OK, last chance with the easy stuff.  Set both gnus-use-cache and
> gnus-agent to nil.  Fetch new news again.  Does this fix the problem?

Both are activated. In my running session I have set both of them to
`nil' via "customize for current session". I checked the values and they
are `nil' now. Then I tried pressing "g": Not updating.
Then I hit "1 g": It works.

Actually this is how I work with IMAP since the bug was introduced:
Always hitting "1 g", "2 g" and "3 g" for my IMAP groups (which are on
different levels) since "g" doesn't update any of them.

Regards,
Marcus
-- 
"Two, Five, Zero, Zero, Zero
Jihad"

Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not

[Kevin Greiner]

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

Marcus Frings <iam-est-hora-surgere@despammed.com> writes:

> * Kevin Greiner <kgreiner@xpediantsolutions.com> wrote:
>
>>> Same results with this patch.  Can I provide more information or help
>>> in some other way?
>
> Well, I'm not Mark but I dare to answer. :-)

Pls do.  I more feedback the sooner this can be put behind us.

>> Definitely.  I'll admit that right now, I'm skeptical that unpatching
>> Lars code change actually fixes this problem.
>
> I promise you: It does! I used 5.10.4 (where it was introduced) with the
> new code: Not working! Then I unpatched 5.10.4 back to the old code:
> It's working!

Alright, let's try one last test concerning Lars patch.  Apply this
patch to the clean (CVS head) revision of gnus-start.el.


[-- Attachment #2: gnus-start.patch2.txt --]
[-- Type: text/plain, Size: 360 bytes --]

--- ../lisp.cvs_ref/gnus-start.el	Tue Mar  9 01:07:19 2004
+++ gnus-start.el	Thu Mar 11 18:41:40 2004
@@ -1673,6 +1673,7 @@
 	       (t
 		'foreign)))
 	(push (cons method method-type) type-cache))
+      (message "Group %s is %s" group method-type)
       (if (and method
 	       (eq method-type 'foreign))
 	  ;; These groups are foreign.  Check the level.

[-- Attachment #3: Type: text/plain, Size: 910 bytes --]


Trigger the bug then look in the *messages* buffer.  Search for one of
the groups that did not update.  Did gnus correctly classify the
group?  What type is this group (i.e. primary, secondary, foreign)?
What type did gnus report?

>> So, here's the next test.  In your group buffer, type
>
>> M-: (gnus-activate-group "GROUP")<RET> {where GROUP is the group name
>>                         as shown in the group buffer.  Obviously pick
>>                         a group that is not updating.}
>
> M-: (gnus-activate-group "INBOX")<RET>
>
>> What does this function return in the minibuffer?  If it is nil, your
>> group isn't activating.
>
> It returns `nil'.

OK, so the actual problem is somewhere inside of
gnus-activate-group (We'll come back to this with the next message).

Here's an interesting test.

Try this
M-x load-library gnus
M-x load-library gnus-start.el
M-x gnus

Has the error gone away?

Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not

[Mark Plaksin]

Kevin Greiner <kgreiner@xpediantsolutions.com> writes:

> Mark Plaksin <happy@mcplaksin.org> writes:
>
>> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>>
>>> Mark Plaksin <happy@mcplaksin.org> writes:
>>>
>>>> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>>>>
>>>>> Mark Plaksin <happy@mcplaksin.org> writes:
>>>>>
>>>>>> Marcus Frings <iam-est-hora-surgere@despammed.com> writes:
>>>>>>
>>>>>>> By the way, this is also a bug on my FreeBSD system. Both on Debian and
>>>>>>> FreeBSD I use GNU Emacs 21.3.1 (and `g' fails on all systems) but on two
>>>>>>> different Windoze boxes I use a CVS Emacs (and there `g' works without
>>>>>>> any problems). So the new code seems to work for CVS Emacs but fails on
>>>>>>> the current stable Emacs. Can this really be Emacs-specific?
>>>>>>
>>>>>> I have the problem with both CVS Emacs and the wonderful multi-tty
>>>>>> (http://lorentey.web.elte.hu/project/emacs.html) Emacs which is CVS
>>>>>> Emacs plus patches.
>>>>>
>>>>> This patch should be applied to rev 7.8 (CVS head) of gnus-start.el.
>>>>> Please let me know what the outcome is.  Finally, if this doesn't
>>>>> help, please revert to CVS head.
>>>>
>>>> Thanks for the patch!
>>>>
>>>> It doesn't change the behavior for me.  Testing this I was also
>>>> reminded that the problem affects my nnvirtual groups too.
>>>>
>>>> After patching, I exited Emacs, started up again, started Gnus (which
>>>> automatically checks groups at level 1), and then did 5 G.  Gnus
>>>> checked all groups at level 4 and below but no groups at level 5.  I
>>>> have both nnimap and nnvirtual groups at level 5.  As before, going to
>>>> the top topic and hitting ESC g (i.e., ESC < ESC g) checks all groups at
>>>> all levels.
>>>
>>> Well, I tried being a little smarter and did learn one fact.  The code
>>> that Lars patched in gnus-start and that I re-patched in my previous
>>> patch is never used when you do ESC < ESC g as you described.
>>>
>>> That would appear to indicate that your problems are being caused by
>>> the rather innocuous addition of two inline declarations in gnus.el.
>>> If so, the problem is more of an emacs bug that gnus, which would help
>>> explain why it is only seen on certain platforms.
>>>
>>> All right, enough talk.  Here's the patch for gnus.el.  As before,
>>> apply it to the current revision of gnus.el.  What is different is
>>> that you MUST delete all *.elc files before compiling gnus.  The
>>> reason is that gnus-secondary-method-p is an inline function (a
>>> defsubst) which, like a macro, is expanded at compilation time.
>>
>> Same results with this patch.  Can I provide more information or help
>> in some other way?
>
> Definitely.  I'll admit that right now, I'm skeptical that unpatching
> Lars code change actually fixes this problem.
>
> So, let's go back to the beginning.  The problem as I understand is
> that your nnimap, nnvirtual, perhaps other, groups are not fetching
> new articles.  As an example, the command 'ESC < ESC g' was provided.
>
> ESC < is move point OK
> ESC g gnus-topic-get-new-news-this-topic
>
> gnus-topic-get-new-news-this-topic is a fairly simple function that
> selects a set of groups then calls gnus-group-get-new-news-this-group.
> Hmmm.  That's identical to turning off the topic mode, marking several
> groups with '#', then pressing 'ESC g'.  Does this work for you or is
> it also broken?  (This will determine whether the problem is in selecting
> or processing the groups).

This *works*.

Your other suggestions got me looking at the code and I found that
changing gnus-activate-foreign-newsgroups from the default of 4 to 5
solves the problem for me.  The documentation for this variable makes it
sound like it's only relevant at startup but maybe I misunderstand it:

  *If nil, Gnus will not check foreign newsgroups at startup.
  If it is non-nil, it should be a number between one and nine.  Foreign
  newsgroups that have a level lower or equal to this number will be
  activated on startup.  For instance, if you want to active all
  subscribed newsgroups, but not the rest, you'd set this variable to
  `gnus-level-subscribed'.
  
  If you subscribe to lots of newsgroups from different servers, startup
  might take a while.  By setting this variable to nil, you'll save time,
  but you won't be told how many unread articles there are in the
  groups.

Before making the change mentioned above, these two parts of
gnus-get-unread-articles seem to be what causes Gnus not to check all of
the groups:

	 (foreign-level
	  (min
	   (cond ((and gnus-activate-foreign-newsgroups
		       (not (numberp gnus-activate-foreign-newsgroups)))
		  (1+ gnus-level-subscribed))
		 ((numberp gnus-activate-foreign-newsgroups)
		  gnus-activate-foreign-newsgroups)
		 (t 0))
	   level))

For me foreign-level ended up set to 4.  Then this part of the code
ends up checking whether 5 <= 4 and it's not so the group gets skipped.

	  (when (and (<= (gnus-info-level info) foreign-level)
		     (setq active (gnus-activate-group group 'scan)))

I'm not sure what all of that means :)

Marcus: Does setting gnus-activate-foreign-newsgroups to 5 solve the
problem for you?

Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not

[Mark Plaksin]

Kevin Greiner <kgreiner@xpediantsolutions.com> writes:

> Mark Plaksin <happy@mcplaksin.org> writes:
>
>> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>>
>>> Mark Plaksin <happy@mcplaksin.org> writes:
>>>
>>>> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>>>>
>>>>> Mark Plaksin <happy@mcplaksin.org> writes:
>>>>>
>>>>>> Marcus Frings <iam-est-hora-surgere@despammed.com> writes:
>>>>>>
>>>>>>> By the way, this is also a bug on my FreeBSD system. Both on Debian and
>>>>>>> FreeBSD I use GNU Emacs 21.3.1 (and `g' fails on all systems) but on two
>>>>>>> different Windoze boxes I use a CVS Emacs (and there `g' works without
>>>>>>> any problems). So the new code seems to work for CVS Emacs but fails on
>>>>>>> the current stable Emacs. Can this really be Emacs-specific?
>>>>>>
>>>>>> I have the problem with both CVS Emacs and the wonderful multi-tty
>>>>>> (http://lorentey.web.elte.hu/project/emacs.html) Emacs which is CVS
>>>>>> Emacs plus patches.
>>>>>
>>>>> This patch should be applied to rev 7.8 (CVS head) of gnus-start.el.
>>>>> Please let me know what the outcome is.  Finally, if this doesn't
>>>>> help, please revert to CVS head.
>>>>
>>>> Thanks for the patch!
>>>>
>>>> It doesn't change the behavior for me.  Testing this I was also
>>>> reminded that the problem affects my nnvirtual groups too.
>>>>
>>>> After patching, I exited Emacs, started up again, started Gnus (which
>>>> automatically checks groups at level 1), and then did 5 G.  Gnus
>>>> checked all groups at level 4 and below but no groups at level 5.  I
>>>> have both nnimap and nnvirtual groups at level 5.  As before, going to
>>>> the top topic and hitting ESC g (i.e., ESC < ESC g) checks all groups at
>>>> all levels.
>>>
>>> Well, I tried being a little smarter and did learn one fact.  The code
>>> that Lars patched in gnus-start and that I re-patched in my previous
>>> patch is never used when you do ESC < ESC g as you described.
>>>
>>> That would appear to indicate that your problems are being caused by
>>> the rather innocuous addition of two inline declarations in gnus.el.
>>> If so, the problem is more of an emacs bug that gnus, which would help
>>> explain why it is only seen on certain platforms.
>>>
>>> All right, enough talk.  Here's the patch for gnus.el.  As before,
>>> apply it to the current revision of gnus.el.  What is different is
>>> that you MUST delete all *.elc files before compiling gnus.  The
>>> reason is that gnus-secondary-method-p is an inline function (a
>>> defsubst) which, like a macro, is expanded at compilation time.
>>
>> Same results with this patch.  Can I provide more information or help
>> in some other way?
>
> Definitely.  I'll admit that right now, I'm skeptical that unpatching
> Lars code change actually fixes this problem.
>
> So, let's go back to the beginning.  The problem as I understand is
> that your nnimap, nnvirtual, perhaps other, groups are not fetching
> new articles.  As an example, the command 'ESC < ESC g' was provided.
>
> ESC < is move point OK
> ESC g gnus-topic-get-new-news-this-topic
>
> gnus-topic-get-new-news-this-topic is a fairly simple function that
> selects a set of groups then calls gnus-group-get-new-news-this-group.
> Hmmm.  That's identical to turning off the topic mode, marking several
> groups with '#', then pressing 'ESC g'.  Does this work for you or is
> it also broken?  (This will determine whether the problem is in selecting
> or processing the groups).

[ I posted this earlier from another address but even after confirming
and waiting the "10 minutes", Gmane hasn't posted it so I'm trying
again.]

This *works*.

Your other suggestions got me looking at the code and I found that
changing gnus-activate-foreign-newsgroups from the default of 4 to 5
solves the problem for me.  The documentation for this variable makes it
sound like it's only relevant at startup but maybe I misunderstand it:

  *If nil, Gnus will not check foreign newsgroups at startup.
  If it is non-nil, it should be a number between one and nine.  Foreign
  newsgroups that have a level lower or equal to this number will be
  activated on startup.  For instance, if you want to active all
  subscribed newsgroups, but not the rest, you'd set this variable to
  `gnus-level-subscribed'.
  
  If you subscribe to lots of newsgroups from different servers, startup
  might take a while.  By setting this variable to nil, you'll save time,
  but you won't be told how many unread articles there are in the
  groups.

Before making the change mentioned above, these two parts of
gnus-get-unread-articles seem to be what causes Gnus not to check all of
the groups:

	 (foreign-level
	  (min
	   (cond ((and gnus-activate-foreign-newsgroups
		       (not (numberp gnus-activate-foreign-newsgroups)))
		  (1+ gnus-level-subscribed))
		 ((numberp gnus-activate-foreign-newsgroups)
		  gnus-activate-foreign-newsgroups)
		 (t 0))
	   level))

For me foreign-level ended up set to 4.  Then this part of the code
ends up checking whether 5 <= 4 and it's not so the group gets skipped.

	  (when (and (<= (gnus-info-level info) foreign-level)
		     (setq active (gnus-activate-group group 'scan)))

I'm not sure what all of that means :)

Marcus: Does setting gnus-activate-foreign-newsgroups to 5 solve the
problem for you?

Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not

[Kevin Greiner]

Mark Plaksin <happy@mcplaksin.org> writes:

> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>
>> Mark Plaksin <happy@mcplaksin.org> writes:
>>
>>> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>>>
>>>> Mark Plaksin <happy@mcplaksin.org> writes:
>>>>
>>>>> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>>>>>
>>>>>> Mark Plaksin <happy@mcplaksin.org> writes:
>>>>>>
>>>>>>> Marcus Frings <iam-est-hora-surgere@despammed.com> writes:
>>>>>>>
>>>>>>>> By the way, this is also a bug on my FreeBSD system. Both on Debian and
>>>>>>>> FreeBSD I use GNU Emacs 21.3.1 (and `g' fails on all systems) but on two
>>>>>>>> different Windoze boxes I use a CVS Emacs (and there `g' works without
>>>>>>>> any problems). So the new code seems to work for CVS Emacs but fails on
>>>>>>>> the current stable Emacs. Can this really be Emacs-specific?
>>>>>>>
>>>>>>> I have the problem with both CVS Emacs and the wonderful multi-tty
>>>>>>> (http://lorentey.web.elte.hu/project/emacs.html) Emacs which is CVS
>>>>>>> Emacs plus patches.
>>>>>>
>>>>>> This patch should be applied to rev 7.8 (CVS head) of gnus-start.el.
>>>>>> Please let me know what the outcome is.  Finally, if this doesn't
>>>>>> help, please revert to CVS head.
>>>>>
>>>>> Thanks for the patch!
>>>>>
>>>>> It doesn't change the behavior for me.  Testing this I was also
>>>>> reminded that the problem affects my nnvirtual groups too.
>>>>>
>>>>> After patching, I exited Emacs, started up again, started Gnus (which
>>>>> automatically checks groups at level 1), and then did 5 G.  Gnus
>>>>> checked all groups at level 4 and below but no groups at level 5.  I
>>>>> have both nnimap and nnvirtual groups at level 5.  As before, going to
>>>>> the top topic and hitting ESC g (i.e., ESC < ESC g) checks all groups at
>>>>> all levels.
>>>>
>>>> Well, I tried being a little smarter and did learn one fact.  The code
>>>> that Lars patched in gnus-start and that I re-patched in my previous
>>>> patch is never used when you do ESC < ESC g as you described.
>>>>
>>>> That would appear to indicate that your problems are being caused by
>>>> the rather innocuous addition of two inline declarations in gnus.el.
>>>> If so, the problem is more of an emacs bug that gnus, which would help
>>>> explain why it is only seen on certain platforms.
>>>>
>>>> All right, enough talk.  Here's the patch for gnus.el.  As before,
>>>> apply it to the current revision of gnus.el.  What is different is
>>>> that you MUST delete all *.elc files before compiling gnus.  The
>>>> reason is that gnus-secondary-method-p is an inline function (a
>>>> defsubst) which, like a macro, is expanded at compilation time.
>>>
>>> Same results with this patch.  Can I provide more information or help
>>> in some other way?
>>
>> Definitely.  I'll admit that right now, I'm skeptical that unpatching
>> Lars code change actually fixes this problem.
>>
>> So, let's go back to the beginning.  The problem as I understand is
>> that your nnimap, nnvirtual, perhaps other, groups are not fetching
>> new articles.  As an example, the command 'ESC < ESC g' was provided.
>>
>> ESC < is move point OK
>> ESC g gnus-topic-get-new-news-this-topic
>>
>> gnus-topic-get-new-news-this-topic is a fairly simple function that
>> selects a set of groups then calls gnus-group-get-new-news-this-group.
>> Hmmm.  That's identical to turning off the topic mode, marking several
>> groups with '#', then pressing 'ESC g'.  Does this work for you or is
>> it also broken?  (This will determine whether the problem is in selecting
>> or processing the groups).
>
> [ I posted this earlier from another address but even after confirming
> and waiting the "10 minutes", Gmane hasn't posted it so I'm trying
> again.]
>
> This *works*.
>
> Your other suggestions got me looking at the code and I found that
> changing gnus-activate-foreign-newsgroups from the default of 4 to 5
> solves the problem for me.  The documentation for this variable makes it
> sound like it's only relevant at startup but maybe I misunderstand it:
>
>   *If nil, Gnus will not check foreign newsgroups at startup.
>   If it is non-nil, it should be a number between one and nine.  Foreign
>   newsgroups that have a level lower or equal to this number will be
>   activated on startup.  For instance, if you want to active all
>   subscribed newsgroups, but not the rest, you'd set this variable to
>   `gnus-level-subscribed'.
>   
>   If you subscribe to lots of newsgroups from different servers, startup
>   might take a while.  By setting this variable to nil, you'll save time,
>   but you won't be told how many unread articles there are in the
>   groups.

I believe that you understand it just fine.  I'll bet that the
gnus*get-new-news* methods were added after this variable.  Their
behavior, after all, duplicates some of the startup logic.

Perhaps a documentation change is in order.


> Before making the change mentioned above, these two parts of
> gnus-get-unread-articles seem to be what causes Gnus not to check all of
> the groups:
>
> 	 (foreign-level
> 	  (min
> 	   (cond ((and gnus-activate-foreign-newsgroups
> 		       (not (numberp gnus-activate-foreign-newsgroups)))
> 		  (1+ gnus-level-subscribed))
> 		 ((numberp gnus-activate-foreign-newsgroups)
> 		  gnus-activate-foreign-newsgroups)
> 		 (t 0))
> 	   level))
>
> For me foreign-level ended up set to 4.  Then this part of the code
> ends up checking whether 5 <= 4 and it's not so the group gets skipped.
>
> 	  (when (and (<= (gnus-info-level info) foreign-level)
> 		     (setq active (gnus-activate-group group 'scan)))
>
> I'm not sure what all of that means :)

The basic thrust is that your groups were not activating because gnus
thinks that they are foreign AND the foreign activation level was set
too low.

So the major question is, "Did Lars patch fix code that was
incorrectly classifying foreign groups as secondary or did it break
code by doing the opposite?".

Kevin

Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not

[Marcus Frings]

* Mark Plaksin <happy@usg.edu> wrote:

> Marcus: Does setting gnus-activate-foreign-newsgroups to 5 solve the
> problem for you?

I'll try this on Saturday or Sunday because I won't be at home earlier.

Regards,
Marcus
-- 
"Fear of ghosts is forcing me apart 
And the further I get from the things that I care about
The less I care about how much further away I get..."

Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not

[Mark Plaksin]

Kevin Greiner <kgreiner@xpediantsolutions.com> writes:

> Mark Plaksin <happy@mcplaksin.org> writes:
>
>> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>>
>>> Mark Plaksin <happy@mcplaksin.org> writes:
>>>
>>>> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>>>>
>>>>> Mark Plaksin <happy@mcplaksin.org> writes:
>>>>>
>>>>>> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>>>>>>
>>>>>>> Mark Plaksin <happy@mcplaksin.org> writes:
>>>>>>>
>>>>>>>> Marcus Frings <iam-est-hora-surgere@despammed.com> writes:
>>>>>>>>
>>>>>>>>> By the way, this is also a bug on my FreeBSD system. Both on Debian and
>>>>>>>>> FreeBSD I use GNU Emacs 21.3.1 (and `g' fails on all systems) but on two
>>>>>>>>> different Windoze boxes I use a CVS Emacs (and there `g' works without
>>>>>>>>> any problems). So the new code seems to work for CVS Emacs but fails on
>>>>>>>>> the current stable Emacs. Can this really be Emacs-specific?
>>>>>>>>
>>>>>>>> I have the problem with both CVS Emacs and the wonderful multi-tty
>>>>>>>> (http://lorentey.web.elte.hu/project/emacs.html) Emacs which is CVS
>>>>>>>> Emacs plus patches.
>>>>>>>
>>>>>>> This patch should be applied to rev 7.8 (CVS head) of gnus-start.el.
>>>>>>> Please let me know what the outcome is.  Finally, if this doesn't
>>>>>>> help, please revert to CVS head.
>>>>>>
>>>>>> Thanks for the patch!
>>>>>>
>>>>>> It doesn't change the behavior for me.  Testing this I was also
>>>>>> reminded that the problem affects my nnvirtual groups too.
>>>>>>
>>>>>> After patching, I exited Emacs, started up again, started Gnus (which
>>>>>> automatically checks groups at level 1), and then did 5 G.  Gnus
>>>>>> checked all groups at level 4 and below but no groups at level 5.  I
>>>>>> have both nnimap and nnvirtual groups at level 5.  As before, going to
>>>>>> the top topic and hitting ESC g (i.e., ESC < ESC g) checks all groups at
>>>>>> all levels.
>>>>>
>>>>> Well, I tried being a little smarter and did learn one fact.  The code
>>>>> that Lars patched in gnus-start and that I re-patched in my previous
>>>>> patch is never used when you do ESC < ESC g as you described.
>>>>>
>>>>> That would appear to indicate that your problems are being caused by
>>>>> the rather innocuous addition of two inline declarations in gnus.el.
>>>>> If so, the problem is more of an emacs bug that gnus, which would help
>>>>> explain why it is only seen on certain platforms.
>>>>>
>>>>> All right, enough talk.  Here's the patch for gnus.el.  As before,
>>>>> apply it to the current revision of gnus.el.  What is different is
>>>>> that you MUST delete all *.elc files before compiling gnus.  The
>>>>> reason is that gnus-secondary-method-p is an inline function (a
>>>>> defsubst) which, like a macro, is expanded at compilation time.
>>>>
>>>> Same results with this patch.  Can I provide more information or help
>>>> in some other way?
>>>
>>> Definitely.  I'll admit that right now, I'm skeptical that unpatching
>>> Lars code change actually fixes this problem.
>>>
>>> So, let's go back to the beginning.  The problem as I understand is
>>> that your nnimap, nnvirtual, perhaps other, groups are not fetching
>>> new articles.  As an example, the command 'ESC < ESC g' was provided.
>>>
>>> ESC < is move point OK
>>> ESC g gnus-topic-get-new-news-this-topic
>>>
>>> gnus-topic-get-new-news-this-topic is a fairly simple function that
>>> selects a set of groups then calls gnus-group-get-new-news-this-group.
>>> Hmmm.  That's identical to turning off the topic mode, marking several
>>> groups with '#', then pressing 'ESC g'.  Does this work for you or is
>>> it also broken?  (This will determine whether the problem is in selecting
>>> or processing the groups).
>>
>> [ I posted this earlier from another address but even after confirming
>> and waiting the "10 minutes", Gmane hasn't posted it so I'm trying
>> again.]
>>
>> This *works*.
>>
>> Your other suggestions got me looking at the code and I found that
>> changing gnus-activate-foreign-newsgroups from the default of 4 to 5
>> solves the problem for me.  The documentation for this variable makes it
>> sound like it's only relevant at startup but maybe I misunderstand it:
>>
>>   *If nil, Gnus will not check foreign newsgroups at startup.
>>   If it is non-nil, it should be a number between one and nine.  Foreign
>>   newsgroups that have a level lower or equal to this number will be
>>   activated on startup.  For instance, if you want to active all
>>   subscribed newsgroups, but not the rest, you'd set this variable to
>>   `gnus-level-subscribed'.
>>   
>>   If you subscribe to lots of newsgroups from different servers, startup
>>   might take a while.  By setting this variable to nil, you'll save time,
>>   but you won't be told how many unread articles there are in the
>>   groups.
>
> I believe that you understand it just fine.  I'll bet that the
> gnus*get-new-news* methods were added after this variable.  Their
> behavior, after all, duplicates some of the startup logic.
>
> Perhaps a documentation change is in order.
>
>> Before making the change mentioned above, these two parts of
>> gnus-get-unread-articles seem to be what causes Gnus not to check all of
>> the groups:
>>
>> 	 (foreign-level
>> 	  (min
>> 	   (cond ((and gnus-activate-foreign-newsgroups
>> 		       (not (numberp gnus-activate-foreign-newsgroups)))
>> 		  (1+ gnus-level-subscribed))
>> 		 ((numberp gnus-activate-foreign-newsgroups)
>> 		  gnus-activate-foreign-newsgroups)
>> 		 (t 0))
>> 	   level))
>>
>> For me foreign-level ended up set to 4.  Then this part of the code
>> ends up checking whether 5 <= 4 and it's not so the group gets skipped.
>>
>> 	  (when (and (<= (gnus-info-level info) foreign-level)
>> 		     (setq active (gnus-activate-group group 'scan)))
>>
>> I'm not sure what all of that means :)
>
> The basic thrust is that your groups were not activating because gnus
> thinks that they are foreign AND the foreign activation level was set
> too low.
>
> So the major question is, "Did Lars patch fix code that was
> incorrectly classifying foreign groups as secondary or did it break
> code by doing the opposite?".
>
> Kevin

The diff that Marcus posted indicates that the second section of code
above was unchanged by the patches in question.  The first part above
is what changed.  The ChangeLog entry for this change doesn't answer
your question though so perhaps it's just inadvertent breakage?

I don't understand the code change well enough to figure out what's
supposed to be happening.

Here's the relevant section of the diff:

Index: gnus-start.el
diff -u gnus/lisp/gnus-start.el:6.86 gnus/lisp/gnus-start.el:6.87
--- gnus-start.el:6.86	Mon Dec 22 15:06:54 2003
+++ gnus-start.el	Tue Dec 30 04:58:14 2003

[ ... ]

@@ -1639,12 +1642,25 @@
       ;; nil for non-foreign groups that the user has requested not be checked
       ;; t for unchecked foreign groups or bogus groups, or groups that can't
       ;;   be checked, for one reason or other.
-      (if (and (setq method (gnus-info-method info))
-	       (not (inline
-		      (gnus-server-equal
-		       gnus-select-method
-		       (setq method (gnus-server-get-method nil method)))))
-	       (not (gnus-secondary-method-p method)))
+      (when (setq method (gnus-info-method info))
+	(if (setq cmethod (assoc method methods-cache))
+	    (setq method (cdr cmethod))
+	  (setq cmethod (inline (gnus-server-get-method nil method)))
+	  (push (cons method cmethod) methods-cache)
+	  (setq method cmethod)))
+      (when (and method
+		 (not (setq method-type (cdr (assoc method type-cache)))))
+	(setq method-type
+	      (cond
+	       ((gnus-secondary-method-p method)
+		'secondary)
+	       ((inline (gnus-server-equal gnus-select-method method))
+		'primary)
+	       (t
+		'foreign)))
+	(push (cons method method-type) type-cache))
+      (if (and method
+	       (eq method-type 'foreign))
 	  ;; These groups are foreign.  Check the level.
 	  (when (and (<= (gnus-info-level info) foreign-level)
 		     (setq active (gnus-activate-group group 'scan)))

And the ChangeLog entry:
2003-12-30  Lars Magne Ingebrigtsen  <larsi@gnus.org>

	* gnus-start.el (gnus-get-unread-articles): Inline gnus-server-get-method.
	(gnus-get-unread-articles): Cache methods.
	(gnus-get-unread-articles-in-group): Indent.

	* gnus.el (gnus-version-number): Bump.
	(gnus-secondary-method-p): Extend servers to methods before comparing.
	(gnus-secondary-method-p): Revert.

Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not

[Marcus Frings]

* Mark Plaksin <happy@usg.edu> wrote:

> For me foreign-level ended up set to 4.  Then this part of the code
> ends up checking whether 5 <= 4 and it's not so the group gets skipped.

> Marcus: Does setting gnus-activate-foreign-newsgroups to 5 solve the
> problem for you?

No, unfortunately not. I have set the value from 4 to 5 but `g' doesn't
update my nnimap group. I still have to use `3 g' and so on.

Regards,
Marcus
-- 
"Did you really think I would not deduce where you would run to, insect?"
                                                 (Shodan in System Shock)

Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not

[Marcus Frings]

* Kevin Greiner <kgreiner@xpediantsolutions.com> wrote:

> Alright, let's try one last test concerning Lars patch.  Apply this
> patch to the clean (CVS head) revision of gnus-start.el.
> --- ../lisp.cvs_ref/gnus-start.el	Tue Mar  9 01:07:19 2004
> +++ gnus-start.el	Thu Mar 11 18:41:40 2004
> @@ -1673,6 +1673,7 @@
>  	       (t
>  		'foreign)))
>  	(push (cons method method-type) type-cache))
> +      (message "Group %s is %s" group method-type)
>        (if (and method
>  	       (eq method-type 'foreign))
>  	  ;; These groups are foreign.  Check the level.
> Trigger the bug then look in the *messages* buffer.  Search for one of
> the groups that did not update.  Did gnus correctly classify the
> group?  What type is this group (i.e. primary, secondary, foreign)?
> What type did gnus report?

Yes, groups are classified correctly, here's an example:

Group nnimap+192.168.0.1:INBOX is secondary

That's okay because I use `gnus-secondary-select-methods' to include my
IMAP stuff.

>> M-: (gnus-activate-group "INBOX")<RET>
>> It returns `nil'.

> OK, so the actual problem is somewhere inside of
> gnus-activate-group (We'll come back to this with the next message).
> Here's an interesting test.

> Try this
> M-x load-library gnus
> M-x load-library gnus-start.el
> M-x gnus

> Has the error gone away?

Unfortunately this hasn't caused the bug to disappear. `g' doesn't
update my IMAP groups, thus I'm still using `3 g' to refresh them.

Regards,
Marcus
-- 
"Two, Five, Zero, Zero, Zero
Jihad"

Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not

[Marcus Frings]

* Mark Plaksin <happy@mcplaksin.org> wrote:

> Here's the relevant section of the diff:

> Index: gnus-start.el
> diff -u gnus/lisp/gnus-start.el:6.86 gnus/lisp/gnus-start.el:6.87
> --- gnus-start.el:6.86	Mon Dec 22 15:06:54 2003
> +++ gnus-start.el	Tue Dec 30 04:58:14 2003

> [ ... ]

> @@ -1639,12 +1642,25 @@
>        ;; nil for non-foreign groups that the user has requested not be checked
>        ;; t for unchecked foreign groups or bogus groups, or groups that can't
>        ;;   be checked, for one reason or other.
> -      (if (and (setq method (gnus-info-method info))
> -	       (not (inline
> -		      (gnus-server-equal
> -		       gnus-select-method
> -		       (setq method (gnus-server-get-method nil method)))))
> -	       (not (gnus-secondary-method-p method)))
> +      (when (setq method (gnus-info-method info))
> +	(if (setq cmethod (assoc method methods-cache))
> +	    (setq method (cdr cmethod))
> +	  (setq cmethod (inline (gnus-server-get-method nil method)))
> +	  (push (cons method cmethod) methods-cache)
> +	  (setq method cmethod)))
> +      (when (and method
> +		 (not (setq method-type (cdr (assoc method type-cache)))))
> +	(setq method-type
> +	      (cond
> +	       ((gnus-secondary-method-p method)
> +		'secondary)
> +	       ((inline (gnus-server-equal gnus-select-method method))
> +		'primary)
> +	       (t
> +		'foreign)))
> +	(push (cons method method-type) type-cache))
> +      (if (and method
> +	       (eq method-type 'foreign))
>  	  ;; These groups are foreign.  Check the level.
>  	  (when (and (<= (gnus-info-level info) foreign-level)
>  		     (setq active (gnus-activate-group group 'scan)))

Yes, this one is the source of all evil. :-)

If I unpatch the current No Gnus and include 

,----
| (if (and (setq method (gnus-info-method info))
|       (not (inline
|             (gnus-server-equal
| 	     gnus-select-method
| 	     (setq method (gnus-server-get-method nil method)))))
|       (not (gnus-secondary-method-p method)))
`----

everything is working again.

Regards,
Marcus
-- 
"Look at you, hacker. A pathetic creature of meat and bone, panting and
sweating as you run through my corridors. How can you challenge a perfect,
immortal machine?"
                                                  (Shodan in System Shock)

Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not

[Kevin Greiner]

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

Marcus Frings <iam-est-hora-surgere@despammed.com> writes:

> * Mark Plaksin <happy@mcplaksin.org> wrote:
>
>> Here's the relevant section of the diff:
>
>> Index: gnus-start.el
>> diff -u gnus/lisp/gnus-start.el:6.86 gnus/lisp/gnus-start.el:6.87
>> --- gnus-start.el:6.86	Mon Dec 22 15:06:54 2003
>> +++ gnus-start.el	Tue Dec 30 04:58:14 2003
>
>> [ ... ]
>
>> @@ -1639,12 +1642,25 @@
>>        ;; nil for non-foreign groups that the user has requested not be checked
>>        ;; t for unchecked foreign groups or bogus groups, or groups that can't
>>        ;;   be checked, for one reason or other.
>> -      (if (and (setq method (gnus-info-method info))
>> -	       (not (inline
>> -		      (gnus-server-equal
>> -		       gnus-select-method
>> -		       (setq method (gnus-server-get-method nil method)))))
>> -	       (not (gnus-secondary-method-p method)))
>> +      (when (setq method (gnus-info-method info))
>> +	(if (setq cmethod (assoc method methods-cache))
>> +	    (setq method (cdr cmethod))
>> +	  (setq cmethod (inline (gnus-server-get-method nil method)))
>> +	  (push (cons method cmethod) methods-cache)
>> +	  (setq method cmethod)))
>> +      (when (and method
>> +		 (not (setq method-type (cdr (assoc method type-cache)))))
>> +	(setq method-type
>> +	      (cond
>> +	       ((gnus-secondary-method-p method)
>> +		'secondary)
>> +	       ((inline (gnus-server-equal gnus-select-method method))
>> +		'primary)
>> +	       (t
>> +		'foreign)))
>> +	(push (cons method method-type) type-cache))
>> +      (if (and method
>> +	       (eq method-type 'foreign))
>>  	  ;; These groups are foreign.  Check the level.
>>  	  (when (and (<= (gnus-info-level info) foreign-level)
>>  		     (setq active (gnus-activate-group group 'scan)))
>
> Yes, this one is the source of all evil. :-)

I do share your frustration.  We're right back to the beginning; my
original patch changed this code -- a change that proved ineffective.

Part of my problem is the lack of hard test data.  To that end, I've
written yet another patch :).  In this patch, gnus-start has both
algorithms - the working original and the broken optimization.  What's
also different is that I have a debug print on every last line of each
algorithm.

So, here's what I'd like to see.  Obviously, install the patch and
recompile gnus.

Then start gnus, try to trigger the error (in this version, the old
algorithm takes precidence so the groups will update correctly).  Then
switch to the 'kjg' buffer.

Please verify that this buffer contains, at least, one occurrance of
"DISCREPENCY LOCATED".  If it does, please send the contents of this
buffer to me.


[-- Attachment #2: gnus-start.patch3.txt --]
[-- Type: text/plain, Size: 3611 bytes --]

--- ../lisp.cvs_ref/gnus-start.el	Sun Mar 14 01:02:02 2004
+++ gnus-start.el	Sun Mar 14 00:59:48 2004
@@ -1619,6 +1619,12 @@
 	(setcar (gnus-group-entry (gnus-info-group info)) num))
       num)))
 
+(defun kjg (format &rest values)
+  (save-excursion 
+    (set-buffer (get-buffer-create "kjg"))
+    (insert (apply #'format format values) "\n"))
+  (car (last values)))
+
 ;; Go though `gnus-newsrc-alist' and compare with `gnus-active-hashtb'
 ;; and compute how many unread articles there are in each group.
 (defun gnus-get-unread-articles (&optional level)
@@ -1637,7 +1643,7 @@
 	 (methods-cache nil)
 	 (type-cache nil)
 	 scanned-methods info group active method retrieve-groups cmethod
-	 method-type)
+	 method-type new-results old-results)
     (gnus-message 6 "Checking new news...")
 
     (while newsrc
@@ -1656,25 +1662,44 @@
       ;; nil for non-foreign groups that the user has requested not be checked
       ;; t for unchecked foreign groups or bogus groups, or groups that can't
       ;;   be checked, for one reason or other.
-      (when (setq method (gnus-info-method info))
-	(if (setq cmethod (assoc method methods-cache))
-	    (setq method (cdr cmethod))
-	  (setq cmethod (inline (gnus-server-get-method nil method)))
-	  (push (cons method cmethod) methods-cache)
-	  (setq method cmethod)))
-      (when (and method
-		 (not (setq method-type (cdr (assoc method type-cache)))))
-	(setq method-type
-	      (cond
-	       ((gnus-secondary-method-p method)
-		'secondary)
-	       ((inline (gnus-server-equal gnus-select-method method))
-		'primary)
-	       (t
-		'foreign)))
-	(push (cons method method-type) type-cache))
-      (if (and method
-	       (eq method-type 'foreign))
+
+      (kjg "\n\nBeginning Test on Group %s" (gnus-info-group info))
+      (when (kjg "method = %s" (setq method (gnus-info-method info)))
+	(if (kjg "cmethod = %s" (setq cmethod (assoc method methods-cache)))
+	    (kjg "method = %s" (setq method (cdr cmethod)))
+	  (kjg "cmethod = %s" (setq cmethod (inline (gnus-server-get-method nil method))))
+	  (push (kjg "Pushed %s onto methods-cache" (cons method cmethod)) methods-cache)
+	  (kjg "method = %s" (setq method cmethod))))
+      (when (kjg "Need to calc method type is %s" 
+		 (and method
+		      (not (kjg "method-type = %s" (setq method-type (cdr (kjg "method[%s] entry in type-cache = %s" method (assoc method type-cache))))))))
+	(kjg "method-type = %s" (setq method-type
+				      (cond
+				       ((gnus-secondary-method-p method)
+					'secondary)
+				       ((inline (gnus-server-equal gnus-select-method method))
+					'primary)
+				       (t
+					'foreign))))
+	(push (kjg "Pushed %s onto type-cache" (cons method method-type)) type-cache))
+
+      (setq new-results (kjg "new-results = %s" (and method
+						     (eq method-type 'foreign))))
+
+      (kjg "Beginning old solution")
+      (setq old-results (and (kjg "method = %s" (setq method (gnus-info-method info)))
+			     (kjg "not equal = %s" (not (inline
+							  (gnus-server-equal
+							   gnus-select-method
+							   (kjg "method = %s" (setq method (gnus-server-get-method nil method)))))))
+			     (kjg "not secondary method = %s" (not (gnus-secondary-method-p method)))))
+
+      (kjg "old-results = %s" old-results)
+
+      (or (equal new-results old-results)
+	  (kjg "DISCREPENCY LOCATED: old-results = %s new-results = %s" old-results new-results))
+
+      (if old-results
 	  ;; These groups are foreign.  Check the level.
 	  (when (and (<= (gnus-info-level info) foreign-level)
 		     (setq active (gnus-activate-group group 'scan)))

[-- Attachment #3: Type: text/plain, Size: 7 bytes --]


Kevin

Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not

[Marcus Frings]

* Kevin Greiner <kgreiner@xpediantsolutions.com> wrote:

> I do share your frustration.  We're right back to the beginning; my
> original patch changed this code -- a change that proved ineffective.

:-) I'm not frustrated that much. In fact I really enjoy to help you to
fix the bug.

> Part of my problem is the lack of hard test data.  To that end, I've
> written yet another patch :).  In this patch, gnus-start has both

At this point I would really like to thank you because I deeply
appreciate your help in tracking down this bug.

> algorithms - the working original and the broken optimization.  What's
> also different is that I have a debug print on every last line of each
> algorithm.

> So, here's what I'd like to see.  Obviously, install the patch and
> recompile gnus.

I installed the patch and it compiled fine.

> Then start gnus, try to trigger the error (in this version, the old
> algorithm takes precidence so the groups will update correctly).  Then
> switch to the 'kjg' buffer.
> Please verify that this buffer contains, at least, one occurrance of
> "DISCREPENCY LOCATED".  If it does, please send the contents of this
> buffer to me.

I'll send you the whole content of the buffer in a private mail because I
don't want to publish all my groups and mailboxes here but of course you
can send your results to the list after analysing the buffer.

Regards,
Marcus
-- 
"Love for the death and for the defecation
Romance and assassination
Give me the love of genocide
Give me love"

Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not

[Mark Plaksin]

Marcus Frings <iam-est-hora-surgere@despammed.com> writes:

> * Kevin Greiner <kgreiner@xpediantsolutions.com> wrote:
>
>> I do share your frustration.  We're right back to the beginning; my
>> original patch changed this code -- a change that proved ineffective.
>
> :-) I'm not frustrated that much. In fact I really enjoy to help you to
> fix the bug.
>
>> Part of my problem is the lack of hard test data.  To that end, I've
>> written yet another patch :).  In this patch, gnus-start has both
>
> At this point I would really like to thank you because I deeply
> appreciate your help in tracking down this bug.

Me too!

>> Then start gnus, try to trigger the error (in this version, the old
>> algorithm takes precidence so the groups will update correctly).  Then
>> switch to the 'kjg' buffer.
>> Please verify that this buffer contains, at least, one occurrance of
>> "DISCREPENCY LOCATED".  If it does, please send the contents of this
>> buffer to me.

I didn't get any occurrences :(  In case it's useful, the (160k) output
is here:
http://mcplaksin.org/happy/kjg.txt

Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not

[Marcus Frings]

* Mark Plaksin <happy@mcplaksin.org> wrote:

>>> Please verify that this buffer contains, at least, one occurrance of
>>> "DISCREPENCY LOCATED".  If it does, please send the contents of this
>>> buffer to me.

> I didn't get any occurrences :(  In case it's useful, the (160k) output
> is here: http://mcplaksin.org/happy/kjg.txt

Well, I had some of these. Don't know what this means. :-)

Regards,
Marcus
-- 
"Hört, Ihr Leute, laßt Euch sagen: Einen Engel als Beute werden wir erschlagen!
Hab meinen Verstand begraben wie meine Seele im Wüstenboden... Und ich will
nicht länger warten, bis Gottes unendlicher Hoden endlich in Flammen aufgeht!"

Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not

[Kevin Greiner]

Marcus Frings <iam-est-hora-surgere@despammed.com> writes:

> * Mark Plaksin <happy@mcplaksin.org> wrote:
>
>>>> Please verify that this buffer contains, at least, one occurrance of
>>>> "DISCREPENCY LOCATED".  If it does, please send the contents of this
>>>> buffer to me.
>
>> I didn't get any occurrences :(  In case it's useful, the (160k) output
>> is here: http://mcplaksin.org/happy/kjg.txt
>
> Well, I had some of these. Don't know what this means. :-)

To answer your question, it means that the old, and new, algorithms
disagreed as to the type (primary, secondary, foreign) of the group's
server.  This supports your position that the new algorithm changed
the behavior of gnus.

So the question is, did the new algorithm introduce a new bug or fix
an old bug (one that you were incidentally depending on)?

Here's the debug for one of the groups (I changed the IP # just to
confuse any casual readers).

Beginning Test on Group nnimap+192.168.0.1:INBOX.Mark
method = nnimap:192.168.0.1

cmethod = (nnimap:192.168.0.1 nnimap 192.168.0.1 
  (nnimap-address 192.168.0.1)
  (nnimap-authinfo-file ~/.authinfo)
  (nnimap-stream ssl)
  (nnimap-list-pattern INBOX.*))

method = (nnimap 192.168.0.1 
  (nnimap-address 192.168.0.1)
  (nnimap-authinfo-file ~/.authinfo)
  (nnimap-stream ssl)
  (nnimap-list-pattern INBOX.*))
method[(nnimap 192.168.0.1 
          (nnimap-address 192.168.0.1)
          (nnimap-authinfo-file ~/.authinfo)
          (nnimap-stream ssl)
          (nnimap-list-pattern INBOX.*))]
 entry in type-cache = 
  ((nnimap 192.168.0.1 
      (nnimap-address 192.168.0.1)
      (nnimap-authinfo-file ~/.authinfo)
      (nnimap-stream ssl)
      (nnimap-list-pattern INBOX.*)) .
 secondary)
method-type = secondary
Need to calc method type is nil
new-results = nil
Beginning old solution
method = nnimap:192.168.0.1
method = (nnimap 192.168.0.1)
not equal = t
not secondary method = t
old-results = t
DISCREPENCY LOCATED: old-results = t new-results = nil

Now, to explain what this means.  By the debug, the value of
old-results was t so this expression evaluates to true.

(and (setq method (gnus-info-method info))
     (not (inline
	    (gnus-server-equal
	     gnus-select-method
	     (setq method (gnus-server-get-method nil method)))))
     (not (gnus-secondary-method-p method)))

The pseudo-code for this expression is

 (AND ... Have a non-nil method (The nil method is equivalent to the primary) ...
      (NOT ... Equal to the primary (gnus-select-method) method ...)
      (NOT ... Any of the known secondary methods ...))

or

The old algorithm concluded that this group was foreign.

Marcus, in your very first message (dated 18 Jan), you listed your
config as:

(setq gnus-secondary-select-methods
      '((nnimap "192.168.0.1"
		(nnimap-address "192.168.0.1")
		(nnimap-authinfo-file "~/.authinfo")
		(nnimap-stream ssl)
		(nnimap-list-pattern "INBOX.*")
		)))

This means that the (nnimap "192.168.0.1" ...) method shown in the
debug is a SECONDARY method.  This clearly shows that the old code was
buggy and that Lars new code fixed the bug.

As for your problem, gnus is certainly following a different branch in
the code.  You could be triggering either a latent bug in that code
or, the more likely, it's something in your configuration.

So let's take the easy path.  Open the gnus-start.el file and search
for ";; These groups are native or secondary.".  Insert this
expression after this line.

(when (equal (gnus-info-group info) "nnimap+192.168.0.1:INBOX.Mark")
  (debug))

Eval the buffer (don't compile it) then fetch the groups.  When the
debugger starts, use the 'c' and 'd' commands to step through the
gnus-get-unread-articles function.  Don't bother going to deep into the
functions it calls.  What you really want to know is which branch of
the cond is executed.

Here's the only issue left concerning Lars' code.  The value of the
variable 'method' is different.  In the old code, the variable
identified which method but none of the method parameters.  In the new
code, method identifies the fully-qualified method.  This should NOT
cause a problem.  However, your stepping though this code may tell a
different story.

Personally, my bet is that gnus is evaluating
(> (gnus-info-level info) level) as true.


Now then Mark, I suspect that you've been reading along so far.  Your
test results indicate that you didn't get any of the "DISCREPENCY
LOCATED" messages. That indicates that your problem is probably due to
'method' having a different value.  Hmmm... Didn't I just say that
that wasn't an issue?  This job just isn't fun anymore.

Gnus should be adding your groups to retrieve-groups. So, add the
debug expression shown above (with a suitable group name) then please
step through the code to see when it branched past the
(push (list method group) retrieve-groups) statement.

Thanks,
Kevin

Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not

[Marcus Frings]

* Kevin Greiner <kgreiner@xpediantsolutions.com> wrote:
> Marcus Frings <iam-est-hora-surgere@despammed.com> writes:
>> * Mark Plaksin <happy@mcplaksin.org> wrote:

>>>>> Please verify that this buffer contains, at least, one occurrance of
>>>>> "DISCREPENCY LOCATED".  If it does, please send the contents of this
>>>>> buffer to me.

>>> I didn't get any occurrences :(  In case it's useful, the (160k) output
>>> is here: http://mcplaksin.org/happy/kjg.txt

>> Well, I had some of these. Don't know what this means. :-)

> To answer your question, it means that the old, and new, algorithms
> disagreed as to the type (primary, secondary, foreign) of the group's
> server.  This supports your position that the new algorithm changed
> the behavior of gnus.

> So the question is, did the new algorithm introduce a new bug or fix
> an old bug (one that you were incidentally depending on)?

> Here's the debug for one of the groups (I changed the IP # just to
> confuse any casual readers).

> Beginning Test on Group nnimap+192.168.0.1:INBOX.Mark
> method = nnimap:192.168.0.1

> cmethod = (nnimap:192.168.0.1 nnimap 192.168.0.1 
>   (nnimap-address 192.168.0.1)
>   (nnimap-authinfo-file ~/.authinfo)
>   (nnimap-stream ssl)
>   (nnimap-list-pattern INBOX.*))

> method = (nnimap 192.168.0.1 
>   (nnimap-address 192.168.0.1)
>   (nnimap-authinfo-file ~/.authinfo)
>   (nnimap-stream ssl)
>   (nnimap-list-pattern INBOX.*))
> method[(nnimap 192.168.0.1 
>           (nnimap-address 192.168.0.1)
>           (nnimap-authinfo-file ~/.authinfo)
>           (nnimap-stream ssl)
>           (nnimap-list-pattern INBOX.*))]
>  entry in type-cache = 
>   ((nnimap 192.168.0.1 
>       (nnimap-address 192.168.0.1)
>       (nnimap-authinfo-file ~/.authinfo)
>       (nnimap-stream ssl)
>       (nnimap-list-pattern INBOX.*)) .
>  secondary)
> method-type = secondary
> Need to calc method type is nil
> new-results = nil
> Beginning old solution
> method = nnimap:192.168.0.1
> method = (nnimap 192.168.0.1)
> not equal = t
> not secondary method = t
> old-results = t
> DISCREPENCY LOCATED: old-results = t new-results = nil

> Now, to explain what this means.  By the debug, the value of
> old-results was t so this expression evaluates to true.

> (and (setq method (gnus-info-method info))
>      (not (inline
> 	    (gnus-server-equal
> 	     gnus-select-method
> 	     (setq method (gnus-server-get-method nil method)))))
>      (not (gnus-secondary-method-p method)))

> The pseudo-code for this expression is
>  (AND ... Have a non-nil method (The nil method is equivalent to the primary) ...
>       (NOT ... Equal to the primary (gnus-select-method) method ...)
>       (NOT ... Any of the known secondary methods ...))

> or

> The old algorithm concluded that this group was foreign.

> Marcus, in your very first message (dated 18 Jan), you listed your
> config as:

> (setq gnus-secondary-select-methods
>       '((nnimap "192.168.0.1"
> 		(nnimap-address "192.168.0.1")
> 		(nnimap-authinfo-file "~/.authinfo")
> 		(nnimap-stream ssl)
> 		(nnimap-list-pattern "INBOX.*")
> 		)))

> This means that the (nnimap "192.168.0.1" ...) method shown in the
> debug is a SECONDARY method.  This clearly shows that the old code was
> buggy and that Lars new code fixed the bug.

Ah, okay.

> As for your problem, gnus is certainly following a different branch in
> the code.  You could be triggering either a latent bug in that code
> or, the more likely, it's something in your configuration.

I also thought in the first place that there could be a bug in my
configuration since I have a pretty large setup which is divided into
many separate files but now I am sure for 100 % that my configuration is
fine because the bug also shows up if I load my gnus_server.el *only*
(and no other Gnus configuration files!). My gnus_server.el:

,----[ gnus_server.el ]
| (setq gnus-select-method '(nntp "iridium.home.local"))
| 
| (setq gnus-read-active-file 'some)
| 
| (setq gnus-check-new-newsgroups 'ask-server)
| 
| (setq gnus-save-killed-list nil)
| 
| (setq gnus-check-bogus-newsgroups 'ask-server)
| 
| (setq gnus-secondary-select-methods
|       '((nnimap "192.168.0.1"
| 		(nnimap-address "192.168.0.1")
| 		(nnimap-authinfo-file "~/.authinfo")
| 		(nnimap-stream ssl)
| 		(nnimap-list-pattern "INBOX.*")
| 		)))
| 
| (add-to-list 'gnus-secondary-select-methods
| 	     '(nntp "gmane" (nntp-address "news.gmane.org")))
| 
| (setq gnus-refer-article-method
|       '(current
| 	(nntp "iridium.home.local")           ; lokaler Newsserver
| 	(nntp "news.t-online.de")             ; news.t-online.de
|         (nnweb "google" (nnweb-type google))  ; groups.google.com
| 	(nntp "news.gmane.org")))             ; news.gmane.org
| 
| (setq gnus-refer-thread-limit t)
`----

In my opinion there's nothing in my setup that could cause the bug.

> So let's take the easy path.  Open the gnus-start.el file and search
> for ";; These groups are native or secondary.".  Insert this
> expression after this line.

> (when (equal (gnus-info-group info) "nnimap+192.168.0.1:INBOX.Mark")
>   (debug))

> Eval the buffer (don't compile it) then fetch the groups.  When the

One question: Should I have patched an unmodified gnus-start.el or the
one which contains the patch with both of the old and new algorithms
from your last mail? By the way, I patched an original gnus-start.el
from a fresh upstream CVS checkout.

> debugger starts, use the 'c' and 'd' commands to step through the
> gnus-get-unread-articles function.  Don't bother going to deep into the
> functions it calls.  What you really want to know is which branch of
> the cond is executed.

> Here's the only issue left concerning Lars' code.  The value of the
> variable 'method' is different.  In the old code, the variable
> identified which method but none of the method parameters.  In the new
> code, method identifies the fully-qualified method.  This should NOT
> cause a problem.  However, your stepping though this code may tell a
> different story.

> Personally, my bet is that gnus is evaluating
> (> (gnus-info-level info) level) as true.

Well, I have done what you asked me to do but unfortunately I failed to
find any valuable information. When I hit "c" it just runs through and
the *Backtrace* buffer will be closed immediately within 1 second. Then
I used "d" to go step by step (Argh, I guess I had to hit "d" more than
1000 times :-) but I was unable to recognize something interesting
concerning (> (gnus-info-level info) level) because I really have no
clue about Lisp debugging. 

> Now then Mark, I suspect that you've been reading along so far.  Your
> test results indicate that you didn't get any of the "DISCREPENCY
> LOCATED" messages. That indicates that your problem is probably due to
> 'method' having a different value.  Hmmm... Didn't I just say that
> that wasn't an issue?  This job just isn't fun anymore.
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  :-)

One thing I haven't understood yet:
Why does it fail on Emacs 21.3.1 but works with a (Windows) CVS Emacs
which I downloaded from <http://www.crasseux.com/>?

Regards,
Marcus
-- 
"The father's eyes said `Beautiful! How beautiful you are!'. The boy's eyes
said `How beautiful! She glitters like a star!'. The child's eyes uttered joy
and stilled my heart with sadness for the way we are. And this is why I hate
you and how I understand that no-one ever knows or loves another."

Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not

[Kevin Greiner]

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

Marcus Frings <iam-est-hora-surgere@despammed.com> writes:

...Trimmed...

> I also thought in the first place that there could be a bug in my
> configuration since I have a pretty large setup which is divided into
> many separate files but now I am sure for 100 % that my configuration is
> fine because the bug also shows up if I load my gnus_server.el *only*
> (and no other Gnus configuration files!). My gnus_server.el:
>
> ,----[ gnus_server.el ]
> | (setq gnus-select-method '(nntp "iridium.home.local"))
> | 
> | (setq gnus-read-active-file 'some)
> | 
> | (setq gnus-check-new-newsgroups 'ask-server)
> | 
> | (setq gnus-save-killed-list nil)
> | 
> | (setq gnus-check-bogus-newsgroups 'ask-server)
> | 
> | (setq gnus-secondary-select-methods
> |       '((nnimap "192.168.0.1"
> | 		(nnimap-address "192.168.0.1")
> | 		(nnimap-authinfo-file "~/.authinfo")
> | 		(nnimap-stream ssl)
> | 		(nnimap-list-pattern "INBOX.*")
> | 		)))
> | 
> | (add-to-list 'gnus-secondary-select-methods
> | 	     '(nntp "gmane" (nntp-address "news.gmane.org")))
> | 
> | (setq gnus-refer-article-method
> |       '(current
> | 	(nntp "iridium.home.local")           ; lokaler Newsserver
> | 	(nntp "news.t-online.de")             ; news.t-online.de
> |         (nnweb "google" (nnweb-type google))  ; groups.google.com
> | 	(nntp "news.gmane.org")))             ; news.gmane.org
> | 
> | (setq gnus-refer-thread-limit t)
> `----
>
> In my opinion there's nothing in my setup that could cause the bug.

I agree.

>> So let's take the easy path.  Open the gnus-start.el file and search
>> for ";; These groups are native or secondary.".  Insert this
>> expression after this line.
>
>> (when (equal (gnus-info-group info) "nnimap+192.168.0.1:INBOX.Mark")
>>   (debug))
>
>> Eval the buffer (don't compile it) then fetch the groups.  When the
>
> One question: Should I have patched an unmodified gnus-start.el or the
> one which contains the patch with both of the old and new algorithms
> from your last mail? By the way, I patched an original gnus-start.el
> from a fresh upstream CVS checkout.

Doing patches on top of patches tends to get messy.  The patch will be
for a fresh file from the CVS head.

>> debugger starts, use the 'c' and 'd' commands to step through the
>> gnus-get-unread-articles function.  Don't bother going to deep into the
>> functions it calls.  What you really want to know is which branch of
>> the cond is executed.
>
>> Here's the only issue left concerning Lars' code.  The value of the
>> variable 'method' is different.  In the old code, the variable
>> identified which method but none of the method parameters.  In the new
>> code, method identifies the fully-qualified method.  This should NOT
>> cause a problem.  However, your stepping though this code may tell a
>> different story.
>
>> Personally, my bet is that gnus is evaluating
>> (> (gnus-info-level info) level) as true.
>
> Well, I have done what you asked me to do but unfortunately I failed to
> find any valuable information. When I hit "c" it just runs through and
> the *Backtrace* buffer will be closed immediately within 1 second. Then
> I used "d" to go step by step (Argh, I guess I had to hit "d" more than
> 1000 times :-) but I was unable to recognize something interesting
> concerning (> (gnus-info-level info) level) because I really have no
> clue about Lisp debugging. 

Sorry about that.  If I ask for something that takes more than a
couple of minutes, please feel free to ask for something easier.

>> Now then Mark, I suspect that you've been reading along so far.  Your
>> test results indicate that you didn't get any of the "DISCREPENCY
>> LOCATED" messages. That indicates that your problem is probably due to
>> 'method' having a different value.  Hmmm... Didn't I just say that
>> that wasn't an issue?  This job just isn't fun anymore.
>                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  :-)
>
> One thing I haven't understood yet:
> Why does it fail on Emacs 21.3.1 but works with a (Windows) CVS Emacs
> which I downloaded from <http://www.crasseux.com/>?

Just part of the strangeness.  I personally use Emacs 21.3.1 and have
consistently failed to reproduce this problem.

Let's try approaching this from an old direction.  Instead of focusing
on Lars' patch, let's try to trace the execution to the point of
breakage.

The attached patch introduces diagnostic trace statements to four
different files.  The instructions are:
1) Apply the patch to clean files from CVS, recompile, then start gnus.
2) Do ESC < ESC g in the group buffer.
3) Send me the contents of the kjg buffer.

Thanks,
Kevin


[-- Attachment #2: patch3.txt --]
[-- Type: text/plain, Size: 13147 bytes --]

--- ../lisp.cvs_ref/gnus-group.el	Mon Mar  1 20:12:29 2004
+++ gnus-group.el	Mon Mar 22 19:17:51 2004
@@ -2357,6 +2357,8 @@
 	;; ... and then yanking it.  Magic!
 	(gnus-group-yank-group)
 	(gnus-set-active new-name (gnus-active group))
+	(gnus-cache-rename-group group new-name)
+	(gnus-agent-rename-group group new-name)
 	(gnus-message 6 "Renaming group %s to %s...done" group new-name)
 	new-name)
     (setq gnus-killed-list (delete group gnus-killed-list))
@@ -3504,7 +3506,7 @@
   ;; First we make sure that we have really read the active file.
   (unless (gnus-read-active-file-p)
     (let ((gnus-read-active-file t)
-	  (gnus-agent nil))		; Trick the agent into ignoring the active file.
+	  (gnus-agent gnus-plugged)); If we're actually plugged, store the active file in the agent.
       (gnus-read-active-file)))
   ;; Find all groups and sort them.
   (let ((groups
@@ -3583,12 +3585,15 @@
     (gnus-group-list-groups (and (numberp arg)
 				 (max (car gnus-group-list-mode) arg)))))
 
+(autoload 'kjg "gnus-start")
+
 (defun gnus-group-get-new-news-this-group (&optional n dont-scan)
   "Check for newly arrived news in the current group (and the N-1 next groups).
 The difference between N and the number of newsgroup checked is returned.
 If N is negative, this group and the N-1 previous groups will be checked."
   (interactive "P")
-  (let* ((groups (gnus-group-process-prefix n))
+  (kjg "(gnus-group-get-new-news-this-group %s %s)" n dont-scan)
+  (let* ((groups (kjg "groups = %s" (gnus-group-process-prefix n)))
 	 (ret (if (numberp n) (- n (length groups)) 0))
 	 (beg (unless n
 		(point)))
--- ../lisp.cvs_ref/gnus-int.el	Tue Mar  9 02:07:19 2004
+++ gnus-int.el	Mon Mar 22 19:17:51 2004
@@ -331,16 +331,24 @@
   (funcall (gnus-get-function gnus-command-method 'request-regenerate)
 	   (nth 1 gnus-command-method)))
 
+(autoload 'kjg "gnus-start")
+
 (defun gnus-request-group (group &optional dont-check gnus-command-method)
   "Request GROUP.  If DONT-CHECK, no information is required."
+  (kjg "(gnus-request-group %s %s %s)" group dont-check gnus-command-method)
   (let ((gnus-command-method
-	 (or gnus-command-method (inline (gnus-find-method-for-group group)))))
+	 (or gnus-command-method (inline (kjg "(gnus-find-method-for-group %s) => %s" group (gnus-find-method-for-group group))))))
     (when (stringp gnus-command-method)
-      (setq gnus-command-method
-	    (inline (gnus-server-to-method gnus-command-method))))
-    (funcall (inline (gnus-get-function gnus-command-method 'request-group))
+      (kjg "gnus-command-method = %s" (setq gnus-command-method
+	    (inline (gnus-server-to-method gnus-command-method)))))
+    (kjg "(funcall %s %s %s %s) => %s" 
+	 (gnus-get-function gnus-command-method 'request-group) 
+	 (kjg "(gnus-group-real-name %s) => %s" group (gnus-group-real-name group))
+	 (nth 1 gnus-command-method)
+	 dont-check
+	 (funcall (inline (gnus-get-function gnus-command-method 'request-group))
 	     (gnus-group-real-name group) (nth 1 gnus-command-method)
-	     dont-check)))
+	     dont-check))))
 
 (defun gnus-list-active-group (group)
   "Request active information on GROUP."
--- ../lisp.cvs_ref/gnus-start.el	Sun Mar 14 02:02:02 2004
+++ gnus-start.el	Mon Mar 22 18:24:18 2004
@@ -1481,9 +1481,10 @@
 (defun gnus-activate-group (group &optional scan dont-check method)
   ;; Check whether a group has been activated or not.
   ;; If SCAN, request a scan of that group as well.
-  (let ((method (or method (inline (gnus-find-method-for-group group))))
+  (kjg "(gnus-activate-group %s %s %s %s)" group scan dont-check method)
+  (let ((method (kjg "method = %s" (or method (inline (gnus-find-method-for-group group)))))
 	active)
-    (and (inline (gnus-check-server method))
+    (and (kjg "(gnus-check-server %s) => %s" method (inline (gnus-check-server method)))
 	 ;; We escape all bugs and quit here to make it possible to
 	 ;; continue if a group is so out-there that it reports bugs
 	 ;; and stuff.
@@ -1501,7 +1502,7 @@
 	      (message "Quit activating %s" group)
 	      nil)))
 	 (unless dont-check
-	   (setq active (gnus-parse-active))
+	   (setq active (kjg "(gnus-parse-active) = %s" (gnus-parse-active)))
 	   ;; If there are no articles in the group, the GROUP
 	   ;; command may have responded with the `(0 . 0)'.  We
 	   ;; ignore this if we already have an active entry
@@ -1522,7 +1523,7 @@
 
 	     (gnus-set-active group active)
 	     ;; Return the new active info.
-	     active)))))
+	     (kjg "active = %s" active))))))
 
 (defun gnus-get-unread-articles-in-group (info active &optional update)
   (when active
@@ -1619,6 +1620,12 @@
 	(setcar (gnus-group-entry (gnus-info-group info)) num))
       num)))
 
+(defun kjg (format &rest values)
+  (save-excursion 
+    (set-buffer (get-buffer-create "kjg"))
+    (insert (apply #'format format values) "\n"))
+  (car (last values)))
+
 ;; Go though `gnus-newsrc-alist' and compare with `gnus-active-hashtb'
 ;; and compute how many unread articles there are in each group.
 (defun gnus-get-unread-articles (&optional level)
@@ -1673,53 +1680,52 @@
 	       (t
 		'foreign)))
 	(push (cons method method-type) type-cache))
-      (if (and method
-	       (eq method-type 'foreign))
-	  ;; These groups are foreign.  Check the level.
-	  (when (and (<= (gnus-info-level info) foreign-level)
-		     (setq active (gnus-activate-group group 'scan)))
-	    ;; Let the Gnus agent save the active file.
-	    (when (and gnus-agent active (gnus-online method))
-	      (gnus-agent-save-group-info
-	       method (gnus-group-real-name group) active))
-	    (unless (inline (gnus-virtual-group-p group))
-	      (inline (gnus-close-group group)))
-	    (when (fboundp (intern (concat (symbol-name (car method))
-					   "-request-update-info")))
-	      (inline (gnus-request-update-info info method))))
-	;; These groups are native or secondary.
-	(cond
-	 ;; We don't want these groups.
-	 ((> (gnus-info-level info) level)
-	  (setq active 'ignore))
-	 ;; Activate groups.
-	 ((not gnus-read-active-file)
-	  (if (gnus-check-backend-function 'retrieve-groups group)
-	      ;; if server support gnus-retrieve-groups we push
-	      ;; the group onto retrievegroups for later checking
-	      (if (assoc method retrieve-groups)
-		  (setcdr (assoc method retrieve-groups)
-			  (cons group (cdr (assoc method retrieve-groups))))
-		(push (list method group) retrieve-groups))
-	    ;; hack: `nnmail-get-new-mail' changes the mail-source depending
-	    ;; on the group, so we must perform a scan for every group
-	    ;; if the users has any directory mail sources.
-	    ;; hack: if `nnmail-scan-directory-mail-source-once' is non-nil,
-	    ;; for it scan all spool files even when the groups are
-	    ;; not required.
-	    (if (and
-		 (or nnmail-scan-directory-mail-source-once
-		     (null (assq 'directory
-				 (or mail-sources
-				     (if (listp nnmail-spool-file)
-					 nnmail-spool-file
-				       (list nnmail-spool-file))))))
-		 (member method scanned-methods))
-		(setq active (gnus-activate-group group))
-	      (setq active (gnus-activate-group group 'scan))
-	      (push method scanned-methods))
-	    (when active
-	      (gnus-close-group group))))))
+
+      (cond ((kjg "(eq method-type 'foreign) = %s" (eq method-type 'foreign))
+	     ;; These groups are foreign.  Check the level.
+	     (when (and (kjg "(<= (gnus-info-level info) foreign-level) = %s" (<= (gnus-info-level info) foreign-level))
+			(kjg "(setq active (gnus-activate-group group 'scan)) = %s" (setq active (gnus-activate-group group 'scan))))
+	       ;; Let the Gnus agent save the active file.
+	       (when (and gnus-agent active (gnus-online method))
+		 (gnus-agent-save-group-info
+		  method (gnus-group-real-name group) active))
+	       (unless (inline (gnus-virtual-group-p group))
+		 (inline (gnus-close-group group)))
+	       (when (fboundp (intern (concat (symbol-name (car method))
+					      "-request-update-info")))
+		 (inline (gnus-request-update-info info method)))))
+	    ;; These groups are native or secondary.
+	    ((kjg "(> (gnus-info-level info) level) = %s" (> (gnus-info-level info) level))
+	     ;; We don't want these groups.
+	     (setq active 'ignore))
+	    ;; Activate groups.
+	    ((kjg "(not gnus-read-active-file) = %s" (not gnus-read-active-file))
+	     (if (gnus-check-backend-function 'retrieve-groups group)
+		 ;; if server support gnus-retrieve-groups we push
+		 ;; the group onto retrievegroups for later checking
+		 (if (assoc method retrieve-groups)
+		     (setcdr (assoc method retrieve-groups)
+			     (cons group (cdr (assoc method retrieve-groups))))
+		   (push (list method group) retrieve-groups))
+	       ;; hack: `nnmail-get-new-mail' changes the mail-source depending
+	       ;; on the group, so we must perform a scan for every group
+	       ;; if the users has any directory mail sources.
+	       ;; hack: if `nnmail-scan-directory-mail-source-once' is non-nil,
+	       ;; for it scan all spool files even when the groups are
+	       ;; not required.
+	       (if (and
+		    (or nnmail-scan-directory-mail-source-once
+			(null (assq 'directory
+				    (or mail-sources
+					(if (listp nnmail-spool-file)
+					    nnmail-spool-file
+					  (list nnmail-spool-file))))))
+		    (member method scanned-methods))
+		   (setq active (gnus-activate-group group))
+		 (setq active (gnus-activate-group group 'scan))
+		 (push method scanned-methods))
+	       (when active
+		 (gnus-close-group group)))))
 
       ;; Get the number of unread articles in the group.
       (cond
@@ -1936,10 +1942,13 @@
 
 ;; Get the active file(s) from the backend(s).
 (defun gnus-read-active-file (&optional force not-native)
+  (kjg "(gnus-read-active-file %s %s)" force not-native)
   (gnus-group-set-mode-line)
   (let ((methods
 	 (mapcar
-	  (lambda (m) (if (stringp m) (gnus-server-get-method nil m) m))
+	  (lambda (m) (kjg "m = %s; method = %s"
+			   m
+			   (if (stringp m) (gnus-server-get-method nil m) m)))
 	  (append
 	   (if (and (not not-native)
 		    (gnus-check-server gnus-select-method))
@@ -1970,38 +1979,45 @@
 	       nil))))))))
 
 (defun gnus-read-active-file-1 (method force)
+  (kjg "(gnus-read-active-file-1 %s %s)" method force)
   (let (where mesg)
     (setq where (nth 1 method)
 	  mesg (format "Reading active file%s via %s..."
 		       (if (and where (not (zerop (length where))))
 			   (concat " from " where) "")
 		       (car method)))
+    (kjg mesg)
     (gnus-message 5 mesg)
-    (when (gnus-check-server method)
+    (when (kjg "(gnus-check-server method) = %s" (gnus-check-server method))
       ;; Request that the backend scan its incoming messages.
-      (when (gnus-check-backend-function 'request-scan (car method))
+      (when (kjg "(gnus-check-backend-function 'request-scan (car method)) = %s"
+		 (gnus-check-backend-function 'request-scan (car method)))
 	(gnus-request-scan nil method))
       (cond
        ((and (eq gnus-read-active-file 'some)
-	     (gnus-check-backend-function 'retrieve-groups (car method))
+	     (kjg "(gnus-check-backend-function 'retrieve-groups (car method)) = %s" 
+		  (gnus-check-backend-function 'retrieve-groups (car method)))
 	     (not force))
 	(let ((newsrc (cdr gnus-newsrc-alist))
-	      (gmethod (gnus-server-get-method nil method))
+	      (gmethod (kjg "gmethod = %s" (gnus-server-get-method nil method)))
 	      groups info)
 	  (while (setq info (pop newsrc))
 	    (when (inline
-		    (gnus-server-equal
-		     (inline
-		       (gnus-find-method-for-group
-			(gnus-info-group info) info))
-		     gmethod))
-	      (push (gnus-group-real-name (gnus-info-group info))
+		    (kjg "gnus-server-equal = %s"
+			 (gnus-server-equal
+			  (inline
+			    (kjg "(gnus-find-method-for-group %s info) = %s" 
+				 (gnus-info-group info)
+				 (gnus-find-method-for-group
+				  (gnus-info-group info) info)))
+			  gmethod)))
+	      (push (kjg "Pushing %s onto groups" (gnus-group-real-name (gnus-info-group info)))
 		    groups)))
 	  (gnus-read-active-file-2 groups method)))
        ((null method)
 	t)
        (t
-	(if (not (gnus-request-list method))
+	(if (not (kjg "(gnus-request-list method) = %s" (gnus-request-list method)))
 	    (unless (equal method gnus-message-archive-method)
 	      (gnus-error 1 "Cannot read active file from %s server"
 			  (car method)))
--- ../lisp.cvs_ref/gnus-topic.el	Thu Feb 12 07:24:52 2004
+++ gnus-topic.el	Mon Mar 22 19:17:50 2004
@@ -1453,12 +1453,15 @@
       (call-interactively 'gnus-group-unmark-group)
     (gnus-topic-mark-topic topic t non-recursive)))
 
+(autoload 'kjg "gnus-start")
+
 (defun gnus-topic-get-new-news-this-topic (&optional n)
   "Check for new news in the current topic."
   (interactive "P")
+  (kjg "(gnus-topic-get-new-news-this-topic)")
   (if (not (gnus-group-topic-p))
       (gnus-group-get-new-news-this-group n)
-    (let* ((topic (gnus-group-topic-name))
+    (let* ((topic (kjg "topic = %s" (gnus-group-topic-name)))
 	   (data (cadr (gnus-topic-find-topology topic))))
       (save-excursion
 	(gnus-topic-mark-topic topic nil (and n t))

Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not

[Marcus Frings]

* Kevin Greiner <kgreiner@xpediantsolutions.com> wrote:
> Marcus Frings <iam-est-hora-surgere@despammed.com> writes:

>> One question: Should I have patched an unmodified gnus-start.el or the
>> one which contains the patch with both of the old and new algorithms
>> from your last mail? By the way, I patched an original gnus-start.el
>> from a fresh upstream CVS checkout.

> Doing patches on top of patches tends to get messy.  The patch will be
> for a fresh file from the CVS head.

Ah, okay.

> Sorry about that.  If I ask for something that takes more than a
> couple of minutes, please feel free to ask for something easier.

Hehehehehe, no, you are silly! :-) I really have no problem with
spending plenty of hours if it helps you to identify the bug and then
get rid of it. My only problem was that I didn't really know what I was
doing and what I should have looked for when I had a look at the
*backtrace* buffer. ;-)

>> One thing I haven't understood yet:
>> Why does it fail on Emacs 21.3.1 but works with a (Windows) CVS Emacs
>> which I downloaded from <http://www.crasseux.com/>?

> Just part of the strangeness.  I personally use Emacs 21.3.1 and have
> consistently failed to reproduce this problem.

Hm, then I will apply your patch also on Gnus at my Windows system and
send you both of the buffers (Linux and Windows). Maybe you can find
something different this way.

> Let's try approaching this from an old direction.  Instead of focusing
> on Lars' patch, let's try to trace the execution to the point of
> breakage.

> The attached patch introduces diagnostic trace statements to four
> different files.  The instructions are:
> 1) Apply the patch to clean files from CVS, recompile, then start gnus.
> 2) Do ESC < ESC g in the group buffer.
> 3) Send me the contents of the kjg buffer.

I have applied the patches and created your buffer. I will send
the output by mail because the file is about 40 KB.

Regards,
Marcus
-- 
"Als Hirte erlaube mir, zu dienen meinem Vater dir. Deine Macht reichst du uns
durch deine Hand. Diese verbindet uns wie ein heiliges Band. Wir waten durch
ein Meer von Blut. Herr, gib uns dafür Kraft und Mut. In nomine patris,
et filii, et spiritu sancti."

Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not

[Marcus Frings]

* Kevin Greiner <kgreiner@xpediantsolutions.com> wrote:

> Let's try approaching this from an old direction.  Instead of focusing
> on Lars' patch, let's try to trace the execution to the point of
> breakage.

> The attached patch introduces diagnostic trace statements to four
> different files.  The instructions are:
> 1) Apply the patch to clean files from CVS, recompile, then start gnus.
> 2) Do ESC < ESC g in the group buffer.
> 3) Send me the contents of the kjg buffer.

Kevin, I sent the output of the buffer almost 3 weeks ago and
contacted you via private mail two times but you never replied. Any
progress in removing the bug?

Regards,
Marcus
-- 
"To call up a demon you must learn its name. Men dreamed that, once, but now it
is real in another way. You know that, Case. Your business is to learn the names
of programs, the long formal names, names the owners seek to conceal. True
names ..." - "A Turing code's not your name." - "Neuromancer", the boy said.

Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not

[Kevin Greiner]

Marcus Frings <iam-est-hora-surgere@despammed.com> writes:

> * Kevin Greiner <kgreiner@xpediantsolutions.com> wrote:
>
>> Let's try approaching this from an old direction.  Instead of focusing
>> on Lars' patch, let's try to trace the execution to the point of
>> breakage.
>
>> The attached patch introduces diagnostic trace statements to four
>> different files.  The instructions are:
>> 1) Apply the patch to clean files from CVS, recompile, then start gnus.
>> 2) Do ESC < ESC g in the group buffer.
>> 3) Send me the contents of the kjg buffer.
>
> Kevin, I sent the output of the buffer almost 3 weeks ago and
> contacted you via private mail two times but you never replied. Any
> progress in removing the bug?

Something strange going on as I replied to your email twice; the
second time being on 3/29.  To summarize, gnus appears to have
functioned correctly in both test files.  In each case, the agent
passed the request forward so that nnimap-request-group was called.
The only difference I could find, and it is insignificant since the
group request was made, is that the server for the Systemmeldungen
group was listed as foreign in the first file and secondary in the
second file.

Do you want to pursue this further?

Kevin

Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not

[Marcus Frings]

Sorry for the late response!

* Kevin Greiner <kgreiner@xpediantsolutions.com> wrote:

> Something strange going on as I replied to your email twice; the
> second time being on 3/29.  To summarize, gnus appears to have

Hm, very strange. I have got none of your two mails, at least none of
them reached my regular inbox on my system. Did you send them to my FROM
or my REPLY-TO address? Both addresses have a server-side preprocessed
spam-filter before mails get through to my regular inbox on my computer
(where is also a local Spamassassin running) but I couldn't find them in
any of my spam folders. However, I think the problem is solved. See
below.

> functioned correctly in both test files.  In each case, the agent
> passed the request forward so that nnimap-request-group was called.
> The only difference I could find, and it is insignificant since the
> group request was made, is that the server for the Systemmeldungen
> group was listed as foreign in the first file and secondary in the
> second file.

> Do you want to pursue this further?

Well, I think finally I got rid of the annoying problem. As you said
some groups are listed as foreign and some as secondary. So I removed
all my IMAP groups with "U" and even killed them with "S
k". Additionally I have also removed every agent related folder about
IMAP in my home directory. Then I left Gnus, started it up again and
subscribed every IMAP group again from using "A A".

As it seems everything is working again now! If I press "g" to refresh
the group buffer all IMAP groups get updated when new mail is available!
I checked it several times the last days just to be sure that I'm not
talking bullshit here and as far as it concerns me everything with my
IMAP groups is fine again now - problem solved!

I want to thank you *very* much for all your effort you put into this
issue (code, testing, analyzing...)! Now I can enjoy my IMAP stuff in
Gnus again. ;-)

Regards,
Marcus
-- 
"To call up a demon you must learn its name. Men dreamed that, once, but now it
is real in another way. You know that, Case. Your business is to learn the names
of programs, the long formal names, names the owners seek to conceal. True
names ..." - "A Turing code's not your name." - "Neuromancer", the boy said.