From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/32878 Path: main.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.emacs.gnus.general Subject: "Fixing up" gnus - (how hard is this?). (was Re: (provide 'nnmaildir)) Date: 17 Oct 2000 11:00:17 -0500 Sender: owner-ding@hpc.uh.edu Message-ID: <87aec3o3u6.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 1035169087 22246 80.91.224.250 (21 Oct 2002 02:58:07 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 02:58:07 +0000 (UTC) Cc: ding@gnus.org Return-Path: Original-Received: from spinoza.math.uh.edu (spinoza.math.uh.edu [129.7.128.18]) by mailhost.sclp.com (Postfix) with ESMTP id D56B3D051E for ; Tue, 17 Oct 2000 12:01:24 -0400 (EDT) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by spinoza.math.uh.edu (8.9.1/8.9.1) with ESMTP id LAB19820; Tue, 17 Oct 2000 11:00:54 -0500 (CDT) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Tue, 17 Oct 2000 11:00:17 -0500 (CDT) Original-Received: from mailhost.sclp.com (postfix@66-209.196.61.interliant.com [209.196.61.66] (may be forged)) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id LAA23622 for ; Tue, 17 Oct 2000 11:00:04 -0500 (CDT) Original-Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54]) by mailhost.sclp.com (Postfix) with ESMTP id 30616D051E for ; Tue, 17 Oct 2000 12:00:30 -0400 (EDT) Original-Received: from omen.localnet ([24.162.113.38]) by mail.austin.rr.com with Microsoft SMTPSVC(5.5.1877.537.53); Tue, 17 Oct 2000 11:02:28 -0500 Original-Received: from raven.localnet (raven.localnet [192.168.1.7]) by omen.localnet (Postfix) with ESMTP id 2A35727C4B; Tue, 17 Oct 2000 11:00:24 -0500 (CDT) Original-Received: by raven.localnet (Postfix, from userid 1000) id 6DA1EAEA4; Tue, 17 Oct 2000 11:00:18 -0500 (CDT) Original-To: prj@po.cwru.edu (Paul Jarc) In-Reply-To: Simon Josefsson's message of "05 Oct 2000 10:57:28 +0200" Original-Lines: 103 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:32878 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:32878 Simon Josefsson writes: > prj@po.cwru.edu (Paul Jarc) writes: > > > What do 'killed, 'dormant, 'save, 'download, and 'unsend mean? Do > > they persist between Gnus sessions? > > Unsend is for nndraft:queue only (I think), killed isn't persistant (I > think), the others are persistant but if the backend can't implement > them (some IMAP can't store flags) Gnus keep them in .newsrc.eld. So > you shouldn't need to worry. (This note is being precipitated by another one of my talented friends dumping gnus because it DTWT one too many times. He loved gnus, but over time, there were some problems that just made it untenable for him to keep using it. I've got some similar problems (though not quite the same), and I'm trying to decide how hard it might be to finally fix gnus to address my concerns. In addition, I'm trying to decide whether or not my fixes, if any, would be likely to be accepted upstream. I don't want to throw away the effort if I'm trying to go against the direction gnus is headed :>) I've thought about hacking up a backend that fixes some of my major gripes with gnus, but I didn't know how hard it would be. One of my gripes is that you can't easily just archive a group (by copying/moving directories), and have gnus DTRT. This is both because gnus doesn't store the readness info with the files, and because gnus keeps its own idea about where your groups are - it doesn't just present you with whatever groups it finds in the nnml source directory. For my purposes, I'd like a slightly simplified mail/news reader that was suspciciously similar (i.e. nearly identical in most ways) to gnus, but with the following additions (all mostly related to mail, and not all probably fixable via the backend). (please excuse any schemisms in the pseudo-code below) - it should be easy to move your groups around, archiving and unarchiving (tarring up, storing on tape, whatever), without confusing gnus. This means storing the mark info with the backend. If I delete an nnml directory from the filesystem, the next time I start up gnus, I'd just like to see it gone. If I untar an old one, I'd like to see gnus notice it. - it should be *very* hard to have an emacs crash totally hose all your state information (readness, group hierarchies, layout, etc.). This means storing the mark info with the backend *and* writing it frequently - this may mean *not* writing out a monolihic state file, not even one per backend group. - it should allow every article to be marked with an arbitrary number of "tags". Some of the tag names (perhaps all prefixed with "gnus:", like "gnus:unread") would be reserved for internal use, but others would be available for the user. - it should be easy to write code that will take actions based on the user tags. - it should be easy to write code that changes the "system" state of an article: (add-system-article-mark article 'gnus:unread) - it should have one clear policy with respect to marking articles read, and/or deleting them. - it should be *easy* to understand this policy, and to override it. I'd like to be able to do things like this and expect them to interact well with the rest of the system: (setq gnus-expire-check (lambda (article) (or (normal-system-expire-check article) (article-user-mark? article 'garbage) (article-user-mark? article 'spam)))) - it should be easy for the user to map over articles with code that makes it obvious what's going on: (gnus-group-map-all-articles backend "inbox" (lambda (article) (if (search-article-for "MONEY") (add-article-user-mark article 'spam)))) - it should handle very large groups efficiently (maybe even with an sql backend option). Perhaps gnus can already do this stuff and I just don't know it, but if not, anyone have any thoughts about how hard this would be to add? I've also wondered how hard it might be to turn much of the gnus code into a mail related emacs library. Gnus has a tremendous quantity of excellent mail related code, and it's stuff that's hard to get right. It would be really nice if this code were avaialbe for re-use so that if someone's just not quite happy with gnus, they could still use the library, create something that more closely suits their needs, and continue to contribute to the development of the common code. Thoughts? -- Rob Browning PGP=E80E0D04F521A094 532B97F5D64E3930