Feature request: strip banners from all groups matching a regexp

Feature request: strip banners from all groups matching a regexp

[Christopher Splinter]

Hi,

IWBNI there were some functionality which would allow the user to
strip banners from messages in groups which match a certain regexp
using something like

(setq gnus-strip-banners-from-groups
  '(("nnml:lists\\.debian\\..*" . signature)))

Re: Feature request: strip banners from all groups matching a regexp

[Jeff Senn]

Christopher Splinter <chris@splinter.inka.de> writes:

> Hi,
> 
> IWBNI there were some functionality which would allow the user to
> strip banners from messages in groups which match a certain regexp
> using something like
> 
> (setq gnus-strip-banners-from-groups
>   '(("nnml:lists\\.debian\\..*" . signature)))

M-x apropos \r banner \r

:-) 

Or did you mean you specifically wanted a regex for the group(s)
rather than a group parameter that specifies a regex for the banner?

Aside: Is the 'banner' parameter documented in the Group Parameters
Info?  I don't see it...

-- 
-Jas

Re: Feature request: strip banners from all groups matching a regexp

[Charles Sebold]

On 25 Kislev 5761, Christopher Splinter wrote:

> IWBNI there were some functionality which would allow the user to
> strip banners from messages in groups which match a certain regexp
> using something like
> 
> (setq gnus-strip-banners-from-groups
>   '(("nnml:lists\\.debian\\..*" . signature)))

Note: I'm running Gnus from CVS, earlier versions may or may not do
this.

Does this help?  If you have the Gnus manual in your info, put your
cursor after the next line and hit C-x C-e

(Info-goto-node "(gnus)Article Hiding")

,----
| `W W B'
|      Strip the banner specified by the `banner' group parameter
|      (`gnus-article-strip-banner').  This is mainly used to hide those
|      annoying banners and/or signatures that some mailing lists and
|      moderated groups adds to all the messages.  The way to use this
|      function is to add the `banner' group parameter (*note Group
|      Parameters::.) to the group you want banners stripped from.  The
|      parameter either be a string, which will be interpreted as a
|      regular expression matching text to be removed, or the symbol
|      `signature', meaning that the (last) signature should be removed,
|      or other symbol, meaning that the corresponding regular expression
|      in `gnus-article-banner-alist' is used.
`----

-- 
Charles Sebold
Random Answer to an Emacs Very Frequently Asked Question:
 Eshell or ansi-color.el solves problems with garbage GCC or ls output.
--
25th of Kislev, 5761
--
Power is danger.
		-- The Centurion, "Balance of Terror", stardate 1709.2

Re: Feature request: strip banners from all groups matching a regexp

[Christopher Splinter]

* Charles Sebold <csebold@ezl.com>:

> (Info-goto-node "(gnus)Article Hiding")
> 
> ,----
> | `W W B'
> |      Strip the banner specified by the `banner' group parameter
> |      (`gnus-article-strip-banner').

This uses group parameters (which is very annoying if you read
lots of groups that have the same banner).

Re: Feature request: strip banners from all groups matching a regexp

[Christopher Splinter]

* Jeff Senn <senn@maya.com>:

>> IWBNI there were some functionality which would allow the user to
>> strip banners from messages in groups which match a certain regexp
>> using something like
>> 
>> (setq gnus-strip-banners-from-groups
>>   '(("nnml:lists\\.debian\\..*" . signature)))
> Or did you mean you specifically wanted a regex for the
> group(s) rather than a group parameter that specifies a regex
> for the banner?

Yes.

> Aside: Is the 'banner' parameter documented in the Group
> Parameters Info?  I don't see it...

No, but it's in the 'Article Hiding' node. I just sent a patch
with documentation for this group parameter to bugs@gnus.org.

Re: Feature request: strip banners from all groups matching a regexp

[ShengHuo ZHU]

Christopher Splinter <chris@splinter.inka.de> writes:

> Hi,
> 
> IWBNI there were some functionality which would allow the user to
> strip banners from messages in groups which match a certain regexp
> using something like
> 
> (setq gnus-strip-banners-from-groups
>   '(("nnml:lists\\.debian\\..*" . signature)))

Implemented. A variable called gnus-parameter-banner-alist.

ShengHuo

Re: Feature request: strip banners from all groups matching a regexp

[Kai Großjohann]

On 22 Dec 2000, Christopher Splinter wrote:

> This uses group parameters (which is very annoying if you read
> lots of groups that have the same banner).

Maybe topic parameters are your friends.  Though you then have to
group all the groups with the same banner in the same topic.  Hm.

kai
-- 
~/.signature

Re: Feature request: strip banners from all groups matching a regexp

[NAGY Andras]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> > This uses group parameters (which is very annoying if you read
> > lots of groups that have the same banner).
> 
> Maybe topic parameters are your friends.  Though you then have to
> group all the groups with the same banner in the same topic.  Hm.

Some of the group options can be set based on group and topic
parameters as well as on group regexps (say, total-expiry).  Others
only based on parameters (banner).  And perhaps some only based on
regexps. :)

Shouldn't there be a unified way for doing stuff like this?



Andras

Re: Feature request: strip banners from all groups matching a regexp

[Kai Großjohann]

On 23 Dec 2000, NAGY Andras wrote:

> Shouldn't there be a unified way for doing stuff like this?

Yes.  I wish there was.

kai
-- 
~/.signature

regexp-based group parameters

[NAGY Andras]

NAGY Andras <nagya@inf.elte.hu> writes:

> Some of the group options can be set based on group and topic
> parameters as well as on group regexps (say, total-expiry).  Others
> only based on parameters (banner).  And perhaps some only based on
> regexps. :)
> 
> Shouldn't there be a unified way for doing stuff like this?

Let's summarize once more: many functions in Gnus behave differently,
depending on which group they operate on.  There is (was?) a tendency
among these functions to introduce a custom variable, containing a
regexp, to be matched against group names, to decide which groups they
are supposed to deal width.  (Examples include
gnus-total-expirable-newsgroups, gnus-mailing-list-groups,
gnus-permanently-visible-groups etc).  Generally, a group matching or
not one of these regexps defines a boolean parameter for that group.

There are other type of such variables, regexp->something alists
(e.g. gnus-posting-styles) which assign a parameter to a group, based
on its name.

Besides this, there is the group/topic parameters mechanism, where
parameters can be assigned directly, or based on the groups place in
the topic hierarchy.  Furthermore, this info is stored in the newsrc
file instead of being customizable by the user through a config file.

Many (but not all, and even if yes, see below) Gnus functions (posting
styles, expiry, etc) allow the user to specify group parameters via
the gnus-group-find-parameter API as well as the "non-standard" custom
regexp way.

Extending the find-parameter implementation to treat not only
group/topic parameters found in newsrc, but also those found in a
newly introduced regexp->param-list alist, would have the following
advantages:

* Gnus functions could use a single interface to fetch group
parameters based on both methods, without having to deal with regexp
matching and stuff.

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

* The latter would allow storing group parameters in a static config
file, suitable for using on several hosts, instead of the
host-dependent, ever-changing newsrc.eld.


While writing this, I have found gnus-define-group-parameter which is
close to what I am talking about.  This defines a function
(gnus-parameter-%s group) for fetching a parameter's value, and this
function makes use of gnus-parameter-%s-alist, which maps group
regexps to parameter values.

However, there are several problems with this:

* For now, only 7 group parameters are defined this way.

* For this reason, the rest of Gnus does not make use of these
functions, but uses gnus-group-find-parameter, which ignores the
contents of gnus-parameter-%s-alist.

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

* There is still no way to assign multiple parameters to a set of
groups at once.

To demonstrate this: I cannot (but would like to) write the following
in my .gnus:

(setq gnus-parameters
   '(("mail\..*" (gnus-show-threads . nil)
                 (gnus-use-scoring . nil)
                 (gnus-summary-line-format .
                        "%U%R%z%I%(%[%d:%ub%-20,20f%]%) %s\n")
                 (gcc-self . t)
                 (dispaly . all))

     ("list\..*" (total-expire . t)
                 (broken-reply-to . t))))
     

