No Gnus doesn't like the obsolete spam syntax

No Gnus doesn't like the obsolete spam syntax

[Russ Allbery]

Just a quick note in case it saves someone else some time.

I used to have:

(custom-set-variables
 '(gnus-parameters
   '(("^nnml:spam\\..*"
      (spam-contents gnus-group-spam-classification-spam)
      (spam-process (gnus-group-spam-exit-processor-bogofilter
                     gnus-group-ham-exit-processor-bogofilter))))))

(with more gnus-parameters, but that's the relevant ones).  This no longer
works with No Gnus (version in the headers).  I'm not entirely sure why,
but following the manual's instructions and then fiddling a little to
figure out what they really mean, the following *does* work:

(custom-set-variables
 '(gnus-parameters
   '(("^nnml:spam\\..*"
      (spam-contents gnus-group-spam-classification-spam)
      (spam-process ((spam spam-use-bogofilter)
                     (ham spam-use-bogofilter)))))))

It took me a little bit to get the syntax right, since for some reason I
read the manual suggestion and thought it said to replace

    gnus-group-spam-exit-processor-bogofilter

with

    ('(spam spam-use-bogofilter))

literally.  That just silently fails with no error message, apparently due
to having one too many layers of parens.

(Yes, I know you can do this all inside customize.  I hate the interface
for customize and also prefer to have commented configurations so that I
can remember why I changed something, which means that I do a lot of
writing code based directly on the manual or using customize to generate a
first draft and then tweaking it.)

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: No Gnus doesn't like the obsolete spam syntax

[Ted Zlatanov]

On Tue, 09 Aug 2005, rra@stanford.edu wrote:

> Just a quick note in case it saves someone else some time.
> 
> I used to have:
> 
> (custom-set-variables
>  '(gnus-parameters
>    '(("^nnml:spam\\..*"
>       (spam-contents gnus-group-spam-classification-spam)
>       (spam-process (gnus-group-spam-exit-processor-bogofilter
>                      gnus-group-ham-exit-processor-bogofilter))))))
> 
> (with more gnus-parameters, but that's the relevant ones).  This no longer
> works with No Gnus (version in the headers).  I'm not entirely sure why,
> but following the manual's instructions and then fiddling a little to
> figure out what they really mean, the following *does* work:
> 
> (custom-set-variables
>  '(gnus-parameters
>    '(("^nnml:spam\\..*"
>       (spam-contents gnus-group-spam-classification-spam)
>       (spam-process ((spam spam-use-bogofilter)
>                      (ham spam-use-bogofilter)))))))
> 
> It took me a little bit to get the syntax right, since for some reason I
> read the manual suggestion and thought it said to replace
> 
>     gnus-group-spam-exit-processor-bogofilter
> 
> with
> 
>     ('(spam spam-use-bogofilter))
> 
> literally.  That just silently fails with no error message, apparently due
> to having one too many layers of parens.

Yeah...  I wasn't sure about changing to the new style of
configuration for exactly this reason - backwards compatibility.  I
think the pain is worth it, though, as the new format is much better
IMO.

Was the manual misleading in any way?  I'll be glad to fix it.

> (Yes, I know you can do this all inside customize.  I hate the interface
> for customize and also prefer to have commented configurations so that I
> can remember why I changed something, which means that I do a lot of
> writing code based directly on the manual or using customize to generate a
> first draft and then tweaking it.)

I'm ambivalent on this issue.  It's nice to customize, and for spam.el
stuff it's almost required, but on the other hand I like everything in
my gnus.el...  Of course, don't forget that Gnus has three ways to set
group variables, through gnus-parameters, individual global variables,
and group/topic parameters...  It's insane IMHO.  I would prefer to
pick one (group/topic parameters are best I think) and provide
conversion functions from the others to it.  But anyhow :)

Ted

Re: No Gnus doesn't like the obsolete spam syntax

[Russ Allbery]

