Re: "Fixing up" gnus - (how hard is this?).

[prj@po.cwru.edu (Paul Jarc)]

Rob Browning <rlb@cs.utexas.edu> writes:
> 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,

Backends can do this.  If all backends were made to do this, Gnus
wouldn't have to duplicate the information in newsrc.eld, and
nn*-request-set-info could perhaps be discarded in favor of
-get-article-marks, -get-marked-articles, etc.

> 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.

I think backends can also tackle this problem.  I intend to do so for
nnmaildir.

>   - 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.

nnmaildir writes its state file frequently, but it is one monolithic
file per group.  I may move to some form of journaling, but I've got
other changes to get to first.

>   - it should allow every article to be marked with an arbitrary
>     number of "tags".

User-defined, you mean?  That would be useful indeed.  Obviously, it
requires cooperation from Gnus, though.

> I've also wondered how hard it might be to turn much of the gnus code
> into a mail related emacs library.

That would be good.  Gnus, and user applications in general, ought to
consist of largely application-independant, reusable code, along with
some UI-specific code and (user-redefinable, of course) bindings to
that UI code.


paul