I think the example speaks for itself.  (Setting everything in one
place, independetly of newsrc.eld and topic topology.)

Anyone willing to implement this?  Introducing the new variable (named
gnus-parameters above) and modifying gnus-group-find-parameter would
do the trick, I believe.


Andras

Re: regexp-based group parameters

[Toby Speight]

0> In article <dzc1ysps66o.fsf_-_@pandora.inf.elte.hu>,
0> NAGY Andras <URL:mailto:nagya@inf.elte.hu> ("Nagy") wrote:

Nagy> There is (was?) a tendency among these functions to introduce a
Nagy> custom variable, containing a regexp, to be matched against
Nagy> group names, to decide which groups they are supposed to deal
Nagy> width.
Nagy>
Nagy> There are other type of such variables, regexp->something alists
Nagy> (e.g. gnus-posting-styles) which assign a parameter to a group,
Nagy> based on its name.
Nagy>
Nagy> Besides this, there is the group/topic parameters mechanism,
Nagy> where parameters can be assigned directly, or based on the
Nagy> groups place in the topic hierarchy.  Furthermore, this info is
Nagy> stored in the newsrc file instead of being customizable by the
Nagy> user through a config file.

There's also the possibility of setting group-local variables via
score files.

It would be nice to have these things consistent, and with a clear
statement about when they are applied, and what the precedence order
is.

