group splitting question...

group splitting question...

[Eric E Moore]

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


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....

Is there some reason it does this, other than the splits look neater
w/o the backend names?

-- 
Eric E. Moore

[-- Attachment #2: Type: application/pgp-signature, Size: 184 bytes --]

Re: group splitting question...

[Simon Josefsson]

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.  What exactly is your splitting configuration?

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

Re: group splitting question...

[Eric E Moore]

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

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

[-- Attachment #2: Type: application/pgp-signature, Size: 184 bytes --]

Re: group splitting question...

[Simon Josefsson]

Eric E Moore <e.e.moore@sheffield.ac.uk> writes:

> 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?

The feature isn't implemented.

>> 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".

If I understand correctly, I don't think there is any pre-defined
functionality for doing what you want -- mail cannot be split into
nnimap.  Nnimap can only split mail from one mailbox on the server
into other mailboxes on the same server.

> 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).

Yes.  Sadly, this is probably how it is intended to work.  Only the
group name is used for splitting, and those names are assumed to apply
to whatever backend that eventually receives mail.

>> 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

That function is hard coded for nnmail splitting, but nnimap's
splitter isn't based on nnmail.  That function doesn't really do any
splitting, simplified, it seems to only iterates over all group and
configures up nnmail-split-methods and then let the normal split code
take over.

To solve your problem, I think it is easiest to simply have all mail
moved into a nnimap group and then use the nnimap mail splitter to
split the mail the way you want.  You need to write a macro or
something that takes mail from your local spool (possibly via a nnml
group) and move it into the nnimap group.