Subject: bug#60078: 30.0.50; Gnus: Can't remove groups of select methods that don't exist anymore

From: Jakub Ječmínek <[email-masked]>
Date: Tue, 14 May 2024 20:42:05 +0000

This whole issue sent me really deep, so thank you for sticking by.

"Eric Abrahamsen" <[email-masked]> writes:

> I think you're right about the definition of "foreign", and that there's
> a bug/misunderstanding in code like this, but this check isn't a
> complete fix because `gnus-group-secondary-p' looks up the group's
> method, and the whole reason we're running this code is that the group's
> method no longer exists. (The original/current code also has this
> issue.) If the method is actually gone, groups that used to belong to it
> will also be passed over.

Then it comes down to you as package maintainer to decide what bogus
group actually is, because current definition makes little sense to
me. For example, if the server is down and Gnus is not able to get
active info, all groups belonging to that server become bogus, which is
a little unfortunate.

> So I guess there's two scenarios to support: in the first, the server is
> still there but one or more groups are gone (someone's deleted an IMAP
> folder from the server) and in the second the server itself has been
> removed from the user's config files, and we're clearing out the old
> groups.

Both of these cases can be handled with simple (group-active group)
predicate. Do you have a clue why Lars wanted to handle foreign groups
separately? I've searched (ding) mailing list, old bug reports,
changelogs, commit messages, and everything else I could find but I
found nothing.

Thanks!

-- 
Kuba Ječmínek (http://kubajecminek.cz)