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:
> > 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?
> 
> NAGY Andras means that regexp scheme was not able to configure group
> variables. In this sense, gnus-parameters can do this.

I don't think I understand.

> Unfortunately, we can not implement [storing parameters in backends]
> for some backends without some extra helps (e.g. local files).  It
> could also be a problem for shared or readonly groups.

It would indeed require more work from backends, but it could be done.
I'm implementing read-only groups for nnmaildir, but marks will still
be stored in the backend; only the messages themselves are read-only,
and only the messages themselves need to be.

> > 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.
> 
> You don't have to. mapconcat and regexp-quote are your friends.

That seems rather more like a workaround than a solution.

> It is difficult to avoid loop links in your parameter-parents scheme.

Difficult for the code to detect tham, maybe, but not so difficult for
humans to prevent them, I think.  Must the more capable users be
hindered by a feature designed to prevent mistakes by novices?


paul