Simon Josefsson <jas@extundo.com> writes:

> Eric E Moore <e.e.moore@sheffield.ac.uk> writes:
>
>> Why does splitting on group parameters remove the backend name?  I
>> found this a little confusing, when I set up parameters to try and
>> migrate from nnml to nnimap (to make reading email from different
>> locations a bit easier), and instead of putting my mail in the nnimap
>> group that it was supposed to match, it put it in a new identically
>> named nnml group....
>
> You can't split across backends, so the backend name wouldn't serve
> any purpose.  

Why not?

> What exactly is your splitting configuration?

I have 2 machines.  "work" and "home".  I would like to be able, at
least temporarially, to get gnus to file emails read (from the mail
spool) on "work" to be filed in IMAP groups on an imap server running
on "home".  I have nnimap pointing to home in secondary selects (and
nnml in primary).  I have an nnimap group "INBOX.foo" with a
split-regexp group property that catches messages to a certain email
address.  When I read mail from the spool at work, instead of being
put in the group with the property (e.g. nnimap+home:INBOX.foo),
they're put in an nnml group with the same name (nnml:INBOX.foo),
which in addition to being not what I want, is wrong to boot
(nnml:INBOX.foo does not have that split-spec as a group property).

> Nnimap and nnmail doesn't share splitting code, except for the fancy
> nnimap splitting variable that defaults to the nnmail spitting
> variable contents.

but the group splitting code in gnus-group-split-fancy searches over
all groups, in all backends, to find groups that the message matches,
but then strips off the backend information.  Surely it should either: 

a) only scan groups it can actually deliver to by default
or 
b) be able to deliver to the groups it scans

-- 
Eric E. Moore