From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/56706 Path: main.gmane.org!not-for-mail From: Kevin Greiner Newsgroups: gmane.emacs.gnus.general Subject: Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not Date: Fri, 12 Mar 2004 00:40:42 -0600 Sender: ding-owner@lists.math.uh.edu Message-ID: References: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1B1n8L-0002eO-00 for ; Fri, 12 Mar 2004 14:55:29 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1B1n8C-0006zq-00; Fri, 12 Mar 2004 07:55:20 -0600 Original-Received: from justine.libertine.org ([66.139.78.221] ident=postfix) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1B1gLf-0006EF-00 for ding@lists.math.uh.edu; Fri, 12 Mar 2004 00:40:47 -0600 Original-Received: from quimby.gnus.org (quimby.gnus.org [80.91.224.244]) by justine.libertine.org (Postfix) with ESMTP id 953B93A01F4 for ; Fri, 12 Mar 2004 00:40:46 -0600 (CST) Original-Received: from news by quimby.gnus.org with local (Exim 3.35 #1 (Debian)) id 1B1gLd-0007Oi-00 for ; Fri, 12 Mar 2004 07:40:45 +0100 Original-To: ding@gnus.org Original-Path: not-for-mail Original-Newsgroups: gnus.ding Original-Lines: 139 Original-NNTP-Posting-Host: dialup-216-12-206-138.ev1.net Original-X-Trace: quimby.gnus.org 1079073645 26443 216.12.206.138 (12 Mar 2004 06:40:45 GMT) Original-X-Complaints-To: usenet@quimby.gnus.org Original-NNTP-Posting-Date: Fri, 12 Mar 2004 06:40:45 +0000 (UTC) User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (windows-nt) Cancel-Lock: sha1:mrWbkZnjJbIyWqI7SUMmAKx8hPo= Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:56706 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:56706 Mark Plaksin writes: > Kevin Greiner writes: > >> Mark Plaksin writes: >> >>> Kevin Greiner writes: >>> >>>> Mark Plaksin writes: >>>> >>>>> Kevin Greiner writes: >>>>> >>>>>> Mark Plaksin writes: >>>>>> >>>>>>> Marcus Frings 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