From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/50784 Path: main.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.gnus.general Subject: Re: nnimap doing redundant work? Date: Tue, 11 Mar 2003 19:00:10 +0100 Sender: owner-ding@hpc.uh.edu Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1047405827 13163 80.91.224.249 (11 Mar 2003 18:03:47 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 11 Mar 2003 18:03:47 +0000 (UTC) Cc: ding@hpc.uh.edu Original-X-From: owner-ding@hpc.uh.edu Tue Mar 11 19:03:46 2003 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18so3o-00035m-00 for ; Tue, 11 Mar 2003 19:01:08 +0100 Original-Received: from sina.hpc.uh.edu ([129.7.128.10] ident=lists) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 18so3O-00010P-00; Tue, 11 Mar 2003 12:00:42 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Tue, 11 Mar 2003 12:01:42 -0600 (CST) Original-Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id MAA20982 for ; Tue, 11 Mar 2003 12:01:28 -0600 (CST) Original-Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.8/8.12.8) with ESMTP id h2BI0BZG011058 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 11 Mar 2003 19:00:11 +0100 Original-To: David Abrahams Mail-Copies-To: nobody X-Payment: hashcash 1.2 0:030311:dave@boost-consulting.com:145d41f0c6e45162 X-Hashcash: 0:030311:dave@boost-consulting.com:145d41f0c6e45162 X-Payment: hashcash 1.2 0:030311:ding@hpc.uh.edu:7929449658190d80 X-Hashcash: 0:030311:ding@hpc.uh.edu:7929449658190d80 In-Reply-To: (David Abrahams's message of "Tue, 11 Mar 2003 12:03:16 -0500") User-Agent: Gnus/5.090016 (Oort Gnus v0.16) Emacs/21.3.50 (gnu/linux) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:50784 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:50784 David Abrahams writes: > Simon Josefsson writes: > >> David Abrahams writes: >> >>>> How do you set up the nnimap server definition in Gnus (i.e., >>>> ~/.gnus or ~/.emacs snippet)? >>> >>> (setq gnus-select-method >>> '(nnimap "www.stlport.com" >>> (nnimap-address "www.stlport.com") >>> (nnimap-stream ssl) >>> (nnimap-authenticator login) >>> )) >> >> Perhaps this hasn't been tested much. Could you kill all groups, >> restart emacs with this definition instead: >> >> (setq gnus-select-method '(nnnil "") >> gnus-secondary-select-methods '((nnimap "www.stlport.com" >> (nnimap-address "www.stlport.com") >> (nnimap-stream ssl) >> (nnimap-authenticator login) >> ))) > > nnimap: Updating info for nnimap+www.stlport.com:INBOX...done > Retrieving newsgroup: nnimap+www.stlport.com:INBOX... > nnimap: Updating info for nnimap+www.stlport.com:INBOX...done > Fetching headers for nnimap+www.stlport.com:INBOX...done > Generating summary...done > No more unread articles > > > Also, the group buffer was pretty strange after I did this; several > groups appeared multiple times. I had to kill them and re-check my > subscriptions in order to clean things up. Did you kill all groups and then resubscribed to them? No mention of the old groups in ~/.newsrc* when you press `s' in Gnus? Do you have any customization when entering a group? Or just any kind of customization that might affect this? >> If this solves it, it is probably easy to reproduce the problem. If >> you like to debug the lisp to see why this happens, that would be >> appreciated. > > I'm very bad at elisp debugging (not very competent with edebug), but > if there's a specifc thing you want me to look at I'll be happy to do > it. Let's try to get things into a working state first, then it is easier to debug; just do a binary search between the working state and the buggy state until the cause of the problem is found. It still takes some energy though, so perhaps you'll settle with simply having the problem disappear. But is useful too, the mailing list archive will document this, in case someone wants to debug this in the future.