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

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Bjørn Mork <bjorn@mork.no> writes:

> On July 6, 2015 4:45:46 AM CEST, Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
>>Bjørn Mork <bjorn@mork.no> writes:
>>
>>> The recent nnimap speedups introduced a couple of regressions wrt
>>> new and empty nnimap groups. This prevents Gnus from creating new
>>> IMAP groups.
>>>
>>> These two patches fix the problems for me, but are created in the
>>> way I usually do lisp: by mindless trial and error until emacs
>>> stops complaining. I.e., there might be much better ways to fix
>>> this...
>>>
>>> Anyway: Works For Me (tm)
>>>
>>>
>>> Bjørn Mork (2):
>>>   nnimap.el (nnimap-request-group): don't make nil into a list
>>>   nnimap.el (nnimap-request-group): group could be empty
>>>
>>>  lisp/nnimap.el | 3 ++-
>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>>Hi Bjørn,
>>
>>I'm guessing you only see this when you move a message from one group
>>into a non-existent group, and you're prompted to create the new group,
>>and it gives you an error. Is that right?
>>
>>The group actually is created, it just gives an error when it's
>>re-selected. That's because the move/copy process doesn't automatically
>>subscribe to the group and register it with Gnus: if you go into the
>>*Server* buffer and open the group list for the server in question,
>>you'll see the new group there, unsubscribed.
>
> Yes, that's the typical situation where I see this. I didn't realise that the group isn't immediately subscribed to.
>
> Btw, does this mean that copying to any unsubscribed group will fail,
> or am I misunderstanding? If not, then that doesn't seem right. I do
> have a couple of use cases where it makes sense to move or copy into
> groups which I'm not interested in subscribing to.

I wasn't quite clear about the difference between subscribed and
"registered". You can copy into unsubscribed groups without any trouble.
"Registered" is a term I made up just to say that Gnus knows about the
group and is keeping track of attributes for it -- this ought to be the
case no matter what. My proposed solution would both register the group,
and subscribe it. An alternative would be to register the group and
*not* subscribe it, but given that it's got to be one or the other, I'd
lean towards subscribing.

What do you think?

>>My feeling is that groups which are created as part of the article
>>move/copy process should be automatically subscribed to, and registered
>>with Gnus (ie entered into gnus-newsrc-hashtb). That would solve this
>>problem, and also seems like the Right Thing to Do.
>>
>>Does anyone have any opinions on this? I'll work up a patch, if not.
>
> Sounds perfect to me. Thanks
>
>
> Bjørn