Ted Zlatanov <tzz@lifelogs.com> writes:
> On Thu, 20 Nov 2003, lorentey@elte.hu wrote:
>
>> I see.  But I don't think it is normal that spam-split (or some
>> other nil-returning function) would be at the end of the split
>> specification.
>
> That's never stopped anyone :)

You are right, of course. :-)

> Let me give you an example: gnus-use-ifile is guaranteed to return a
> group name.  So the user makes spam-split the last entry in the
> split rules.  Eventually the user decides to turn spam-use-ifile
> off.  It's not a farfetched scenario at all.

But if I understand it well, no message would be lost; they would just
reappear in the current group, and I think these users can easily fix
their configuration, or simply ignore the new respooling feature.
Adding a note to the documentation along the lines of 'to prevent
unexpected results, if you plan to use this feature, make sure that
your split rules are set up so that the last rule never returns nil'
would be enough, I guess.

(By the way: is it 'respool' or 'resplit'?  I don't know the correct
terminology.)

>> IMHO most of this (except infrequent the nil case) would be
>> eliminated by disabling spam-split.
>
> Well, try it with the current respool behavior and let's see how it
> works.  It may be that all this worrying was unnecessary.

Thank you for implementing this!  I appreciate your work.

I have played with it for a while, and after adding the
no-spam-split-during-respool thingy, I think it does exactly what I
need.

If you're interested, here is my change: (it's quite ugly, but works)