Re: [PATCH 0/2] two minor fixes for new/empty nnimap group handling

[Eric Abrahamsen <eric@ericabrahamsen.net>]

[-- Attachment #1: Type: text/plain, Size: 2540 bytes --]

Dan Christensen <jdc@uwo.ca> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> I pushed a small change to `nnimap-request-group' yesterday that would
>> have prevented the first patch from applying cleanly -- sorry, I should
>> have mentioned you'd need to pull again first.
>
> No problem!
>
>> I thought my changes to the group creation process would have ensured
>> that all new groups had an "active" entry, but I guess not.
>>
>> I'd like to take one more whack at this, and then I'm going to give up
>> and just put Bjørn's guard in. Would you mind removing Bjørn's patches,
>> pulling once more, and trying these two?
>
> I just tried your latest patches against the latest git version.  As
> before, the problem with info being nil is handled, but active is still
> nil and I get the backtrace below.  If I add Bjørn's line
>
> +	(or active (setq active (cons 0 0)))
>
> then the error goes away, but Gnus thinks that the group is empty
> (not surprisingly), so this isn't really a solution.
>
> I only update Gnus periodically.  I had no trouble with nnmairix 
> with the 2014/10/10 version, but when I next updated on 2015/5/4
> the problem started.  Would it be helpful to bisect?  Based on
> "git log nnimap.el", there aren't many relevant changes, and the
> ones most likely responsible are (from newer to older):
>
> commit 10c00cefb79ea94c49a659b1f063218152e9b379
> commit 04550947fe524054fdc5626ff7b342baca0c18d9
> commit 1b4d1bd1ca7a32d8f9cb7c1ffe02af08f2c4b2c6
> commit 062698a34df9fd679229f7dea14cfaaf408f87de
> commit c2b17919646859aef0e1d329e052dadbbf042eca
> commit 447c56af7cb2afac14a0f3ed23f85d907c443a5d
>
> 447c5 looks especially relevant, but seems to have been buggy since
> later ones made fixes.
>
> Could nnmairix be adjusted to make an extra call at some point to
> activate the appropriate group?  Maybe it needs to call
> nnimap-request-group-scan instead of nnimap-request-group, now that
> 447c5 changed the behaviour of the latter?

I think this is probably the right solution. I'm still convinced that
nnimap should do something in the group creation process to register the
group with Gnus, but you're right that your problem is likely a direct
result of "request-group" getting split into "request-group" and
"request-group-scan", and nnmairix not being edited to follow.

I'm a little bit out of my depth here, but give this patch a whirl and
see how it goes.

I'm trying to set up mairix so I can test this myself, but am having
difficulty just making it do the basics...

Eric


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: nnmairix-create-group.patch --]
[-- Type: text/x-diff, Size: 634 bytes --]

diff --git a/lisp/nnmairix.el b/lisp/nnmairix.el
index 96b40e5..693d3ee 100644
--- a/lisp/nnmairix.el
+++ b/lisp/nnmairix.el
@@ -534,6 +534,9 @@ Other back ends might or might not work.")
 		   "request-group" groupname nnmairix-backend-server)))
     (nnmairix-call-backend
      "request-create-group" groupname nnmairix-backend-server)
+    (when (eq nnmairix-backend 'nnimap)
+      (nnmairix-call-backend
+       "request-group-scan" groupname nnmairix-backend-server))
     (gnus-group-add-parameter qualgroup '(folder . nil))
     (when nnmairix-allowfast-default
       (gnus-group-add-parameter qualgroup '(allow-fast . t)))