Re: convert from setq to customization

[Simon Josefsson <jas@extundo.com>]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Thu, 06 Mar 2003, jas@extundo.com wrote:
>> Ted Zlatanov <tzz@lifelogs.com> writes:
>
>>> For example, spam.el requires nnimap-split-download-body in
>>> nnimap.el to be set if a statistical filter is selected, so the
>>> whole message body is downloaded.
>> 
>> This crossed my mind as well... spam.el should not setq n-s-d-b.
>> 
>> Either spam.el should bind the variable temporarily, or if that
>> doesn't work, we can add a undocumented variable nnimap-using-spam
>> which spam.el can set instead.
>
> How about spam.el generating an error if n-s-d-b is nil and a
> statistical splitter function is selected?  What kind of error is
> reasonable, a showstopper (error) or a Gnus message?  I am not sure
> because this is not a critical problem, it only means that incoming
> spam may not be properly classified.

Yes, an error seems too much.  Using a separate, non-customized,
nnimap variable that spam.el can set seems like a better approach, and
this approach is used in similar situations already.  It would also
allow people to set n-s-d-b to override the spam.el decision, if they
wanted that.

> Also, can I set n-s-d-b in the middle of splitting, or does it have
> to be set at the beginning of the IMAP conversation with the server?

It is only used by n-request-scan, and it can be set and changed at
any point.

> If I could set it, I could ask the user if he wants to set it
> automatically, and then come back and resume splitting.  Hmm, but
> then the IMAP session might time out.

But you would need to remember the decision so it isn't asked every
time...  the solution above seems better, IMHO.