nnimap - not quite there yet?

nnimap - not quite there yet?

[Joe Casadonte]

Before I spend copious amounts of free-time trying to fix what I'm
about to rant about, perhaps someone could tell me if there are
already plans to fix these things.  Or possibly fixes are already in
Oort (though I downloaded it and grepped thru the Changelog quickly
and didn't see anything specifically on these issues).  My setup is a
little odd, and perhaps I need to change it, but until I do, I have
the following problems.

My setup: I have multiple accounts on multiple IMAP servers.
Specifically, 8 accounts on one IMAP server and one on another.  I
differentiate these accounts as being various virtual servers in my
gnus-secondary-select-methods list.

My problems:

1) Despite everything I've tried, mostly with levels, I cannot avoid
   having all accounts logged into at Gnus startup.  I only want two
   or three accounts checked, and I'll check the others once every
   couple of days.  Perhaps I need to define the virtual servers but
   make them inactive somehow, and then manually activate them from
   the server buffer?  Aside from not knowing how to do that off-hand,
   it seems a bit of a PITA.

2) Again, despite attempts to change the behavior (mostly with levels)
   I cannot avoid having nnimap check every folder when I do a
   gnus-group-get-new-news.  The folders don't /activate/, mind you, but
   I have to sit thru every one of them being checked.

3) For each virtual IMAP server, an imap process is launched and kept
   hanging around.  With 9 virtual servers, that's just too much.  It
   would be much better if there was one IMAP process that kept
   flipping back and forth.  Yeah, there's a lag with login and all,
   but I'd rather have that then multiple connections hanging around
   doing nothing.  One solution is to have a pool of IMAP connections,
   the limit to which could be configurable (1 for me, N for others).

4) As has been mentioned elsewhere in recent threads, nnimap (and all
   of Gnus for that matter) is not terribly fault tolerant.  If a
   server connection goes down, the connection needs to be severed
   manually before it can be reconnected.  Again, this is more of a
   general Gnus issue, I think, but nnimap seems a bit more stubborn
   then nntp.

Some of these things are OK from an IMAP standpoint, but I'm trying to
buy into the whole "mail is just strangely formatted news" idiom, and
these are some of the things holding me back.  Having said all of
that, I'd be more then happy to jump in and try to fix some of them,
being a firm believer in being a part of the solution (as well as the
problem).

Thanks for listening!

--
Regards,

joe
Joe Casadonte
jcasadonte@northbound-train.com

------------------------------------------------------------------------------
         Llama Fresh Farms => http://www.northbound-train.com
   Gay Media Resource List => http://www.northbound-train.com/gaymedia.html
            Perl for Win32 => http://www.northbound-train.com/perlwin32.html
               Emacs Stuff => http://www.northbound-train.com/emacs.html
          Music CD Trading => http://www.northbound-train.com/cdr.html
------------------------------------------------------------------------------
                       Live Free, that's the message!
------------------------------------------------------------------------------

Re: nnimap - not quite there yet?

[Kai Großjohann]

Joe Casadonte <jcasadonte@northbound-train.com> writes:

> 1) Despite everything I've tried, mostly with levels, I cannot avoid
>    having all accounts logged into at Gnus startup.  I only want two
>    or three accounts checked, and I'll check the others once every
>    couple of days.  Perhaps I need to define the virtual servers but
>    make them inactive somehow, and then manually activate them from
>    the server buffer?  Aside from not knowing how to do that off-hand,
>    it seems a bit of a PITA.

Hm.  I've got a foreign nntp server that I'm not checking, and that
works.  Maybe Gnus is trying to look for new groups on the nnimap
servers?  You could try to make them foreign servers, rather than
secondary.

A foreign server can be created via the server buffer, accessible via
^ from the Group buffer.  Secondary servers are secondary because
they're listed in gnus-secondary-select-methods.

Maybe you can create a server pointing to one of the existing accounts
and then you can see if you can prevent Gnus from checking that server
on startup.

> 2) Again, despite attempts to change the behavior (mostly with levels)
>    I cannot avoid having nnimap check every folder when I do a
>    gnus-group-get-new-news.  The folders don't /activate/, mind you, but
>    I have to sit thru every one of them being checked.

Did you kill the unwanted groups (with C-k)?

Not sure whether the previous suggestion works for this one, too.

