* Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not
2004-03-10 18:58 ` PATCH II (for testing only): [Bug, Debian(?)] "g" goes not Kevin Greiner
@ 2004-03-10 19:38 ` Mark Plaksin
2004-03-10 22:36 ` Marcus Frings
` (10 subsequent siblings)
11 siblings, 0 replies; 42+ messages in thread
From: Mark Plaksin @ 2004-03-10 19:38 UTC (permalink / raw)
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?
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not
2004-03-10 18:58 ` PATCH II (for testing only): [Bug, Debian(?)] "g" goes not Kevin Greiner
2004-03-10 19:38 ` Mark Plaksin
@ 2004-03-10 22:36 ` Marcus Frings
2004-03-11 0:10 ` Kevin Greiner
` (9 subsequent siblings)
11 siblings, 0 replies; 42+ messages in thread
From: Marcus Frings @ 2004-03-10 22:36 UTC (permalink / raw)
* 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!"
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not
2004-03-10 18:58 ` PATCH II (for testing only): [Bug, Debian(?)] "g" goes not Kevin Greiner
2004-03-10 19:38 ` Mark Plaksin
2004-03-10 22:36 ` Marcus Frings
@ 2004-03-11 0:10 ` Kevin Greiner
2004-03-11 22:35 ` Marcus Frings
` (8 subsequent siblings)
11 siblings, 0 replies; 42+ messages in thread
From: Kevin Greiner @ 2004-03-11 0:10 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not
2004-03-10 18:58 ` PATCH II (for testing only): [Bug, Debian(?)] "g" goes not Kevin Greiner
` (2 preceding siblings ...)
2004-03-11 0:10 ` Kevin Greiner
@ 2004-03-11 22:35 ` Marcus Frings
2004-03-12 0:48 ` Kevin Greiner
2004-03-13 22:13 ` Marcus Frings
2004-03-12 1:04 ` Mark Plaksin
` (7 subsequent siblings)
11 siblings, 2 replies; 42+ messages in thread
From: Marcus Frings @ 2004-03-11 22:35 UTC (permalink / raw)
* 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"
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not
2004-03-11 22:35 ` Marcus Frings
@ 2004-03-12 0:48 ` Kevin Greiner
2004-03-13 22:13 ` Marcus Frings
1 sibling, 0 replies; 42+ messages in thread
From: Kevin Greiner @ 2004-03-12 0:48 UTC (permalink / raw)
[-- 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?
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not
2004-03-11 22:35 ` Marcus Frings
2004-03-12 0:48 ` Kevin Greiner
@ 2004-03-13 22:13 ` Marcus Frings
1 sibling, 0 replies; 42+ messages in thread
From: Marcus Frings @ 2004-03-13 22:13 UTC (permalink / raw)
* 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"
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not
2004-03-10 18:58 ` PATCH II (for testing only): [Bug, Debian(?)] "g" goes not Kevin Greiner
` (3 preceding siblings ...)
2004-03-11 22:35 ` Marcus Frings
@ 2004-03-12 1:04 ` Mark Plaksin
2004-03-12 3:42 ` Mark Plaksin
` (6 subsequent siblings)
11 siblings, 0 replies; 42+ messages in thread
From: Mark Plaksin @ 2004-03-12 1:04 UTC (permalink / raw)
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?
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not
2004-03-10 18:58 ` PATCH II (for testing only): [Bug, Debian(?)] "g" goes not Kevin Greiner
` (4 preceding siblings ...)
2004-03-12 1:04 ` Mark Plaksin
@ 2004-03-12 3:42 ` Mark Plaksin
2004-03-12 6:40 ` Kevin Greiner
` (5 subsequent siblings)
11 siblings, 0 replies; 42+ messages in thread
From: Mark Plaksin @ 2004-03-12 3:42 UTC (permalink / raw)
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?
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not
2004-03-10 18:58 ` PATCH II (for testing only): [Bug, Debian(?)] "g" goes not Kevin Greiner
` (5 preceding siblings ...)
2004-03-12 3:42 ` Mark Plaksin
@ 2004-03-12 6:40 ` Kevin Greiner
2004-03-12 12:37 ` Marcus Frings
` (4 subsequent siblings)
11 siblings, 0 replies; 42+ messages in thread
From: Kevin Greiner @ 2004-03-12 6:40 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not
2004-03-10 18:58 ` PATCH II (for testing only): [Bug, Debian(?)] "g" goes not Kevin Greiner
` (6 preceding siblings ...)
2004-03-12 6:40 ` Kevin Greiner
@ 2004-03-12 12:37 ` Marcus Frings
2004-03-13 15:23 ` Mark Plaksin
` (3 subsequent siblings)
11 siblings, 0 replies; 42+ messages in thread
From: Marcus Frings @ 2004-03-12 12:37 UTC (permalink / raw)
* 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..."
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not
2004-03-10 18:58 ` PATCH II (for testing only): [Bug, Debian(?)] "g" goes not Kevin Greiner
` (7 preceding siblings ...)
2004-03-12 12:37 ` Marcus Frings
@ 2004-03-13 15:23 ` Mark Plaksin
2004-03-13 20:22 ` Marcus Frings
` (2 subsequent siblings)
11 siblings, 0 replies; 42+ messages in thread
From: Mark Plaksin @ 2004-03-13 15:23 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not
2004-03-10 18:58 ` PATCH II (for testing only): [Bug, Debian(?)] "g" goes not Kevin Greiner
` (8 preceding siblings ...)
2004-03-13 15:23 ` Mark Plaksin
@ 2004-03-13 20:22 ` Marcus Frings
2004-03-13 23:10 ` Marcus Frings
[not found] ` <m38yi87ar9.fsf@ <m3brn0db3t.fsf@water.tss.usg.edu>
11 siblings, 0 replies; 42+ messages in thread
From: Marcus Frings @ 2004-03-13 20:22 UTC (permalink / raw)
* 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)
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not
2004-03-10 18:58 ` PATCH II (for testing only): [Bug, Debian(?)] "g" goes not Kevin Greiner
` (9 preceding siblings ...)
2004-03-13 20:22 ` Marcus Frings
@ 2004-03-13 23:10 ` Marcus Frings
[not found] ` <m38yi87ar9.fsf@ <m3brn0db3t.fsf@water.tss.usg.edu>
11 siblings, 0 replies; 42+ messages in thread
From: Marcus Frings @ 2004-03-13 23:10 UTC (permalink / raw)
* 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)
^ permalink raw reply [flat|nested] 42+ messages in thread[parent not found: <m38yi87ar9.fsf@ <m3brn0db3t.fsf@water.tss.usg.edu>]
* Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not
[not found] ` <m38yi87ar9.fsf@ <m3brn0db3t.fsf@water.tss.usg.edu>
@ 2004-03-14 7:17 ` Kevin Greiner
2004-03-14 13:16 ` Marcus Frings
[not found] ` <v <vita-brevis-breviter-in-brevi-finietur-mors-venit-velociter-quae-neminem-veretur-87d67fpo0n.fsf@gothgoose.net>
2 siblings, 0 replies; 42+ messages in thread
From: Kevin Greiner @ 2004-03-14 7:17 UTC (permalink / raw)
[-- 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
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not
[not found] ` <m38yi87ar9.fsf@ <m3brn0db3t.fsf@water.tss.usg.edu>
2004-03-14 7:17 ` Kevin Greiner
@ 2004-03-14 13:16 ` Marcus Frings
[not found] ` <v <vita-brevis-breviter-in-brevi-finietur-mors-venit-velociter-quae-neminem-veretur-87d67fpo0n.fsf@gothgoose.net>
2 siblings, 0 replies; 42+ messages in thread
From: Marcus Frings @ 2004-03-14 13:16 UTC (permalink / raw)
* 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"
^ permalink raw reply [flat|nested] 42+ messages in thread[parent not found: <v <vita-brevis-breviter-in-brevi-finietur-mors-venit-velociter-quae-neminem-veretur-87d67fpo0n.fsf@gothgoose.net>]
* Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not
[not found] ` <v <vita-brevis-breviter-in-brevi-finietur-mors-venit-velociter-quae-neminem-veretur-87d67fpo0n.fsf@gothgoose.net>
@ 2004-03-14 13:27 ` Mark Plaksin
2004-03-16 3:38 ` Kevin Greiner
` (2 more replies)
2004-03-14 14:12 ` Marcus Frings
1 sibling, 3 replies; 42+ messages in thread
From: Mark Plaksin @ 2004-03-14 13:27 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not
2004-03-14 13:27 ` Mark Plaksin
@ 2004-03-16 3:38 ` Kevin Greiner
2004-03-21 17:44 ` Marcus Frings
[not found] ` <vita-brevis-breviter-in-brevi-finietur-mors-venit-velociter-quae-neminem-ve <ud67dea0u.fsf@xpediantsolutions.com>
2 siblings, 0 replies; 42+ messages in thread
From: Kevin Greiner @ 2004-03-16 3:38 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not
2004-03-14 13:27 ` Mark Plaksin
2004-03-16 3:38 ` Kevin Greiner
@ 2004-03-21 17:44 ` Marcus Frings
[not found] ` <vita-brevis-breviter-in-brevi-finietur-mors-venit-velociter-quae-neminem-ve <ud67dea0u.fsf@xpediantsolutions.com>
2 siblings, 0 replies; 42+ messages in thread
From: Marcus Frings @ 2004-03-21 17:44 UTC (permalink / raw)
* 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."
^ permalink raw reply [flat|nested] 42+ messages in thread[parent not found: <vita-brevis-breviter-in-brevi-finietur-mors-venit-velociter-quae-neminem-ve <ud67dea0u.fsf@xpediantsolutions.com>]
* Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not
[not found] ` <vita-brevis-breviter-in-brevi-finietur-mors-venit-velociter-quae-neminem-ve <ud67dea0u.fsf@xpediantsolutions.com>
@ 2004-03-23 1:30 ` Kevin Greiner
2004-03-23 20:37 ` Marcus Frings
` (2 subsequent siblings)
3 siblings, 0 replies; 42+ messages in thread
From: Kevin Greiner @ 2004-03-23 1:30 UTC (permalink / raw)
[-- 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))
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not
[not found] ` <vita-brevis-breviter-in-brevi-finietur-mors-venit-velociter-quae-neminem-ve <ud67dea0u.fsf@xpediantsolutions.com>
2004-03-23 1:30 ` Kevin Greiner
@ 2004-03-23 20:37 ` Marcus Frings
2004-04-17 16:09 ` Marcus Frings
[not found] ` <vita-brevis-breviter-in-brevi-finietur-mors-venit-velociter-quae-neminem-veretur-87brmqdri1.fsf@gothgoose.net <u3c80e4ex.fsf@xpediantsolutions.com>
3 siblings, 0 replies; 42+ messages in thread
From: Marcus Frings @ 2004-03-23 20:37 UTC (permalink / raw)
* 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."
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not
[not found] ` <vita-brevis-breviter-in-brevi-finietur-mors-venit-velociter-quae-neminem-ve <ud67dea0u.fsf@xpediantsolutions.com>
2004-03-23 1:30 ` Kevin Greiner
2004-03-23 20:37 ` Marcus Frings
@ 2004-04-17 16:09 ` Marcus Frings
[not found] ` <vita-brevis-breviter-in-brevi-finietur-mors-venit-velociter-quae-neminem-veretur-87brmqdri1.fsf@gothgoose.net <u3c80e4ex.fsf@xpediantsolutions.com>
3 siblings, 0 replies; 42+ messages in thread
From: Marcus Frings @ 2004-04-17 16:09 UTC (permalink / raw)
* 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.
^ permalink raw reply [flat|nested] 42+ messages in thread[parent not found: <vita-brevis-breviter-in-brevi-finietur-mors-venit-velociter-quae-neminem-veretur-87brmqdri1.fsf@gothgoose.net <u3c80e4ex.fsf@xpediantsolutions.com>]
* Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not
[not found] ` <vita-brevis-breviter-in-brevi-finietur-mors-venit-velociter-quae-neminem-veretur-87brmqdri1.fsf@gothgoose.net <u3c80e4ex.fsf@xpediantsolutions.com>
@ 2004-04-18 20:29 ` Kevin Greiner
2004-04-27 12:25 ` Marcus Frings
1 sibling, 0 replies; 42+ messages in thread
From: Kevin Greiner @ 2004-04-18 20:29 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not
[not found] ` <vita-brevis-breviter-in-brevi-finietur-mors-venit-velociter-quae-neminem-veretur-87brmqdri1.fsf@gothgoose.net <u3c80e4ex.fsf@xpediantsolutions.com>
2004-04-18 20:29 ` Kevin Greiner
@ 2004-04-27 12:25 ` Marcus Frings
1 sibling, 0 replies; 42+ messages in thread
From: Marcus Frings @ 2004-04-27 12:25 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not
[not found] ` <v <vita-brevis-breviter-in-brevi-finietur-mors-venit-velociter-quae-neminem-veretur-87d67fpo0n.fsf@gothgoose.net>
2004-03-14 13:27 ` Mark Plaksin
@ 2004-03-14 14:12 ` Marcus Frings
1 sibling, 0 replies; 42+ messages in thread
From: Marcus Frings @ 2004-03-14 14:12 UTC (permalink / raw)
* 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!"
^ permalink raw reply [flat|nested] 42+ messages in thread