Gnus development mailing list
 help / color / mirror / Atom feed
From: Lars Magne Ingebrigtsen <larsi@gnus.org>
To: ding@gnus.org
Subject: Re: More on the new nnimap
Date: Mon, 04 Oct 2010 18:36:00 +0200	[thread overview]
Message-ID: <m3fwwldifj.fsf@quimbies.gnus.org> (raw)
In-Reply-To: <m3y6agcv2x.fsf@jhcloos.com>

James Cloos <cloos@jhcloos.com> writes:

> NNimap does an lsub

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

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

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

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

Ok; implemented.

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

If you get two connections, then Gnus thinks that there are two
different servers.  This usually means that you have different
variations in the method definitions -- one has one more slot set or
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.)

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

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

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

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

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

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

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

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




  reply	other threads:[~2010-10-04 16:36 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-02 18:23 James Cloos
2010-10-04 16:36 ` Lars Magne Ingebrigtsen [this message]
2010-10-04 18:02   ` James Cloos
2010-10-04 19:48     ` Lars Magne Ingebrigtsen
2010-10-04 21:14       ` James Cloos
2010-10-05 16:39         ` Lars Magne Ingebrigtsen
2010-10-05 22:01           ` Dan Christensen
2010-10-07 19:11             ` Lars Magne Ingebrigtsen
2010-10-08 15:47               ` James Cloos
2010-10-06  9:05           ` James Cloos
2010-10-07 19:22             ` Lars Magne Ingebrigtsen
2010-10-08 16:00               ` James Cloos
2010-10-09 16:06                 ` Lars Magne Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3fwwldifj.fsf@quimbies.gnus.org \
    --to=larsi@gnus.org \
    --cc=ding@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).