> 3) For each virtual IMAP server, an imap process is launched and kept
>    hanging around.  With 9 virtual servers, that's just too much.  It
>    would be much better if there was one IMAP process that kept
>    flipping back and forth.  Yeah, there's a lag with login and all,
>    but I'd rather have that then multiple connections hanging around
>    doing nothing.  One solution is to have a pool of IMAP connections,
>    the limit to which could be configurable (1 for me, N for others).

Despite them thingies being listed in M-x list-processes RET, they're
just network connections.  No extra process needed for them.  (Unless
you connect to them via a shell command.)

Doing what you want would require a serious rewrite of the
infrastructure.

> 4) As has been mentioned elsewhere in recent threads, nnimap (and all
>    of Gnus for that matter) is not terribly fault tolerant.  If a
>    server connection goes down, the connection needs to be severed
>    manually before it can be reconnected.  Again, this is more of a
>    general Gnus issue, I think, but nnimap seems a bit more stubborn
>    then nntp.

Believe it or not, I never have those problems.  When the connection
goes down for some reason, Gnus brings it back up.  Other than a
slight delay, I don't notice anything.

Do you use a shell command to access your IMAP servers (ssh, say)?
That might be more problematic.

kai
-- 
~/.signature: No such file or directory

Re: nnimap - not quite there yet?

[Amos Gouaux]

>>>>> On 08 Aug 2001 16:29:29 -0400,
>>>>> Joe Casadonte <jcasadonte@northbound-train.com> (jc) writes:

jc> 1) Despite everything I've tried, mostly with levels, I cannot avoid
jc>    having all accounts logged into at Gnus startup.  I only want two
jc>    or three accounts checked, and I'll check the others once every

I do this to some extent.  I just have my primary inbox listed under
gnus-secondary-select-methods.  All the rest I've set up a foreign
groups under the server buffer (press ^ from the *Groups* buffer).

jc> 2) Again, despite attempts to change the behavior (mostly with levels)
jc>    I cannot avoid having nnimap check every folder when I do a
jc>    gnus-group-get-new-news.  The folders don't /activate/, mind you, but
jc>    I have to sit thru every one of them being checked.

This is from code that has been posted by others before, but here it
is again, probably poorly mangled.  ;-)

;;; This is used by gnus-demon-add-handler to check for
;;; new mail periodically.  I have my inbox set at level 1, 
;;; while all my favorite folders are at level 2.  In the
;;; Group buffer, the command `S l' can be used to
;;; set a group level.  This one is run every 5 minutes.
(defun gnus-demon-scan-mail-groups1 ()
  (save-window-excursion
    (when (gnus-alive-p)
      (save-excursion
        (set-buffer gnus-group-buffer)
        (gnus-group-get-new-news 1)))))

;;; I have this one run every 17min.
(defun gnus-demon-scan-mail-groups2 ()
  (save-window-excursion
    (when (gnus-alive-p)
      (save-excursion
        (set-buffer gnus-group-buffer)
        (gnus-group-get-new-news 2)))))

;;; Hook that does that vast majority of gnus customization.
;;; (I set this up long, long ago, and suspect there's a better
;;; way to do this now...)
(add-hook 
 'gnus-startup-hook
 (function
  (lambda ()
    ;; Check for new mail every 5 minutes after being idle for 5 minute.
    (gnus-demon-add-handler 'gnus-demon-scan-mail-groups1 5 5)
    ;; This check is for "favorite" folders that aren't quite as important.
    (gnus-demon-add-handler 'gnus-demon-scan-mail-groups2 17 17)
    ;; .... lots of other junk...
    )))

So, I set my inbox at level one.  Folders that receive new mail that
I want to keep a close eye on at level two.  My folders that I don't
want to be polled at startup at level 4.  Newsgroups and stuff at
level 3 (the default).  When I want to just check my inbox, in the
*Group* buffer I just do `1 g'.  If I want to check some of the
shared folders, `2 g'.  I only use plain `g' if I want to check
everything (at level 3 and above).

jc> 3) For each virtual IMAP server, an imap process is launched and kept
jc>    hanging around.  With 9 virtual servers, that's just too much.  It

I would probably just go into the server buffer and close the
sessions I didn't need.

-- 
Amos

Re: nnimap - not quite there yet?

[Peter Weiss, Sun Microsystems, Germany]

