Re: regexp-based group parameters

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

ShengHuo ZHU <zsh@cs.rochester.edu> writes:
> prj@po.cwru.edu (Paul Jarc) writes:
> > > * 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.
> 
> As to group variables, it is.

How so?

> > 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.)
> 
> Using -request-update-info is another issue.

What do you mean?

> > Also, to provide for hierarchical inheritance, we could have a
> > parameter called, say, parameter-parent, whose value is a group. [...]
> 
> I don't like this idea. Regexp scheme is much clearer and easier to
> maintain.

But it also means that I can't deal with group names and parameters as
the separate entities they are.  If I want two groups to share a set
of parameters, I'm *forced* to either name them similarly, or else use
an ugly, *less* maintainable regexp to identify them.

> > 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.
> 
> This is the weakness of topics implementation.

Right.  But parameter-parents would be an *ordered* list of parents,
and unrelated to topics, so there'd be no ambiguity.


paul