The Agent vs. gnus-find-method-for-group (was: backporting bugfixes to the v5-10 branch)

[Andreas Seltenreich <andreas+ding@gate450.dyndns.org>]

Andreas Seltenreich writes:

> Btw, testing with the agent enabled revealed two places where
> g-f-m-f-g is called on groups after their prefix has been stripped,
> causing the native method to be returned.  I don't think this is
> intentional, is it?

I didn't dig very deep into this, and am far from understanding how
the agent does its magic, but nevertheless some updates:

> Debugger entered: ("g-f-m-f-g called on unknown group")
> [...]
>   gnus-find-method-for-group("mailings.pgsql.general")
>   gnus-agent-get-local("mailings.pgsql.general")
>   gnus-agent-possibly-alter-active("mailings.pgsql.general" (1 . 6325))
>   gnus-agent-regenerate-group("nnpg+lists:mailings.pgsql.general" nil)
>   gnus-agent-regenerate(nil)
>   call-interactively(gnus-agent-regenerate)
>   execute-extended-command(nil)
>   call-interactively(execute-extended-command)

ISTM this causes the agent to look for the group's data in the native
method's directory (via gnus-agent-load-local).

There seems to be provision for passing the method as separate
argument to gnus-agent-get-local to avoid a call to g-f-m-f-g on
prefix-stripped groups in both, v5-10 and trunk:

--8<---------------cut here---------------start------------->8---
2004-10-18  Kevin Greiner

	* gnus-agent.el [...]
        [...]
	(gnus-agent-get-local): Add optional parameters to avoid calling
	gnus-group-real-name and gnus-find-method-for-group.
--8<---------------cut here---------------end--------------->8---

Maybe gnus-command-method should be passed as a third argument in
gnus-agent-possibly-alter-active?

Curiously, I'm unable to observe any adverse effects when regenerating
groups or moving/copying articles, so maybe I'm missing something...

Thanks,
andreas