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

["Ted Zlatanov" <tzz@lifelogs.com>]

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