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:
>> NNimap does an lsub

LMI> Well, LIST, but it's kinda the same thing...

OK.  I guessed based on the reply from imapd.

>> at startup and still fails to subscribe new groups even though I set
>> (gnus-subscribe-newsgroup-method) for all "^nn.+:" groups.  If it is
>> going to list the groups, then it knows about all of them and should
>> honour gnus-subscribe-newsgroup-method and subscribe all new groups
>> via it.

LMI> What is your gnus-subscribe-newsgroup-method exactly? 

(add-hook 'gnus-startup-hook
	  '(lambda ()
	     (setq gnus-subscribe-newsgroup-method
		   '(lambda (newsgroup)
		      (if (string-match "^nn.+:" newsgroup)
			  (gnus-subscribe-alphabetically newsgroup))))))

The format must have come from a suggestion either here, in the manual
or on one of the other emacs lists.  It goes back too many years to remember.

>> C in the server buffer fails to close an nnimap server.  That needs to
>> work.  There are valid reasons to be able to close any server on demand.

LMI> Ok; implemented.

Thanks.

>> New since my last upgrade, I now get two imapd's.

LMI> If you get two connections, then Gnus thinks that there are two
LMI> different servers.  This usually means that you have different
LMI> variations in the method definitions -- one has one more slot set or
LMI> something. 

>> And they use a pipe rather than a pty as they used to.  Not using a
>> pts is a bug; separating stdout from stderr is imperative.  (It is
>> possible the last is an Emacs bug rather than a gnus bug; my emacs is
>> bzr trunk rev 101727.)

LMI> This is with the 'shell connection?  It just does a process-start...

That used to use a pty.  

Many imapds have at least the potential to write to stderr.  That screws
up the imap stream when stderr is muxed with stdout.

Oh.  Figured it out.  You have:

(defun nnimap-open-shell-stream (name buffer host port)
  (let ((process-connection-type nil))
...

process-connection-type has to be t or pty to use a pty.

>> gnus-group-make-group now tries to make the group on the imap server
>> rather than just make a group to access the existing group on the imap
>> server.

LMI> That's what it's always done, I think?

No.  That is new.

>> If the former is useful, then it should not be an error if the
>> group already exists on the server.

LMI> If you ask it to create a group, and it already exists on the server,
LMI> that sounds like a bug to me.

Creating the group, though, is to allow gnus access.

>> Rather than use F, which is *slow*, I have a script which accesses the
>> backend directly and writes out an .el file to add the new groups.  (The
>> backend knows which are new; IMAP not so much.)  That script writes
>> a series of sexps running (gnus-group-make-group) with suitable args.

LMI> Why is `F' slow?  Which backends take long to respond?

Getting the list of groups over imap takes minutes.  Even tens of
minutes.  Doing a single sql query to get the new groups taks less
than 10 ms, according to explain analyze.

(Ideally, of course, I'd skip the imap middleware and have an nn backend
which speaks sql.  But that is a /large/ project and the current setup
is only slow at startup and for things like finding new groups.