Re: regexp-based group parameters

[prj@po.cwru.edu (Paul Jarc)]

NAGY Andras <nagya@inf.elte.hu> writes:
> * Gnus functions could use a single interface to fetch group
> parameters based on both methods, without having to deal with regexp
> matching and stuff.

This is an important goal.

> * Users would be able to define every group parameter based on regexps
> as well, in addition to the group/topic method.

I'm not sure what you mean here.  But see below for my suggestion.

> * Group/topic parameters allow setting arbitrary variables, not only
> `strict' parameters.

I'm not sure this is a problem.  Your gnus-parameters doesn't seem to
address it, either.

> To demonstrate this: I cannot (but would like to) write the following
> in my .gnus:
...
> I think the example speaks for itself.  (Setting everything in one
> place, independetly of newsrc.eld and topic topology.)

Not bad, but I'm not especially fond of the regexp matching; my naming
scheme for my groups should not be determined by whether they have
similar parameters, any more than my topic hierarchy should be so
determined.

I'd like it if parameters were (or could be) stored in backends.
Backends can already use -request-update-info to correct Gnus's
parameters, so we just need a way for Gnus to notify the backend when
the user modifies the parameters.  (Then once all backends do this,
Gnus could stop redundantly storing parameters in newsrc.eld.)

Also, to provide for hierarchical inheritance, we could have a
parameter called, say, parameter-parent, whose value is a group.  Then
when trying to find the value of parameter foo, if the group doesn't
have a value for foo, you check the parent group, recursively,
stopping when you find a group that has foo, or one that has no
parent.  Dummy groups could be used to hold sets of parameters; real
groups would use the dummy as their parent.

Your suggestion (like mine) fails to cover the capability we have now
of putting a group into multiple topics, and using the parameters of
whichever topic the user entered through, but this seems like more
trouble than it's worth, especially in situations where there is no
"current" topic.

Thoughts?


paul