From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/58573 Path: main.gmane.org!not-for-mail From: Kevin Greiner Newsgroups: gmane.emacs.gnus.general Subject: Re: Gnus losing information about what has been read Date: Fri, 24 Sep 2004 11:29:29 -0500 Sender: ding-owner@lists.math.uh.edu Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1096043409 3230 80.91.229.6 (24 Sep 2004 16:30:09 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 24 Sep 2004 16:30:09 +0000 (UTC) Original-X-From: ding-owner+M7111@lists.math.uh.edu Fri Sep 24 18:29:58 2004 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13] ident=mail) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CAsxK-00040O-00 for ; Fri, 24 Sep 2004 18:29:58 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu ident=lists) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1CAsx1-00080u-00; Fri, 24 Sep 2004 11:29:39 -0500 Original-Received: from util2.math.uh.edu ([129.7.128.23]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1CAswx-00080p-00 for ding@lists.math.uh.edu; Fri, 24 Sep 2004 11:29:35 -0500 Original-Received: from justine.libertine.org ([66.139.78.221] ident=postfix) by util2.math.uh.edu with esmtp (Exim 4.30) id 1CAswx-0002YJ-5l for ding@lists.math.uh.edu; Fri, 24 Sep 2004 11:29:35 -0500 Original-Received: from quimby.gnus.org (quimby.gnus.org [80.91.224.244]) by justine.libertine.org (Postfix) with ESMTP id C48C43A01F6 for ; Fri, 24 Sep 2004 11:29:31 -0500 (CDT) Original-Received: from news by quimby.gnus.org with local (Exim 3.35 #1 (Debian)) id 1CAsws-00051p-00 for ; Fri, 24 Sep 2004 18:29:30 +0200 Original-To: ding@gnus.org Original-Path: not-for-mail Original-Newsgroups: gnus.ding Original-Lines: 78 Original-NNTP-Posting-Host: 198.64.160.238 Original-X-Trace: quimby.gnus.org 1096043370 19231 198.64.160.238 (24 Sep 2004 16:29:30 GMT) Original-X-Complaints-To: usenet@quimby.gnus.org Original-NNTP-Posting-Date: Fri, 24 Sep 2004 16:29:30 +0000 (UTC) User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (windows-nt) Cancel-Lock: sha1:lyiEEFVONcItu3PchPHBGq/zECg= Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:58573 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:58573 Kevin Greiner writes: > Ralf Angeli writes: > >> * Kevin Greiner (2004-09-24) writes: >> >>> Ralf Angeli writes: >>> >>>> * Kevin Greiner (2004-09-24) writes: >>>> >>>>> I'm trying an entirely different aproach now as it turned out that the >>>>> nntp implementation required the server to be open for >>>>> nntp-marks-file-name to be correct. >>>>> >>>>> It appears that the agent's synchronization function could actually >>>>> try to write the flags back to itself. Then, having done so, delete >>>>> the flags file so that all of the flags were lost. I've added some >>>>> additional checks. Please give it a try. >>>> >>>> After a fresh CVS checkout I don't get the error related to >>>> `nntp-marks-file-name' being nil anymore. I noticed a message in the >>>> echo area upon leaving a group in unplugged state with e.g. `q': >>>> >>>> Added to /home/angeli/News/agent/nntp/news.gmane.org/agent.lib/flags >>>> >>>> While there are no errors anymore, the marks are forgotten again. >>>> Tested this by starting Emacs/Gnus in plugged state, downloading new >>>> articles into the agent with `J s', switching to unplugged state with >>>> `J j', reading the articles, shutting down Gnus in unplugged state >>>> with `q y' and restarting Emacs and Gnus in plugged state. >>> >>> Have you customized gnus-agent-synchronize-flags? If it is null, >>> automatic synchronization will be completely turned off. >> >> It is customized to t: >> >> ,----[ C-h v gnus-agent-synchronize-flags RET ] >> | gnus-agent-synchronize-flags's value is t >> `---- >> >>> From this description, the unplugged flags are being saved but never >>> sync'ed. In the last step, when you restart emacs and gnus in a >>> plugged state, do you automatically perform a fetch session ('J s')? >> >> No, I am always doing this manually. > > Are you willing/able to do a little lisp debugging for me? If so, please do the following: > 1) Run gnus as you've described up to the point where you've seen the 'Added to ... agent.lib/flags' message. > 2) Start a new emacs process. > 3) Do M-x load-librarygnus-agent.el > 4) Do M-x debug-on-entrygnus-agent-possibly-synchronize-flags > 5) Do M-x gnus > > The questions that I need you to answer are: > > 1) Is gnus-agent-possibly-synchronize-flags being called? That is, do > you ever drop into the debugger? > > 2) As you step through the execution. You should see where gnus > checks for the existence of the agent.lib/flags file. There's one > file for each server. Does gnus check specifically for the > news.gmane.org server's file? > > 3) If the file is found, gnus will attempt to open the server. Does > that open succeed? > > 4) Finally, a (eval (read (current-buffer))) expression is performed > several times. Does it seem to return normally or does it signal > an error? Excellent news. I've finally reproduced the problem. It's very subtle and I've no idea what specifically is happening so far. As best I can tell, I have to generate marks in several groups before the problem occurs. The agent part of the process seems to work fine yet the group/summary buffers don't reflect the changes that are taking place. Kevin