From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/30837 Path: main.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.emacs.gnus.general Subject: Trying to document some of gnus' darkish corners -- please help. Date: 11 May 2000 17:43:17 -0500 Sender: owner-ding@hpc.uh.edu Message-ID: <87vh0kpv22.fsf@raven.localnet> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035167318 10614 80.91.224.250 (21 Oct 2002 02:28:38 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 02:28:38 +0000 (UTC) Cc: ding@gnus.org Return-Path: Original-Received: from lisa.math.uh.edu (lisa.math.uh.edu [129.7.128.49]) by mailhost.sclp.com (Postfix) with ESMTP id 797CDD0520 for ; Thu, 11 May 2000 18:44:31 -0400 (EDT) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by lisa.math.uh.edu (8.9.1/8.9.1) with ESMTP id RAB00955; Thu, 11 May 2000 17:44:24 -0500 (CDT) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Thu, 11 May 2000 17:43:22 -0500 (CDT) Original-Received: from mailhost.sclp.com (postfix@sclp3.sclp.com [204.252.123.139]) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id RAA28328 for ; Thu, 11 May 2000 17:43:10 -0500 (CDT) Original-Received: from mail11.jump.net (mail11.jump.net [207.8.124.20]) by mailhost.sclp.com (Postfix) with ESMTP id 282A4D0521 for ; Thu, 11 May 2000 18:43:30 -0400 (EDT) Original-Received: from cust-53-56.customer.jump.net (cust-35-56.customer.jump.net [216.30.73.56]) by mail11.jump.net (8.9.0/) with ESMTP id RAA07756 for ; Thu, 11 May 2000 17:43:30 -0500 (CDT) Original-Received: from raven.localnet (raven.localnet [192.168.1.7]) by cust-53-56.customer.jump.net (Postfix) with ESMTP id AE7E8278E9 for ; Thu, 11 May 2000 17:43:23 -0500 (CDT) Original-Received: by raven.localnet (Postfix, from userid 1000) id EA81DAEA7; Thu, 11 May 2000 17:43:18 -0500 (CDT) Original-Newsgroups: gnu.emacs.gnus Original-Lines: 83 User-Agent: Gnus/5.0806 (Gnus v5.8.6) Emacs/20.6 Posted-To: gnu.emacs.gnus Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:30837 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:30837 The following message is a courtesy copy of an article that has been posted to gnu.emacs.gnus as well. (If it's impolite to post this issue to both the newsgroup and the ding list, then just let me know and I'll be more careful in the future, but I suspected the audiences were different and that both might be interested and able to help.) I've had a fairly painful set of experiences with gnus over the past few years where what I thought it was going to do, and what it did were two different things. To some extent, this was my fault for assuming that things would actually work the way that I considered reasonable, but to some extent, I think clearer docs would have saved me. As a result, I'm interested in trying to figure out what the current state of affairs is with respect to a few issues, and to help (re)write some info docs to clear these things up. Along those lines, I'd like to see who knows the answers to any or all of the following questions. Please try and be careful to either make sure you're sure you're right, or just make it clear that you're not sure. Some of the problems I've had in the past came from people making suggestions that sounded like they should have worked, but actually didn't because Gnus hadn't quite fully implemented X or Y feature that interacted badly with the change they suggested. I'm happy to double check things as long as I know I need to. I'd also like to answer these questions just because it'll make it clearer what the overall intent/design of the current architecture is. 1) Is gnus supposed to preserve article marks across backend respools (B r)? If not, why not, and also if not, then might it make sense to add a separate command that *will* preserve the marks? (I just lost about 1400 marks because I forgot that gnus would clobber them in this situation -- kinda painful). 2) When you mark a crossposted article, what's supposed to happen to the other copies? I had assumed that when you marked a crossposted article, either all of the copies would get the same mark, or copies other than the one being directly marked would be left alone. Neither seems to be the case. Right now it seems that at least in some cases, the article you mark gets the mark you indicate, and the crossposted copies get a different mark (in my experience the copies are marked as read). This seems worse than either of the two alternatives I mention above, though perhaps I'm missing something. The reason I noticed this is because I used to use the default expire mechanism (where you have to mark articles with 'E' to expire them) and then, at someone's suggestion, I turned on crossposting. When I went to expire large numbers of crossposted articles, I just assumed that the other copies would either get expired or left alone (so that I'd have to expire them directly later). What actually happened was that the other copies were just marked as read, not expired, and they sat around on disk until I noticed that my partition was filling up, and made me suspicious enough to investigate. Of course this is also potientially dangerous if you don't know about it and you're using total-expire. Say you mark a crossposted article as urgent or dormant, and now it gets marked as read elsewhere which means it'll get deleted. If this isn't what you expected, it could be bad. So do the copies get marked as read? Should they? (I'll have to test this one and see.) I'm not sure what I'd like to see ideally, but it might be nice to have a flag you can set (or a separate command) that would have it just ask you what mark to give the crossposted copies when it notices that the article is crossposted. I'm not sure that's feasible though. Alternately, I think either using the same mark everywhere, or not marking the copies at all, might be better, but as I said, perhaps I'm missing the justification for the current behavior. These are the two main issues I've got right now. It's not so much that I want the behaviors changed, though that might be appropriate. More importantly, I just want a clear understanding, and clear documentation, of the status-quo so that I don't keep shooting myself in the foot. Thanks for any help. -- Rob Browning PGP=E80E0D04F521A094 532B97F5D64E3930