Re: Problems with 0.3.2

[Simon Josefsson <jas@pdc.kth.se>]

radford@robby.caltech.edu (Jim Radford) writes:

>  o Gnus wants a Lines header to put in the summary, but we can only
>    easily compute Chars.

There is a summary-line-format character %c that print the number of
characters in a message.  Unfortunely, this only works with NOV
headers right now, but I've submitted a patch to Gnus which will be in
Gnus 5.6.16 that make it work for HEAD headers also.

nnimap also requires some changes to fetch the RFC822.SIZE field and
tell Gnus about it -- it will be in nnimap v0.3.4 posted on the web
page later today.

You need to change your gnus-summary-line-format if you want to see
the size field, this is what I have in my .gnus (the '%6c' is the
relevant part):

(setq gnus-summary-line-format "%U%R%z%I%(%[%6c/%4L: %ub%-20,20n%]%) %s\n")

I guess one could add KB/MB/GB etc, but that's left as an exercise for
the reader. For now, anyway.

>  o Gnus wants highest and lowest article number, but we can only easily
>    compute the number of messages.

nnimap-request-list's slow method return highest/lowest article number
now.

But there is some problem in this area anyway.

1 I have a IMAP group with gnus-info-read=((3 . 16)) which is correct
2 I start Gnus, it says that I have 2 new articles in that folder 
	(namely, 1 and 2)
3 If I select that folder it (correctly) says "No unread news" since
	article 1 and 2 doesn't exist
4 Gnus then believes it has read article 1 and 2, hence 
	gnus-info-read=((1 . 16))
5 nnimap-request-update-info updates this to ((3 . 16)) again
6 goto 1

I have searched through all nnimap but I can't find any place that it
tells Gnus that article 1 and 2 should exist. Any ideas?

>  o Gnus has other information besides read, ticked, and replied that
>    would be usefull to keep on the server.  Any ideas on where to
>    store it?

IMAP support MUA-specific article marks, which we could use. Exactly
what information where you thinking about?

Folder specific information perhaps. I can't see any way of doing that
in IMAP.

>  o Ideally I'd like to store the equivalent of the newsrc on the IMAP
>    server (in a hidden group or message) so that complete remote
>    syncing is possible. 

I don't think Gnus ever uses .newsrc-data instead of current IMAP data
(by calling request-update-info all the time), so this shouldn't be a
problem?

If Gnus doesn't always call request-update-info before using
gnus-info-* values, which could be the case with my
always-2-unread-articles above, this is a problem, but then I think
it's a Gnus problem.

>  o Currently the only thing we "write" to the server is marks, we
>    never run EXPUNGE.  We should.

Yes, but I wouldn't want to enable that until everything else works
flawlessly.  I guess you agree since you haven't enabled that part..

> > Folder filtering is another story, one basicly has to re-write (or
> > steal as much as possible) the nnmail filtering stuff but for IMAP. A
> > clean implementation would do this in nnimap-request-scan. I.e go
> > through all articles in the INBOX and filter and move them to the
> > correct folder (IMAP or not IMAP).
> 
> I put this on the TODO list.

This is the first major thing I'll be doing when I have a nnimap that
doesn't give me backtraces when I use Gnus. I think this is already
the case with 0.3.3.

> The main problems I have had with this have been when I have had my
> nnimap server as my primary server.  When this is the case, you cannot
> subscribe for groups from the "server buffer".  The reason seems to be
> that Gnus always prepends the server name to the group you subscribe
> to in this case; this however should only be done for non-primary
> groups.

Ok. Let's solve that by not letting anyone using nnimap for a primary
server right now. :-)

/S