Re: More on the new nnimap

[James Cloos <cloos@jhcloos.com>]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

LMI> James Cloos <cloos@jhcloos.com> writes:
>> Not now (still on commit 43de9c6fe344).  It only (claimed to) subscribe(d)
>> one group which wasn't actually new.
>> 
>> The 29 new groups were ignored.

LMI> nnimap-request-newgroups returned nil, so it was ignored.  This might
LMI> work now...

Yes, as of ec5f4e48dc25 it works (at least at startup).

>> The equic of stty raw on the pty also will fix that.

LMI> Do you know how to do that?

The src tells me that emacs almost does it already.

That ptys work fine with imap.el suggests that not adding CRs when doing
shell would also work.

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

>> It never did that when I used nnmh, nor have I seen it with nnmaildir.

LMI> Reading the code, it looks like it does:

Yeah.  I commented based on experience rather than on the code....

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?

LMI> So you have (* 20 60 13) => 15600 IMAP groups?

I split debian-bugs, gentoo-bugs, gnome-bugs, gnome-commits into
per-package (and for bz, per-package/reason) groups.  that accounts for
a lot of groups.  (In fact, 14670 and counting, including the empty
groups -- akin to rec vs rec.humor.)  Then there are the rss2email
groups, mailing lists, per-vendor groups.

But mostly the first bunch I mentioned above.

And thanks to the pg backend, everything is super speedy, except LIST.
(And sorting the LIST results; emacs itself now takes about 2½ Tops —
most probably spent waiting for ram — to deal with the LIST results,
before it starts EXAMINing.)

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

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.

(I do not use agent for nnimap.)

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6