Re: regexp-based group parameters

[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

Re: regexp-based group parameters

[Kai Großjohann]

On 23 Feb 2001, Paul Jarc wrote:

> 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 like to be able to say that all nnml:auto.* groups are
auto-expirable.  This way, I can put auto-expirable groups in various
topics and I don't have to worry about setting the parameter on each
and every new group (where I think it's appriate).

Just to provide a counter-opinion to yours.  Maybe regexp matching is
useful to some people and thus shouldn't be removed.

kai
-- 
Be indiscrete.  Do it continuously.

Re: regexp-based group parameters

[Paul Jarc]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> I like to be able to say that all nnml:auto.* groups are
> auto-expirable.  This way, I can put auto-expirable groups in various
> topics and I don't have to worry about setting the parameter on each
> and every new group (where I think it's appriate).

Note that the hierarchy I suggested for parameters would be orthogonal
to the hierarchy for UI (topics).  Is using an "auto.*" name for a
group any easier than adding a "parameter-parent" parameter?

Hmm... I can imagine it would be useful for a group to have an ordered
list of parents.  Then groups g1 and g2 could share one set of
attributes via a common parent p1, while g1 shares another set of
attributes with group g3 via another parent p2; g2 wouldn't need to be
a descendent of p2, and g3 wouldn't need to be a descendent of p1.

> Just to provide a counter-opinion to yours.  Maybe regexp matching is
> useful to some people and thus shouldn't be removed.

It's certainly useful.  But if we can provide a single unified way of
doing things that's at least *as useful* as any existing scheme,
then that would seem like a good thing to do.


paul

Re: regexp-based group parameters

[Kai Großjohann]

On 23 Feb 2001, Paul Jarc wrote:

> Note that the hierarchy I suggested for parameters would be
> orthogonal to the hierarchy for UI (topics).  Is using an "auto.*"
> name for a group any easier than adding a "parameter-parent"
> parameter?

Oh, I completely missed the orthogonality.  Of course, adding a `this
is a ML group' parameter is just as simple.

kai
-- 
Be indiscrete.  Do it continuously.

Re: regexp-based group parameters

[ShengHuo ZHU]

NAGY Andras <nagya@inf.elte.hu> writes:

[...]

> To demonstrate this: I cannot (but would like to) write the following
> in my .gnus:
> 
> (setq gnus-parameters
>    '(("mail\..*" (gnus-show-threads . nil)
>                  (gnus-use-scoring . nil)
>                  (gnus-summary-line-format .
>                         "%U%R%z%I%(%[%d:%ub%-20,20f%]%) %s\n")
>                  (gcc-self . t)
>                  (dispaly . all))
> 
>      ("list\..*" (total-expire . t)
>                  (broken-reply-to . t))))
>      
> 
> I think the example speaks for itself.  (Setting everything in one
> place, independetly of newsrc.eld and topic topology.)
> 
> Anyone willing to implement this?  Introducing the new variable (named
> gnus-parameters above) and modifying gnus-group-find-parameter would
> do the trick, I believe.

OK. It is in oGnus.  

Please notice that there is no "." in group variables.

ShengHuo

Re: regexp-based group parameters

[ShengHuo ZHU]

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.

[...]

> 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.

> 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.

I don't like this idea. Regexp scheme is much clearer and easier to
maintain.

> 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.

ShengHuo

Re: regexp-based group parameters

[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

Re: regexp-based group parameters

[ShengHuo ZHU]

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'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?

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

> > > 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.

You don't have to. mapconcat and regexp-quote are your friends.

> > > 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.

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

ShengHuo

Re: regexp-based group parameters

[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

Re: regexp-based group parameters

[Kai Großjohann]

On 23 Feb 2001, Paul Jarc wrote:

> 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.

There are topics, you know.

kai
-- 
Be indiscrete.  Do it continuously.

Re: regexp-based group parameters

[Randal L. Schwartz]

>>>>> "Kai" == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

Kai> On 23 Feb 2001, Paul Jarc wrote:
>> 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.

Kai> I like to be able to say that all nnml:auto.* groups are
Kai> auto-expirable.  This way, I can put auto-expirable groups in various
Kai> topics and I don't have to worry about setting the parameter on each
Kai> and every new group (where I think it's appriate).

I do this already in my .gnus.el --

(setq gnus-total-expirable-newsgroups "^nnml:list\\.")

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: regexp-based group parameters

[Paul Jarc]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> On 23 Feb 2001, Paul Jarc wrote:
> > 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.
> 
> There are topics, you know.

I know; I was talking about the hypothetical future where
gnus-parameters is the One True (only?) way to set group parameters.
Mind you, I'm not *entirely* happy with my suggestion either... does
anyone else have any ideas?


paul

Re: regexp-based group parameters

[Kai Großjohann]

On 24 Feb 2001, Paul Jarc wrote:
> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>> 
>> There are topics, you know.
> 
> I know; I was talking about the hypothetical future where
> gnus-parameters is the One True (only?) way to set group parameters.

Andras never wanted to _replace_ the existing group/topic parameter
mechanism: 

/----[ from Andras' original post ]
| Extending the find-parameter implementation to treat not only
| group/topic parameters found in newsrc, but also those found in a
| newly introduced regexp->param-list alist, would have the following
| advantages:
\----

At least that's the way I read his `not only... but also'.

kai
-- 
Be indiscrete.  Do it continuously.

Re: regexp-based group parameters

[NAGY Andras]

ShengHuo ZHU <zsh@cs.rochester.edu> writes:

> > To demonstrate this: I cannot (but would like to) write the following
> > in my .gnus:
> > 
> > (setq gnus-parameters

[...]

> >                  (dispaly . all))

[...]

> OK. It is in oGnus.  

Thanks a lot, this is really useful.

Please correct the typo at gnus.el:860.


A note about the variable name.  I picked this almost randomly, for
demonstration purposes, without thinking about whether it conforms
with the Gnus Naming Scheme.  (Is there such a thing?)  Other
possibilities include: gnus-group-parameters and
gnus-group-parameters-alist, indicating this has something to do with
groups, and the value type, respectively.



Andras

Re: regexp-based group parameters

[ShengHuo ZHU]

NAGY Andras <nagya@inf.elte.hu> writes:

> Please correct the typo at gnus.el:860.

Thanks. Fixed.

> A note about the variable name.  I picked this almost randomly, for
> demonstration purposes, without thinking about whether it conforms
> with the Gnus Naming Scheme.  (Is there such a thing?)  

I guess there is an implicit one.

> Other possibilities include: gnus-group-parameters and
> gnus-group-parameters-alist, indicating this has something to do
> with groups, and the value type, respectively.

The name is OK. It is in gnus.el.

ShengHuo