Ted Zlatanov <tzz@lifelogs.com> writes:
> On Tue, 09 Aug 2005, rra@stanford.edu wrote:

>> It took me a little bit to get the syntax right, since for some reason I
>> read the manual suggestion and thought it said to replace

>>     gnus-group-spam-exit-processor-bogofilter

>> with

>>     ('(spam spam-use-bogofilter))

>> literally.  That just silently fails with no error message, apparently
>> due to having one too many layers of parens.

> Yeah...  I wasn't sure about changing to the new style of configuration
> for exactly this reason - backwards compatibility.  I think the pain is
> worth it, though, as the new format is much better IMO.

Yeah, I agree that the new format is better.

> Was the manual misleading in any way?  I'll be glad to fix it.

The only thing that was mildly misleading was this part:

     _WARNING_

     Instead of the obsolete
     `gnus-group-spam-exit-processor-bogofilter', it is recommended
     that you use `'(spam spam-use-bogofilter)'.  Everything will work
     the same way, we promise.

I *think* that leading ' isn't actually desirable, although I'm not
positive at this point.  It looks like my main issue may have already been
fixed, though, since I think at one point there was another level of
parens.

Also, the manual entry there implies that the old syntax will still work,
and it didn't appear to for me.

> Of course, don't forget that Gnus has three ways to set group variables,
> through gnus-parameters, individual global variables, and group/topic
> parameters...  It's insane IMHO.  I would prefer to pick one
> (group/topic parameters are best I think) and provide conversion
> functions from the others to it.  But anyhow :)

I do most everything through a combination of gnus-parameters and
individual global variables, largely because most of my rules apply to
whole classes of groups and editing properties on each of hundreds of
groups is pretty tedious.  I use all three, but the group parameters are
used for special cases and overrides.

(Topic parameters aren't useful as a grouping mechanism for these settings
for me since I use topics to organize groups along a completely different
axis.)

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: No Gnus doesn't like the obsolete spam syntax

[Ted Zlatanov]

On Tue, 20 Sep 2005, rra@stanford.edu wrote:

> The only thing that was mildly misleading was this part:
> 
>      _WARNING_
> 
>      Instead of the obsolete
>      `gnus-group-spam-exit-processor-bogofilter', it is recommended
>      that you use `'(spam spam-use-bogofilter)'.  Everything will work
>      the same way, we promise.
> 
> I *think* that leading ' isn't actually desirable, although I'm not
> positive at this point.  It looks like my main issue may have already been
> fixed, though, since I think at one point there was another level of
> parens.

OK.  I am sure now that providing backward compatibility was a bad
move - not only is it buggy, but it's confusing too!  I should have
had warnings if the old-style symbols were detected, that's all.

Anyhow, the manual entries have been corrected in CVS.  Thanks for
your help.

>> Of course, don't forget that Gnus has three ways to set group variables,
>> through gnus-parameters, individual global variables, and group/topic
>> parameters...  It's insane IMHO.  I would prefer to pick one
>> (group/topic parameters are best I think) and provide conversion
>> functions from the others to it.  But anyhow :)
> 
> I do most everything through a combination of gnus-parameters and
> individual global variables, largely because most of my rules apply to
> whole classes of groups and editing properties on each of hundreds of
> groups is pretty tedious.  I use all three, but the group parameters are
> used for special cases and overrides.
> 
> (Topic parameters aren't useful as a grouping mechanism for these settings
> for me since I use topics to organize groups along a completely different
> axis.)

That's fine, but note I'm saying there should be conversions :) What I
mean is, every time a group is added, deleted, or modified, or Gnus
starts up, all the gnus-parameters and global parameter variables will
get applied to the group/topic hierarchy.  They won't be "live"
anymore when modified directly without Customize, so users will have
to learn that fact, but then you don't have to look in three places
anymore to find the true value of a parameter.

Anyhow, I doubt this will be a popular route.  It seems we're doomed
to multiple configuration sources for the foreseeable future.

Ted