>>>>> On 08 Aug 2001 16:29:29 -0400, Joe Casadonte <jcasadonte@northbound-train.com> said:

Joe> [...]

Joe> 2) Again, despite attempts to change the behavior (mostly with levels)
Joe>    I cannot avoid having nnimap check every folder when I do a
Joe>    gnus-group-get-new-news.  The folders don't /activate/, mind you, but
Joe>    I have to sit thru every one of them being checked.

Joe> [...]

Hello Joe,

    I've achieved this by configuring a key like this

        (define-key gnus-group-mode-map [f12]
          '(lambda () (interactive) (gnus-group-get-new-news 1)))

    in the hook of gnus-started-hook.

     Hth -- Peter

-- 
Consultant der CLASS AG   http://www.class.de
Technical Services
mobil +49 (0) 172/837 91 25
mailto:Peter.Weiss@class.de

Re: nnimap - not quite there yet?

[Joe Casadonte]

On Thu, 09 Aug 2001, Kai Großjohann wrote:

> Joe Casadonte <jcasadonte@northbound-train.com> writes:
>> 1) Despite everything I've tried, mostly with levels, I cannot
>>    avoid having all accounts logged into at Gnus startup.  I only
>>    want two or three accounts checked, and I'll check the others
>>    once every couple of days.  Perhaps I need to define the virtual
>>    servers but make them inactive somehow, and then manually
>>    activate them from the server buffer?  Aside from not knowing
>>    how to do that off-hand, it seems a bit of a PITA.
>
> Hm.  I've got a foreign nntp server that I'm not checking, and that
> works.  Maybe Gnus is trying to look for new groups on the nnimap
> servers?  You could try to make them foreign servers, rather than
> secondary.

I can't seem to get this to work.  How do I specify the .authinfo file
to use on a foreign server?  I can do this with the secondary server
definition.  Is there such a thing as Server Parameters (analogous to
Group Parameters)?  I couldn't find anything in the info file.

> A foreign server can be created via the server buffer, accessible
> via ^ from the Group buffer.  Secondary servers are secondary
> because they're listed in gnus-secondary-select-methods.

What is the real difference between a foreign & secondary server?
Just how you define it?  And maybe the fact that foreign
servers/groups are not checked until explicitly asked?

>> 2) Again, despite attempts to change the behavior (mostly with
>>    levels) I cannot avoid having nnimap check every folder when I
>>    do a gnus-group-get-new-news.  The folders don't /activate/,
>>    mind you, but I have to sit thru every one of them being
>>    checked.
>
> Did you kill the unwanted groups (with C-k)?

