Re: More on the new nnimap

[Lars Magne Ingebrigtsen <larsi@gnus.org>]

James Cloos <cloos@jhcloos.com> writes:

> How do you feel about making LF vs CRLF configurable or dependant on the
> type of stream?

There's already code in there to do that, and the 'shell branch set the
variable to flip that before.  However, there were other problems
related to using a pty-based shell stuff.  But I can't recall why, and
the commit message only says that I switched to non-pty-based, but not
why.  *sigh*

Anybody remembers?

> The difference is that it is not an error if the group already exists,
> except only for the new nnimap.  So how about an nnimap-request-
> possibly-create-group?

But what you want to do is to subscribe Gnus to a group from a server,
right?  The function to do that is `gnus-subscribe-group'.

> (The overall startup time is now 90 min, and that is with 21 Gbps
> RAM throughput.)

Wow.

Anyway, there is no way in the IMAP protocol to ask "what are new
mailboxes since <DATE>", so the only way Gnus has to find new groups is
to issue a LIST, right?  (Well, or LSUB, which is kinda the same thing.)
So if you have this setup, then there's no way that Gnus can get
acceptable performance if you want auto-subscription of new IMAP groups
working.

Or am I missing something?

Can't you just alter your IMAP->pg thing to make LIST fast?  :-)  Gnus
just needs the mailbox names, and doesn't care about anything else.

> Oh, and the bug where an already-read article's contents show up in the
> next group is still there.  I had hoped that it were fixed by the patch
> you described as something like 'fixing backends which lack NOV', but
> I just got it again today.
>
> It only occurs for me the first time I open a given group, and only if
> I did not close are re-start the imapd before doing so.  I had gotten
> info the habit, when setting the level for new groups, of, for each new
> group, closing the server, opening the group, and reading at least one
> article.  Just to avoid mismatch.
>
> When the mismatch occurs, one must read a number of other articles and
> then go back to the failed one in order to see what should be there.

This is most bizarre.  Gnus requests articles from backends by issuing
first a SELECT, and then a UID FETCH.  I can't see any way for that to
fetch an article from the wrong group, unless there's something
fundamentally wrong in the sequence Gnus does these things, and I
haven't heard anything odd in the area before.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen