Problem with gnus-parameters

Problem with gnus-parameters

[Tassilo Horn]

Hi all,

this is the value of my `gnus-parameters':

--8<---------------cut here---------------start------------->8---
(setq gnus-parameters
      `((,(rx "nnimap+")
	 (gnus-use-scoring nil)
	 (gcc-self . t))
	;; Mailing List exceptions
	(,(rx "nnimap+Uni:ml/")
	 (gcc-self . "nnimap+Uni:Sent"))
	(,(rx "nnimap+Fastmail:INBOX.mailinglists.")
	 (gcc-self . "nnimap+Fastmail:INBOX.Sent Items")
	 (gnus-use-scoring t))))
--8<---------------cut here---------------end--------------->8---

In all my IMAP groups scoring is turned off, except for the groups below
nnimap+Fastmail:INBOX.mailinglists.  Similarly, in all my IMAP groups a
Gcc header to the current group is added, except for the mailing list
groups below nnimap+Uni:ml/ and nnimap+Fastmail:INBOX.mailinglists,
where the sent mail folders specified above are inserted as Gcc.  This
suggests that the `gnus-parameters' are applied with the same semantics
as `gnus-posting-styles':

,----[ (info "(gnus)Posting Styles") ]
| Each style will be applicable if the first element "matches", in some
| form or other.  The entire alist will be iterated over, from the
| beginning towards the end, and each match will be applied, which means
| that attributes in later styles that match override the same
| attributes in earlier matching styles.
`----

However, now I added some parameters for setting the `expiry-target', so
that when marking an article with `E', it gets moved to that account's
trash folder.

--8<---------------cut here---------------start------------->8---
(setq gnus-parameters
      `((,(rx "nnimap+")
	 (gnus-use-scoring nil)
	 (gcc-self . t))

	;; Where to expire
	(,(rx "nnimap+Uni:")
	 (expiry-target . "nnimap+Uni:Trash"))
	(,(rx "nnimap+Fastmail:")
	 (expiry-target . "nnimap+Fastmail:INBOX.Trash"))
	(,(rx "nnimap+Gmail:")
	 (expiry-target . "nnimap+Gmail:[Google Mail]/Trash"))

	;; Mailing List exceptions
	(,(rx "nnimap+Uni:ml/")
	 (gcc-self . "nnimap+Uni:Sent"))
	(,(rx "nnimap+Fastmail:INBOX.mailinglists.")
	 (gcc-self . "nnimap+Fastmail:INBOX.Sent Items")
	 (gnus-use-scoring t))))
--8<---------------cut here---------------end--------------->8---

The expected result is that everything concerning gcc-self and scoring
stays as it was before, and that I have an account specific
expiry-target.

But the actual result is that scoring and expiry-target are set as
intended, but the gcc-self setting is disregarded for all groups that
are not below nnimap+Uni:ml or nnimap+Fastmail:INBOX.mailinglists, i.e.,
I don't get a Gcc header to the current group but to my
`gnus-message-archive-group'.

Why is that?  And should that behavior be considered a bug?

I've just remembered that I've brought up a related issue about 5 years
ago: http://thread.gmane.org/gmane.emacs.gnus.general/64171

Bye,
Tassilo

Re: Problem with gnus-parameters

[Katsumi Yamaoka]

Tassilo Horn wrote:
> This suggests that the `gnus-parameters' are applied with the same
> semantics as `gnus-posting-styles':

> ,----[ (info "(gnus)Posting Styles") ]
>| Each style will be applicable if the first element "matches", in some
>| form or other.

No, as for `gnus-parameters' the last match is applied now:

2010-09-26  Lars Magne Ingebrigtsen  <larsi@gnus.org>

	* gnus.el (gnus-group-fast-parameter): Return the last matching
	parameter instead of the first matching parameter.

In addition, the value of any parameter for a `gnus-parameters'
element that doesn't have that parameter is treated as nil.  So,

> (setq gnus-parameters
>       `((,(rx "nnimap+")
> 	 (gnus-use-scoring nil)
> 	 (gcc-self . t))

> 	;; Where to expire
> 	(,(rx "nnimap+Uni:")
> 	 (expiry-target . "nnimap+Uni:Trash"))
> 	(,(rx "nnimap+Fastmail:")
> 	 (expiry-target . "nnimap+Fastmail:INBOX.Trash"))
> 	(,(rx "nnimap+Gmail:")
> 	 (expiry-target . "nnimap+Gmail:[Google Mail]/Trash"))

> 	;; Mailing List exceptions
> 	(,(rx "nnimap+Uni:ml/")
> 	 (gcc-self . "nnimap+Uni:Sent"))
> 	(,(rx "nnimap+Fastmail:INBOX.mailinglists.")
> 	 (gcc-self . "nnimap+Fastmail:INBOX.Sent Items")
> 	 (gnus-use-scoring t))))

for the "nnimap+Gmail:foo" group for example, there are two matching
element; one sets gcc-self to t but the last one resets it to nil.
Maybe the solution is to add (gcc-self . t) to every element having
no gcc-self.  I verified it with this form:

(let ((gnus-parameters YOUR-SETTING))
  (with-temp-buffer
    (gnus-inews-insert-gcc "nnimap+Gmail:foo")
    (buffer-string)))

Re: Problem with gnus-parameters

[Tassilo Horn]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

Hi,

> Tassilo Horn wrote:
>> This suggests that the `gnus-parameters' are applied with the same
>> semantics as `gnus-posting-styles':
>
>> ,----[ (info "(gnus)Posting Styles") ]
>>| Each style will be applicable if the first element "matches", in some
>>| form or other.
>
> No, as for `gnus-parameters' the last match is applied now:
>
> 2010-09-26  Lars Magne Ingebrigtsen  <larsi@gnus.org>
>
> 	* gnus.el (gnus-group-fast-parameter): Return the last matching
> 	parameter instead of the first matching parameter.
>
> In addition, the value of any parameter for a `gnus-parameters'
> element that doesn't have that parameter is treated as nil.

Ok, I see.

> So,
>
>> (setq gnus-parameters
>>       `((,(rx "nnimap+")
>> 	 (gnus-use-scoring nil)
>> 	 (gcc-self . t))
>
>> 	;; Where to expire
>> 	(,(rx "nnimap+Uni:")
>> 	 (expiry-target . "nnimap+Uni:Trash"))
>> 	(,(rx "nnimap+Fastmail:")
>> 	 (expiry-target . "nnimap+Fastmail:INBOX.Trash"))
>> 	(,(rx "nnimap+Gmail:")
>> 	 (expiry-target . "nnimap+Gmail:[Google Mail]/Trash"))
>
>> 	;; Mailing List exceptions
>> 	(,(rx "nnimap+Uni:ml/")
>> 	 (gcc-self . "nnimap+Uni:Sent"))
>> 	(,(rx "nnimap+Fastmail:INBOX.mailinglists.")
>> 	 (gcc-self . "nnimap+Fastmail:INBOX.Sent Items")
>> 	 (gnus-use-scoring t))))
>
> for the "nnimap+Gmail:foo" group for example, there are two matching
> element; one sets gcc-self to t but the last one resets it to nil.
> Maybe the solution is to add (gcc-self . t) to every element having no
> gcc-self.

That would solve my issue, but the general question is: Is there a
reason why `gnus-parameters' are applied differently than posting
styles?

From user's perspective, the posting styles approach is extremely
convenient, because I don't need to duplicate information.  Now, to
achieve what I want, I need to duplicate information five times that
would be there implicitly with the iterative first-to-last posting style
application approach.

--8<---------------cut here---------------start------------->8---
(setq gnus-parameters
      `((,(rx "nnimap+")
	 (gnus-use-scoring nil)
	 (gcc-self . t))

	;; Where to expire
	(,(rx "nnimap+Uni:")
	 (gcc-self . t)                                  ;; DUPLICATE
	 (expiry-target . "nnimap+Uni:Trash"))
	(,(rx "nnimap+Fastmail:")
	 (gcc-self . t)                                  ;; DUPLICATE
	 (expiry-target . "nnimap+Fastmail:INBOX.Trash"))
	(,(rx "nnimap+Gmail:")
	 (gcc-self . t)                                  ;; DUPLICATE
	 (expiry-target . "nnimap+Gmail:[Google Mail]/Trash"))

	;; Mailing List exceptions
	(,(rx "nnimap+Uni:ml/")
	 (expiry-target . "nnimap+Uni:Trash")            ;; DUPLICATE
	 (gcc-self . "nnimap+Uni:Sent"))
	(,(rx "nnimap+Fastmail:INBOX.mailinglists.")
	 (expiry-target . "nnimap+Fastmail:INBOX.Trash") ;; DUPLICATE
	 (gcc-self . "nnimap+Fastmail:INBOX.Sent Items")
	 (gnus-use-scoring t))))
--8<---------------cut here---------------end--------------->8---

And even more baffling, the group local variables (like
gnus-use-scoring) actually seem to be applied exactly like posting
styles.  Above, I've disabled it for all nnimap groups except for my
mailinglist groups on my fastmail account.  That works just fine as-is
without the need of adding (gnus-use-scoring nil) to any other part.

IMO, the current implementation is pretty confusing.  And although the
docs state that there are parameters and group local variable, it
doesn't tell how that influences their application.  Well, basically it
doesn't say anything about how group parameters are applied, anyway...

Bye,
Tassilo

Re: Problem with gnus-parameters

[Lars Magne Ingebrigtsen]

Tassilo Horn <tassilo@member.fsf.org> writes:

> From user's perspective, the posting styles approach is extremely
> convenient, because I don't need to duplicate information.  Now, to
> achieve what I want, I need to duplicate information five times that
> would be there implicitly with the iterative first-to-last posting style
> application approach.

There's advantages to the "cumulative" approach, and there's advantages
to the "first match wins" approach, and Gnus has gone a bit back and
forth on what makes most sense in each case.

Which is how we ended up in the present condition.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Problem with gnus-parameters

[Tassilo Horn]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

Hi Lars,

>> From user's perspective, the posting styles approach is extremely
>> convenient, because I don't need to duplicate information.  Now, to
>> achieve what I want, I need to duplicate information five times that
>> would be there implicitly with the iterative first-to-last posting
>> style application approach.
>
> There's advantages to the "cumulative" approach, and there's
> advantages to the "first match wins" approach, and Gnus has gone a bit
> back and forth on what makes most sense in each case.
>
> Which is how we ended up in the present condition.  :-)

Yeah, right.  Doing it cumulatively for posting styles,
last-match-wins-ly for group parameters, but again cumulatively for
group local parameters (both specified in `gnus-parameters') seems like
a fine compromise then.  We should consider forming a political
party. ;-)

I can live with the current situation.  It's just that I think it's not
obvious, and it's not documented.

Bye,
Tassilo

Re: Problem with gnus-parameters

[Lars Magne Ingebrigtsen]

Tassilo Horn <tassilo@member.fsf.org> writes:

> I can live with the current situation.  It's just that I think it's not
> obvious, and it's not documented.

I've now documented it.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Problem with gnus-parameters

[Tassilo Horn]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

Hi Lars,

>> I can live with the current situation.  It's just that I think it's
>> not obvious, and it's not documented.
>
> I've now documented it.

You mean this?

,----[ (info "(gnus)Group Parameters") ]
|    The first clause that matches the group name will be used.
`----

That's actually not true.  In fact, if that was true, then the example
above that sentence would contain "dead code" because "mail\\.me" could
never match because the first clause always wins.

In the current situation, the *last* matching clause defines the group
parameters, and group parameters of previous matches are discarded.  For
group local variables, *all* matching clauses contribute to the final
values, i.e., here we have a cumulative approach (equal to posting
styles), where a latter clause may add to or even override previous
settings.  (I consider this a major advantage.)

That's exactly what I've complained about: the differences in the
evaluation strategy of similar items in the same alist.  Furthermore,
since group local variables in gnus-parameters are handled exactly as
gnus-posting-styles, I don't see a reason why group parameters are
treated as an exception.

If there are technical reasons, that's fine with me.  I can live with
it.  So, please fill in this form:

  - [ ] It'll stay as-is because of reason ________________________.

  - [ ] Oh, I didn't notice it's that awkward.  I'll fix it in a way
        that ______________________________________________________.

In any case, I happily volunteer to clarify the docs.

Bye,
Tassilo

Re: Problem with gnus-parameters

[Lars Magne Ingebrigtsen]

Tassilo Horn <tassilo@member.fsf.org> writes:

> That's actually not true.  In fact, if that was true, then the example
> above that sentence would contain "dead code" because "mail\\.me" could
> never match because the first clause always wins.

This is getting more and more confusing.

Here's the code that's used:

(defun gnus-parameters-get-parameter (group)
  "Return the group parameters for GROUP from `gnus-parameters'."
  (let ((case-fold-search (if (eq gnus-parameters-case-fold-search 'default)
			      case-fold-search
			    gnus-parameters-case-fold-search))
	params-list)
    (dolist (elem gnus-parameters)
      (when (string-match (car elem) group)
	(setq params-list
	      (nconc (gnus-expand-group-parameters
		      (car elem) (cdr elem) group)
		     params-list))))
    params-list))

This is extremely cumulative, and lets the last setting win.  Are you
sure it's not working?
    
-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Problem with gnus-parameters

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> This is extremely cumulative, and lets the last setting win.  Are you
> sure it's not working?

I tried the following:

(setq gnus-parameters
  '(("gmane" (foo "lala"))
    ("emacs" (foo "emacs"))))

In most Gmane groups, `foo' got set to "lala".  In this group, which has
"emacs" in its name, it got set to "emacs".
    
-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Problem with gnus-parameters

[Tassilo Horn]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

Hi Lars,

>> This is extremely cumulative, and lets the last setting win.  Are you
>> sure it's not working?
>
> I tried the following:
>
> (setq gnus-parameters
>   '(("gmane" (foo "lala"))
>     ("emacs" (foo "emacs"))))
>
> In most Gmane groups, `foo' got set to "lala".  In this group, which
> has "emacs" in its name, it got set to "emacs".

Yeah, yeah.  We already agree that all clauses are tested and the last
one determines the final value.  The left issue is that only the group
parameters of the last match are applied whereas group local variables
are applied cumulatively, meaning every match counts and later matches
may override values of previous matches.

BTW, in your example, foo is a group local variable because it's given
as a proper list, not a dotted pair.

Give this one a try:

--8<---------------cut here---------------start------------->8---
(setq gnus-parameters
  '(("gmane"
     (gcc-self . t)
     (bar "blabla")
     (foo "lala"))
    ("emacs"
     (foo "emacs"))))
--8<---------------cut here---------------end--------------->8---

Is gcc-self active in this group matching both gmane and emacs?  For me,
its not.  And is bar set here?  Yes, for me it is.

Bye,
Tassilo

Re: Problem with gnus-parameters

[Lars Magne Ingebrigtsen]

Tassilo Horn <tassilo@member.fsf.org> writes:

> BTW, in your example, foo is a group local variable because it's given
> as a proper list, not a dotted pair.
>
> Give this one a try:
> (setq gnus-parameters
>   '(("gmane"
>      (gcc-self . t)
>      (bar "blabla")
>      (foo "lala"))
>     ("emacs"
>      (foo "emacs"))))
> Is gcc-self active in this group matching both gmane and emacs?  For me,
> its not.  And is bar set here?  Yes, for me it is.

If I use the following:

(setq gnus-parameters
  '(("gmane" (foo "lala") (bar "zot") (gcc-self . t))
    ("emacs" (foo "emacs") (gcc-self))))

and then enter a non-Emacs Gmane group, I get gcc-self.  In the Emacs
groups, I don't.  So this seems to work for me.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Problem with gnus-parameters

[Tassilo Horn]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>> Is gcc-self active in this group matching both gmane and emacs?  For me,
>> its not.  And is bar set here?  Yes, for me it is.
>
> If I use the following:
>
> (setq gnus-parameters
>   '(("gmane" (foo "lala") (bar "zot") (gcc-self . t))
>     ("emacs" (foo "emacs") (gcc-self))))
>
> and then enter a non-Emacs Gmane group, I get gcc-self.  In the Emacs
> groups, I don't.  So this seems to work for me.

Lars, you don't get me.  That's exactly what I complain about:

  gmane.foo:   foo=lala,  bar=zot, gcc-self
  gmane.emacs: foo=emacs, bar=zot, no gcc-self

While the bar-setting in the "gmane" clause also accounts for its value
in gmane.emacs, the gcc-self setting doesn't.  This difference between
group parameters vs. group local variables is my concern.

Bye,
Tassilo

Re: Problem with gnus-parameters

[Lars Magne Ingebrigtsen]

Tassilo Horn <tassilo@member.fsf.org> writes:

>> If I use the following:
>>
>> (setq gnus-parameters
>>   '(("gmane" (foo "lala") (bar "zot") (gcc-self . t))
>>     ("emacs" (foo "emacs") (gcc-self))))
>>
>> and then enter a non-Emacs Gmane group, I get gcc-self.  In the Emacs
>> groups, I don't.  So this seems to work for me.
>
> Lars, you don't get me.  That's exactly what I complain about:
>
>   gmane.foo:   foo=lala,  bar=zot, gcc-self
>   gmane.emacs: foo=emacs, bar=zot, no gcc-self
>
> While the bar-setting in the "gmane" clause also accounts for its value
> in gmane.emacs, the gcc-self setting doesn't.  This difference between
> group parameters vs. group local variables is my concern.

Please type slower; I'm not getting what you're saying.  :-)

   gmane.foo:   foo=lala,  bar=zot, gcc-self
   gmane.emacs: foo=emacs, bar=zot, no gcc-self

is exactly what I'd expect with those parameters.  The last setting
wins, so in gmane.emacs there's no gcc-self.  Since the last setting is
(gcc-self . nil).

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Problem with gnus-parameters

[Tassilo Horn]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Please type slower; I'm not getting what you're saying.  :-)

We can play that game for hours.  Oh, I've overlooked the (gcc-self) in
the "emacs" clause.  Anyway, the following setting will result in the
same effects.  Look, I've even lined it up for you! :-)

 '(("gmane"      (foo "lala") (bar "zot") (gcc-self . t))
   ("emacs"      (foo "emacs")                          ))

>    gmane.foo:   foo=lala,    bar=zot,    gcc-self
>    gmane.emacs: foo=emacs,   bar=zot,    no gcc-self

Now, let's inspect the effects:

  - the (bar "zot") entry is only set in the "gmane" clause, yet we have
    its value also in gmane.emacs

  - the "lala" foo value gets overridden in the gmane.emacs group,
    because that defines its own foo setting

  - the gcc-self (which is a group parameter and not a group local
    variable like foo and bar) is *not* propagated to gmane.emacs, as
    one would expect because of bar

To me, that inconsistency between group local variables and group
parameters is far from obvious.  I'd prefer, if in gmane.emacs gcc-self
was active, too, i.e., I'd expect these effects:

     gmane.foo:   foo=lala,    bar=zot,    gcc-self
     gmane.emacs: foo=emacs,   bar=zot,    gcc-self

Then, we had full consistency in how group local variables and group
parameters defined in `gnus-parameters' work, and the behavior would
also be consistent with how `gnus-posting-styles' are applied.

Got it, now?  I really can't be more precise.

That said, although it's inconsistent, I can easily live with it.  If
you decide the current way is how the great spaghetti monster wants it
to be, that's fine.  But it needs a precise documentation then.

Bye,
Tassilo

Re: Problem with gnus-parameters

[Lars Magne Ingebrigtsen]

Tassilo Horn <tassilo@member.fsf.org> writes:

>  '(("gmane"      (foo "lala") (bar "zot") (gcc-self . t))
>    ("emacs"      (foo "emacs")                          ))

[...]

> To me, that inconsistency between group local variables and group
> parameters is far from obvious.  I'd prefer, if in gmane.emacs gcc-self
> was active, too, i.e., I'd expect these effects:
>
>      gmane.foo:   foo=lala,    bar=zot,    gcc-self
>      gmane.emacs: foo=emacs,   bar=zot,    gcc-self

Yes, this is clearly a bug, I think:

(gnus-group-find-parameter "nntp+news.gmane.org:gmane.emacs.test" 'gcc-self)
=> nil

(gnus-group-find-parameter "nntp+news.gmane.org:gmane.emacs.test")
=> ((foo "emacs") (gcc-self . t) (bar "zot") (foo "lala"))

And it's because of this:

(defun gnus-group-find-parameter (group &optional symbol allow-list)

[...]

    (if symbol
	(gnus-group-fast-parameter group symbol allow-list)
      (nconc
       (copy-sequence
	(funcall gnus-group-get-parameter-function group))
       (gnus-parameters-get-parameter group)))))

So the "fast" version applies the precedence in a different way than the
non-fast version does.

I've now fixed the -fast- function to do what it's supposed to.  Give it
a whirl and see whether I've ironed out all the kinks...

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Problem with gnus-parameters

[Tassilo Horn]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>>  '(("gmane"      (foo "lala") (bar "zot") (gcc-self . t))
>>    ("emacs"      (foo "emacs")                          ))
>
> [...]
>
>> To me, that inconsistency between group local variables and group
>> parameters is far from obvious.  I'd prefer, if in gmane.emacs gcc-self
>> was active, too, i.e., I'd expect these effects:
>>
>>      gmane.foo:   foo=lala,    bar=zot,    gcc-self
>>      gmane.emacs: foo=emacs,   bar=zot,    gcc-self
>
> Yes, this is clearly a bug, I think:

It was that way as long as I can think of.  I brought that issue up
somewhere in 2008 I think, but didn't get responses.

>     (if symbol
> 	(gnus-group-fast-parameter group symbol allow-list)
>       (nconc
>        (copy-sequence
> 	(funcall gnus-group-get-parameter-function group))
>        (gnus-parameters-get-parameter group)))))
>
> So the "fast" version applies the precedence in a different way than
> the non-fast version does.
>
> I've now fixed the -fast- function to do what it's supposed to.  Give
> it a whirl and see whether I've ironed out all the kinks...

It seems to work fine now.  Thanks a lot!

Bye,
Tassilo

Re: Problem with gnus-parameters

[Tassilo Horn]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

Hi Lars,

>> That's actually not true.  In fact, if that was true, then the
>> example above that sentence would contain "dead code" because
>> "mail\\.me" could never match because the first clause always wins.
>
> This is getting more and more confusing.

My statement was about the fact that you've written *first* match in the
info docs.

> Here's the code that's used:
>
> (defun gnus-parameters-get-parameter (group)
>   "Return the group parameters for GROUP from `gnus-parameters'."
>   (let ((case-fold-search (if (eq gnus-parameters-case-fold-search 'default)
> 			      case-fold-search
> 			    gnus-parameters-case-fold-search))
> 	params-list)
>     (dolist (elem gnus-parameters)
>       (when (string-match (car elem) group)
> 	(setq params-list
> 	      (nconc (gnus-expand-group-parameters
> 		      (car elem) (cdr elem) group)
> 		     params-list))))
>     params-list))
>
> This is extremely cumulative, and lets the last setting win.

At least, we now agree that the last match wins.  And it looks quite
cumulative.

> Are you sure it's not working?

Yes.  Here are my parameters.

--8<---------------cut here---------------start------------->8---
(setq gnus-parameters
      `((,(rx (or "emacs" "gnus"))
         (gnus-button-emacs-level 10))

	(,(rx "nnimap+")
	 (gnus-use-scoring nil))

	;; Where to expire
	(,(rx "nnimap+Uni:")
	 (gcc-self . t)
	 (expiry-target . "nnimap+Uni:Trash"))
	(,(rx "nnimap+Fastmail:")
	 (gcc-self . t)
	 (expiry-target . "nnimap+Fastmail:INBOX.Trash"))
	(,(rx "nnimap+Gmail:")
	 (gcc-self . t)
	 (expiry-target . "nnimap+Gmail:[Google Mail]/Trash"))

	;; TEST CLAUSE
	(,(rx "nnimap+Uni:INBOX")
	 )
	
	;; Mailing List exceptions
	(,(rx "nnimap+Uni:ml/")
	 (gcc-self . "nnimap+Uni:Sent")
	 (expiry-target . "nnimap+Uni:Trash"))
	(,(rx "nnimap+Fastmail:INBOX.mailinglists.")
	 (gcc-self . "nnimap+Fastmail:INBOX.Sent Items")
	 (expiry-target . "nnimap+Fastmail:INBOX.Trash")
	 (gnus-use-scoring t))

	(,(rx "nntp+Gmane:gwene.")
	 (gnus-use-scoring t)
	 (gnus-summary-line-format
	  "%U%R%4{┃%}%2us%4{┃ %*%B%} %s %3{<%&user-date;>%}\n"))))
--8<---------------cut here---------------end--------------->8---

See the TEST CLAUSE.  If group parameters were cumulative, then in
nnimap+Uni:INBOX I should have gcc-self working.  Just tested, and the
Gcc is set to my archive group meaning no gcc-self is set.

Bye,
Tassilo

Re: Problem with gnus-parameters

[Lars Magne Ingebrigtsen]

Tassilo Horn <tassilo@member.fsf.org> writes:

> My statement was about the fact that you've written *first* match in the
> info docs.

I've fixed that now...

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/