That removed it entirely :(

I just want to have it not be activated until I ask for a certain
level to be activated.  With nntp, I can have a group at a certain
level, say 3, and not have it be queried or even listed, until I asked
for it specifically.

Example: I added an nntp group and set the level to 3.  My
gnus-activate-level is set to 1.  When I run gnus-group-get-new-news
this new group does not get queried.  That's what I'd like to have
happen with my lower-level IMAP folders.

> Despite them thingies being listed in M-x list-processes RET,
> they're just network connections.  No extra process needed for them.
> (Unless you connect to them via a shell command.)

Bingo!  I connect thru an SSH port forwarding tunnel.

> Doing what you want would require a serious rewrite of the
> infrastructure.

I would imagine so :(

>> 4) As has been mentioned elsewhere in recent threads, nnimap (and
>>    all of Gnus for that matter) is not terribly fault tolerant.  If
>>    a server connection goes down, the connection needs to be
>>    severed manually before it can be reconnected.  Again, this is
>>    more of a general Gnus issue, I think, but nnimap seems a bit
>>    more stubborn then nntp.
>
> Believe it or not, I never have those problems.  When the connection
> goes down for some reason, Gnus brings it back up.  Other than a
> slight delay, I don't notice anything.
>
> Do you use a shell command to access your IMAP servers (ssh, say)?
> That might be more problematic.

Bingo again.  So, not knowing enough about SSH, this is more an SSH
issue then a Gnus/nnimap issue?

Thanks for the help so far!

--
Regards,

joe
Joe Casadonte
jcasadonte@northbound-train.com

------------------------------------------------------------------------------
         Llama Fresh Farms => http://www.northbound-train.com
   Gay Media Resource List => http://www.northbound-train.com/gaymedia.html
            Perl for Win32 => http://www.northbound-train.com/perlwin32.html
               Emacs Stuff => http://www.northbound-train.com/emacs.html
          Music CD Trading => http://www.northbound-train.com/cdr.html
------------------------------------------------------------------------------
                       Live Free, that's the message!
------------------------------------------------------------------------------

Re: nnimap - not quite there yet?

[Joe Casadonte]

On 09 Aug 2001, Peter Weiss wrote:

>     I've achieved this by configuring a key like this
>
>         (define-key gnus-group-mode-map [f12]
>           '(lambda () (interactive) (gnus-group-get-new-news 1)))
>
>     in the hook of gnus-started-hook.

Aha -- this works!  But why is this different then having my
gnus-activate-level set to 1?  Does nnimap (or Gnus proper) ignore
this variable unless specified explicitly in the call to
gnus-group-get-new-news?  Or am I attributing more power to
gnus-activate-level then it deserves?  Hmmm...

> gnus-activate-level's value is
> 1
>
> Documentation:
> *Groups higher than this level won't be activated on startup.
> Setting this variable to something low might save lots of time when
> you have many groups that you aren't interested in.

I guess thought this affected subsequent requests, too.  My bad....

Though, I swear this is not honored on startup, either.  At least by
nnimap (I'm not sure how to check nntp).

Thanks!

--
Regards,

joe
Joe Casadonte
jcasadonte@northbound-train.com

------------------------------------------------------------------------------
         Llama Fresh Farms => http://www.northbound-train.com
   Gay Media Resource List => http://www.northbound-train.com/gaymedia.html
            Perl for Win32 => http://www.northbound-train.com/perlwin32.html
               Emacs Stuff => http://www.northbound-train.com/emacs.html
          Music CD Trading => http://www.northbound-train.com/cdr.html
------------------------------------------------------------------------------
                       Live Free, that's the message!
------------------------------------------------------------------------------

Re: nnimap - not quite there yet?

[Joe Casadonte]

On 09 Aug 2001, Joe Casadonte wrote:

>
> On 09 Aug 2001, Peter Weiss wrote:
>
>>     I've achieved this by configuring a key like this
>>
>>         (define-key gnus-group-mode-map [f12]
>>           '(lambda () (interactive) (gnus-group-get-new-news 1)))
>>
>>     in the hook of gnus-started-hook.

Taking that one step further (as I am wont to do), I put the following
in my ~/.gnus:

(defadvice gnus-group-get-new-news (around gnus-group-get-new-news-with-default-level act)
  "Calls gnus-group-get-new-news with a default level if none provided"
  (if (not arg)
	  (setq arg gnus-activate-level))
  ad-do-it)

*Now* it works like I thought it should.... :)

>> gnus-activate-level's value is
>> 1
>>
>> Documentation:
>> *Groups higher than this level won't be activated on startup.
>> Setting this variable to something low might save lots of time when
>> you have many groups that you aren't interested in.
>
> I guess thought this affected subsequent requests, too.  My bad....
>
> Though, I swear this is not honored on startup, either.  At least by
> nnimap (I'm not sure how to check nntp).

I looked again, and neither this variable nor my above advice change
the fact that all of my IMAP groups are "checked" on startup.  I'm not
100% sure what "checked" actually means; it just takes time.

--
Regards,

joe
Joe Casadonte
jcasadonte@northbound-train.com

------------------------------------------------------------------------------
         Llama Fresh Farms => http://www.northbound-train.com
   Gay Media Resource List => http://www.northbound-train.com/gaymedia.html
            Perl for Win32 => http://www.northbound-train.com/perlwin32.html
               Emacs Stuff => http://www.northbound-train.com/emacs.html
          Music CD Trading => http://www.northbound-train.com/cdr.html
------------------------------------------------------------------------------
                       Live Free, that's the message!
------------------------------------------------------------------------------

Re: nnimap - not quite there yet?

[Kai Großjohann]

Joe Casadonte <jcasadonte@northbound-train.com> writes:

> On Thu, 09 Aug 2001, Kai Großjohann wrote:
>
>> Joe Casadonte <jcasadonte@northbound-train.com> writes:
>>> 1) Despite everything I've tried, mostly with levels, I cannot
>>>    avoid having all accounts logged into at Gnus startup.  I only
>>>    want two or three accounts checked, and I'll check the others
>>>    once every couple of days.  Perhaps I need to define the virtual
>>>    servers but make them inactive somehow, and then manually
>>>    activate them from the server buffer?  Aside from not knowing
>>>    how to do that off-hand, it seems a bit of a PITA.
>>
>> Hm.  I've got a foreign nntp server that I'm not checking, and that
>> works.  Maybe Gnus is trying to look for new groups on the nnimap
>> servers?  You could try to make them foreign servers, rather than
>> secondary.
>
> I can't seem to get this to work.  How do I specify the .authinfo file
> to use on a foreign server?  I can do this with the secondary server
> definition.  Is there such a thing as Server Parameters (analogous to
> Group Parameters)?  I couldn't find anything in the info file.

You can use one .authinfo file for many servers.  Put the server name
in the `machine foo' statement.  Gnus ought to accept the server and
the machine name there, but there have been a couple of changes in
that area, so I'm not sure which versions do what.

So if you have (nnimap "blarfl" (nnimap-address "frumple") ...) then
it should work to have `machine blarfl' lines.

>> A foreign server can be created via the server buffer, accessible
>> via ^ from the Group buffer.  Secondary servers are secondary
>> because they're listed in gnus-secondary-select-methods.
>
> What is the real difference between a foreign & secondary server?
> Just how you define it?  And maybe the fact that foreign
> servers/groups are not checked until explicitly asked?

Gnus recognizes a secondary server by its presence in
gnus-secondary-select-methods.  The treatment of a secondary server
differs from a foreign server in that Gnus checks for new groups on
secondary servers, but not on foreign ones.

>>> 2) Again, despite attempts to change the behavior (mostly with
>>>    levels) I cannot avoid having nnimap check every folder when I
>>>    do a gnus-group-get-new-news.  The folders don't /activate/,
>>>    mind you, but I have to sit thru every one of them being
>>>    checked.
>>
>> Did you kill the unwanted groups (with C-k)?
>
> That removed it entirely :(

Do you use topics?  Maybe that group appears in two topics?  This has
happened to me before.  Usually, I can make it go away by moving the
group from one topic to the other with `T m'.  If that fails, you
might have to manually edit .newsrc.eld (the gnus-topic-topology
line).  But be careful!

> I just want to have it not be activated until I ask for a certain
> level to be activated.  With nntp, I can have a group at a certain
> level, say 3, and not have it be queried or even listed, until I asked
> for it specifically.
>
> Example: I added an nntp group and set the level to 3.  My
> gnus-activate-level is set to 1.  When I run gnus-group-get-new-news
> this new group does not get queried.  That's what I'd like to have
> happen with my lower-level IMAP folders.

It's what should happen automatically.  If it doesn't happen, I think
that's a bug in nnimap.

Simon?

>> Despite them thingies being listed in M-x list-processes RET,
>> they're just network connections.  No extra process needed for them.
>> (Unless you connect to them via a shell command.)
>
> Bingo!  I connect thru an SSH port forwarding tunnel.

Nasty you, withholding information from us... ;-)

>> Doing what you want would require a serious rewrite of the
>> infrastructure.
>
> I would imagine so :(
>
>>> 4) As has been mentioned elsewhere in recent threads, nnimap (and
>>>    all of Gnus for that matter) is not terribly fault tolerant.  If
>>>    a server connection goes down, the connection needs to be
>>>    severed manually before it can be reconnected.  Again, this is
>>>    more of a general Gnus issue, I think, but nnimap seems a bit
>>>    more stubborn then nntp.
>>
>> Believe it or not, I never have those problems.  When the connection
>> goes down for some reason, Gnus brings it back up.  Other than a
>> slight delay, I don't notice anything.
>>
>> Do you use a shell command to access your IMAP servers (ssh, say)?
>> That might be more problematic.
>
> Bingo again.  So, not knowing enough about SSH, this is more an SSH
> issue then a Gnus/nnimap issue?

Hm.  One idea might be to use ssh port forwarding.  Maybe that helps.
For example, I run ssh like this:

ssh -f -L 10119:quimby.gnus.org:119 bonny -l grossjoh sleep 3600

This means that `telnet localhost 10119' gives me a connection to
quimby.gnus.org which goes through bonny.  Ie, the connection from
localhost to bonny is encrypted via ssh, and the connection from bonny
to quimby.gnus.org is in the clear, as required by nntp.  This port
forwarding is alive until the command (sleep 3600) terminates.

Of course, the `sleep 3600' part has a high kludge factor.  Not sure
what to do about that.  Also, you'd have to arrange for Gnus to start
this on demand.

There is also an -R option for ssh, which I've never understood.


But I think that Gnus should provide a feature to check whether the
connection to the remote end has gone down.  The idea is like this:
Gnus records the time when it sends a command to the remote host.  And
before sending a command, it looks how much time has elapsed since the
last command.  If that was more than, say, N seconds, Gnus sends a
no-op command and looks carefully whether the remote end replies as it
should.  If the remote end doesn't reply, Gnus takes the connection
down and tries again.

kai
-- 
~/.signature: No such file or directory

Re: nnimap - not quite there yet?

[Paul Jarc]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> Gnus recognizes a secondary server by its presence in
> gnus-secondary-select-methods.  The treatment of a secondary server
> differs from a foreign server in that Gnus checks for new groups on
> secondary servers, but not on foreign ones.

WIBNI this behavior could be configured independently of how the
server was created?

>> Example: I added an nntp group and set the level to 3.  My
>> gnus-activate-level is set to 1.  When I run gnus-group-get-new-news
>> this new group does not get queried.  That's what I'd like to have
>> happen with my lower-level IMAP folders.
> 
> It's what should happen automatically.  If it doesn't happen, I think
> that's a bug in nnimap.

Backends don't know anything about levels.  Well, nnfoo-update-info
has access to a group's level/rank, but that doesn't seem relevant
here, and I imagine nnimap doesn't touch it anyway.

> ssh -f -L 10119:quimby.gnus.org:119 bonny -l grossjoh sleep 3600
...
> There is also an -R option for ssh, which I've never understood.

It's like -L, but backwards.  It connects to the ssh server and starts
listening to a port over there.  When someone connects to that port on
the ssh server, the connection is forwarded over the ssh connection
and hooked up to a new connection to a local port.


paul

Re: nnimap - not quite there yet?

[Kai Großjohann]

prj@po.cwru.edu (Paul Jarc) writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> > Gnus recognizes a secondary server by its presence in
>> gnus-secondary-select-methods.  The treatment of a secondary server
>> differs from a foreign server in that Gnus checks for new groups on
>> secondary servers, but not on foreign ones.
>
> WIBNI this behavior could be configured independently of how the
> server was created?

You can go to the server buffer and create a server nntp:foo.  Then
you can do (add-to-list 'gnus-secondary-select-methods "foo") to make
it secondary.

Is this what you want?

I wish this feature would use server names in the style of "nntp:foo",
like the rest of Gnus.  Oh, well...

>>> Example: I added an nntp group and set the level to 3.  My
>>> gnus-activate-level is set to 1.  When I run gnus-group-get-new-news
>>> this new group does not get queried.  That's what I'd like to have
>>> happen with my lower-level IMAP folders.
>> 
>> It's what should happen automatically.  If it doesn't happen, I think
>> that's a bug in nnimap.
>
> Backends don't know anything about levels.  Well, nnfoo-update-info
> has access to a group's level/rank, but that doesn't seem relevant
> here, and I imagine nnimap doesn't touch it anyway.

Hm.  Hmmm...

kai
-- 
~/.signature: No such file or directory

Re: nnimap - not quite there yet?

[Simon Josefsson]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

>> Example: I added an nntp group and set the level to 3.  My
>> gnus-activate-level is set to 1.  When I run gnus-group-get-new-news
>> this new group does not get queried.  That's what I'd like to have
>> happen with my lower-level IMAP folders.
>
> It's what should happen automatically.  If it doesn't happen, I think
> that's a bug in nnimap.

I think it's simply that checking active info is fast for nntp and
slow for nnimap, so noone has noticed this before -- from
`gnus-group-get-new-news':

    (if (and gnus-read-active-file (not arg))
	(progn
	  (gnus-read-active-file)
	  (gnus-get-unread-articles arg))
      (let ((gnus-read-active-file (if arg nil gnus-read-active-file)))
	(gnus-get-unread-articles arg)))
    (gnus-run-hooks 'gnus-after-getting-new-news-hook)

so unless you call `g' with a prefix, it will read the active files.
It seems as if it's only `gnus-get-unread-articles' that check the
active level, but then it's too late (the active file was already
read).

This seems to be consistent with how group levels work for me, `1 g'
etc works, but setting `gnus-activate-level' to 1 does not.

I guess group levels should be used in `gnus-read-active-file*'.  Ok,
patch below.  Please try.

>>>> 4) As has been mentioned elsewhere in recent threads, nnimap (and
>>>>    all of Gnus for that matter) is not terribly fault tolerant.  If
>>>>    a server connection goes down, the connection needs to be
>>>>    severed manually before it can be reconnected.  Again, this is
>>>>    more of a general Gnus issue, I think, but nnimap seems a bit
>>>>    more stubborn then nntp.
>>>
>>> Believe it or not, I never have those problems.  When the connection
>>> goes down for some reason, Gnus brings it back up.  Other than a
>>> slight delay, I don't notice anything.
>>>
>>> Do you use a shell command to access your IMAP servers (ssh, say)?
>>> That might be more problematic.
>>
>> Bingo again.  So, not knowing enough about SSH, this is more an SSH
>> issue then a Gnus/nnimap issue?
>
> Hm.  One idea might be to use ssh port forwarding.  Maybe that helps.
> For example, I run ssh like this:
>
> ssh -f -L 10119:quimby.gnus.org:119 bonny -l grossjoh sleep 3600
>
> This means that `telnet localhost 10119' gives me a connection to
> quimby.gnus.org which goes through bonny.  Ie, the connection from
> localhost to bonny is encrypted via ssh, and the connection from bonny
> to quimby.gnus.org is in the clear, as required by nntp.  This port
> forwarding is alive until the command (sleep 3600) terminates.
>
> Of course, the `sleep 3600' part has a high kludge factor.  Not sure
> what to do about that.  Also, you'd have to arrange for Gnus to start
> this on demand.
>
> There is also an -R option for ssh, which I've never understood.
>
> But I think that Gnus should provide a feature to check whether the
> connection to the remote end has gone down.  The idea is like this:
> Gnus records the time when it sends a command to the remote host.  And
> before sending a command, it looks how much time has elapsed since the
> last command.  If that was more than, say, N seconds, Gnus sends a
> no-op command and looks carefully whether the remote end replies as it
> should.  If the remote end doesn't reply, Gnus takes the connection
> down and tries again.

I've committed an improvement to the network checking, it should
actually work for all native emacs processes now.

I don't think emacs can distinguish between a dead ssh connection or a
live one if it is invoked in a subshell, but ssh port forwards is ok.

--- gnus-start.el.~6.27.~	Fri Aug 17 17:34:19 2001
+++ gnus-start.el	Fri Aug 17 21:18:30 2001
@@ -1821,16 +1821,34 @@
        ((and (eq gnus-read-active-file 'some)
 	     (gnus-check-backend-function 'retrieve-groups (car method))
 	     (not force))
-	(let ((newsrc (cdr gnus-newsrc-alist))
+	(let* ((newsrc (cdr gnus-newsrc-alist))
 	      (gmethod (gnus-server-get-method nil method))
-	      groups info)
+	       groups info
+	       (foreignp (and gmethod
+			     (not (gnus-native-method-p gmethod))
+			     (not (gnus-secondary-method-p method))))
+	       (level (or gnus-activate-level (1+ gnus-level-subscribed)))
+	       (foreign-level
+		(min
+		 (cond ((and gnus-activate-foreign-newsgroups
+			     (not (numberp gnus-activate-foreign-newsgroups)))
+			(1+ gnus-level-subscribed))
+		       ((numberp gnus-activate-foreign-newsgroups)
+			gnus-activate-foreign-newsgroups)
+		       (t 0))
+		 level)))
 	  (while (setq info (pop newsrc))
-	    (when (inline
+	    (when (and
+		   ;; check level on group
+		   (<= (gnus-info-level info) (if foreignp
+						  foreign-level
+						level))
+		   (inline
 		    (gnus-server-equal
 		     (inline
 		       (gnus-find-method-for-group
 			(gnus-info-group info) info))
-		     gmethod))
+		      gmethod)))
 	      (push (gnus-group-real-name (gnus-info-group info))
 		    groups)))
 	  (gnus-read-active-file-2 groups method)))