GNU bug report logs - #9410
Manual should clearly define "group name"

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9410 in the body.
You can then email your comments to 9410 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dave Abrahams <dave <at> boostpro.com>
To: submit <at> debbugs.gnu.org (The Gnus Bugfixing Girls + Boys)
Subject: Manual should clearly define "group name"
Date: Tue, 30 Aug 2011 11:38:21 -0800

Many times when customizing things for Gnus I have a pattern to match
groups, but it's never entirely clear to me against what the pattern
will be matched.  Will it be <method>+<server>:<group>, or simply
<group>?  Is the answer different depending on whether <method> is a
primary or secondary select method?  A general policy should be spelled
out in the manual, and IMO you should consider adding cross-references
each time group names or group name regexps come up.

Thanks


No Gnus v0.18
GNU Emacs 23.3.1 (x86_64-apple-darwin10.8.0, Carbon Version 1.6.0 AppKit 1038.36)
 of 2011-07-31 on vulcan
200 Leafnode NNTP Daemon, version 1.11.8 running at localhost (my fqdn: pluto.boostpro.com)
500 Unknown command

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Message #8 received at 9410 <at> debbugs.gnu.org (full text, mbox):

From: Dave Abrahams <dave <at> boostpro.com>
To: 9410 <at> debbugs.gnu.org
Subject: Example
Date: Tue, 30 Aug 2011 11:50:49 -0800

One example of the kind of thing that results: I write regexps like this
to match any group on my LocalIMAP server, which is the primary select
method.  

  ^\(\(nnimap\+\)?LocalIMAP:\)?[^+]*$

Though it's painful, I *can* program defensively like this when
a regexp is involved.  Where it becomes an insurmountable issue is where
the actual group name is needed rather than a regexp.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Message #15 received at 9410 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Dave Abrahams <dave <at> boostpro.com>
Cc: 9410 <at> debbugs.gnu.org
Subject: Re: Manual should clearly define "group name"
Date: Sun, 04 Sep 2011 16:24:43 +0200

Dave Abrahams <dave <at> boostpro.com> writes:

> Many times when customizing things for Gnus I have a pattern to match
> groups, but it's never entirely clear to me against what the pattern
> will be matched.  Will it be <method>+<server>:<group>, or simply
> <group>?  Is the answer different depending on whether <method> is a
> primary or secondary select method?

The latter, mainly, which is spelled out in the section that talks about
... that stuff.

I say "mainly" because if you're doing something in the backends, they
don't deal with Gnus group names, but with their own group names, which
are un-prefixed.

> A general policy should be spelled out in the manual, and IMO you
> should consider adding cross-references each time group names or group
> name regexps come up.

In Gnus, a group name is always what it is, so I don't think that's
necessary.

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

Message #18 received at 9410 <at> debbugs.gnu.org (full text, mbox):

From: Dave Abrahams <dave <at> boostpro.com>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: 9410 <at> debbugs.gnu.org
Subject: Re: Manual should clearly define "group name"
Date: Sun, 04 Sep 2011 07:15:55 -0800

on Sun Sep 04 2011, Lars Magne Ingebrigtsen <larsi-AT-gnus.org> wrote:

> Dave Abrahams <dave <at> boostpro.com> writes:
>
>> Many times when customizing things for Gnus I have a pattern to match
>> groups, but it's never entirely clear to me against what the pattern
>> will be matched.  Will it be <method>+<server>:<group>, or simply
>> <group>?  Is the answer different depending on whether <method> is a
>> primary or secondary select method?
>
> The latter, mainly, 

the latter, meaning "secondary select method," or meaning "simply
<group>?"

> which is spelled out in the section that talks about ... that stuff.

And which one would that be?

> I say "mainly" because if you're doing something in the backends, they
> don't deal with Gnus group names, but with their own group names, which
> are un-prefixed.

Umm... so that sounds like you meant "the former" above, and not "the
latter?"

>> A general policy should be spelled out in the manual, and IMO you
>> should consider adding cross-references each time group names or group
>> name regexps come up.
>
> In Gnus, a group name is always what it is

I'd like to join your tautology-of-the-month club, Lars! ;-)

> , so I don't think that's necessary.

This is clear as mud, I'm afraid.  Here's an example from my gnus
customizations:

 '(gnus-spam-process-destinations
   (quote
    (("^\\(\\(nnimap\\+\\)?LocalIMAP:\\)?[^+]*$" "[Gmail].Spam"))))
 '(gnus-spam-process-newsgroups
   (quote
    (("^\\(\\(nntp\\+\\)?LocalNNTP:\\)?gmane\\."
      ((spam spam-use-gmane))))))

I have a strong suspicion that those regexps are at least 400% more
complicated than they actually need to be, but I couldn't tell what Gnus
was going to be matching.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Message #21 received at 9410 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Dave Abrahams <dave <at> boostpro.com>
Cc: 9410 <at> debbugs.gnu.org
Subject: Re: Manual should clearly define "group name"
Date: Sat, 10 Sep 2011 20:37:16 +0200

Dave Abrahams <dave <at> boostpro.com> writes:

>>> Many times when customizing things for Gnus I have a pattern to match
>>> groups, but it's never entirely clear to me against what the pattern
>>> will be matched.  Will it be <method>+<server>:<group>, or simply
>>> <group>?  Is the answer different depending on whether <method> is a
>>> primary or secondary select method?
>>
>> The latter, mainly, 
>
> the latter, meaning "secondary select method," or meaning "simply
> <group>?"

The latter, as in "depending on whether method is...".

>> I say "mainly" because if you're doing something in the backends, they
>> don't deal with Gnus group names, but with their own group names, which
>> are un-prefixed.
>
> Umm... so that sounds like you meant "the former" above, and not "the
> latter?"

Nope.

> This is clear as mud, I'm afraid.  Here's an example from my gnus
> customizations:
>
>  '(gnus-spam-process-destinations
>    (quote
>     (("^\\(\\(nnimap\\+\\)?LocalIMAP:\\)?[^+]*$" "[Gmail].Spam"))))
>  '(gnus-spam-process-newsgroups
>    (quote
>     (("^\\(\\(nntp\\+\\)?LocalNNTP:\\)?gmane\\."
>       ((spam spam-use-gmane))))))
>
> I have a strong suspicion that those regexps are at least 400% more
> complicated than they actually need to be, but I couldn't tell what Gnus
> was going to be matching.

The regexps look fine to me.

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

Message #24 received at 9410 <at> debbugs.gnu.org (full text, mbox):

From: Dave Abrahams <dave <at> boostpro.com>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: 9410 <at> debbugs.gnu.org
Subject: Re: Manual should clearly define "group name"
Date: Sun, 11 Sep 2011 06:56:01 -0400

on Sat Sep 10 2011, Lars Magne Ingebrigtsen <larsi-AT-gnus.org> wrote:

> Dave Abrahams <dave <at> boostpro.com> writes:
>
>>>> Many times when customizing things for Gnus I have a pattern to match
>>>> groups, but it's never entirely clear to me against what the pattern
>>>> will be matched.  Will it be <method>+<server>:<group>, or simply
>>>> <group>?  Is the answer different depending on whether <method> is a
>>>> primary or secondary select method?
>>>
>>> The latter, mainly, 
>>
>> the latter, meaning "secondary select method," or meaning "simply
>> <group>?"
>
> The latter, as in "depending on whether method is...".

Okay, that's useful information that could be in the doc.

I'm guessing that if it's a primary select method, it'll be <group> and
if a secondary select method it'll be <method>+<server>:<group>.  Is
that correct?

>>> I say "mainly" because if you're doing something in the backends, they
>>> don't deal with Gnus group names, but with their own group names, which
>>> are un-prefixed.
>>
>> Umm... so that sounds like you meant "the former" above, and not "the
>> latter?"
>
> Nope.

With my idea of "latter" being so off-the-mark, it's no wonder I was
confused.  Thanks for your patience.

>> This is clear as mud, I'm afraid.  Here's an example from my gnus
>> customizations:
>>
>>  '(gnus-spam-process-destinations
>>    (quote
>>     (("^\\(\\(nnimap\\+\\)?LocalIMAP:\\)?[^+]*$" "[Gmail].Spam"))))
>>  '(gnus-spam-process-newsgroups
>>    (quote
>>     (("^\\(\\(nntp\\+\\)?LocalNNTP:\\)?gmane\\."
>>       ((spam spam-use-gmane))))))
>>
>> I have a strong suspicion that those regexps are at least 400% more
>> complicated than they actually need to be, but I couldn't tell what Gnus
>> was going to be matching.
>
> The regexps look fine to me.

Well, but they're more defensive than they need to be, aren't they?
They both will match any of the following three patterns.

      <method>+<server>:<group>
      <server>:<group>
      <group>

From what you've said so far I'm guessing that even if I want to be
resilient against servers switching from primary to secondary select
methods, the middle pattern is unnecessary.  Is that right?

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Message #27 received at 9410 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Dave Abrahams <dave <at> boostpro.com>
Cc: 9410 <at> debbugs.gnu.org
Subject: Re: Manual should clearly define "group name"
Date: Sun, 11 Sep 2011 17:13:49 +0200

Dave Abrahams <dave <at> boostpro.com> writes:

> Okay, that's useful information that could be in the doc.

Do you have a suggestion where?

> I'm guessing that if it's a primary select method, it'll be <group> and
> if a secondary select method it'll be <method>+<server>:<group>.  Is
> that correct?

Almost.  If it's a non-native group, it'll be the latter.

> With my idea of "latter" being so off-the-mark, it's no wonder I was
> confused.  Thanks for your patience.

:-)

> Well, but they're more defensive than they need to be, aren't they?
> They both will match any of the following three patterns.
>
>       <method>+<server>:<group>
>       <server>:<group>
>       <group>
>
>>From what you've said so far I'm guessing that even if I want to be
> resilient against servers switching from primary to secondary select
> methods, the middle pattern is unnecessary.  Is that right?

Yup.

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

Message #30 received at 9410 <at> debbugs.gnu.org (full text, mbox):

From: Dave Abrahams <dave <at> boostpro.com>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: 9410 <at> debbugs.gnu.org
Subject: Re: Manual should clearly define "group name"
Date: Sun, 11 Sep 2011 13:05:21 -0400

on Sun Sep 11 2011, Lars Magne Ingebrigtsen <larsi-AT-gnus.org> wrote:

> Dave Abrahams <dave <at> boostpro.com> writes:
>
>> Okay, that's useful information that could be in the doc.
>
> Do you have a suggestion where?

In a section on general conventions (you'd say, e.g. "when the doc says
`group name' it means a pattern like this.  The method+server part is
present under these conditions").  If there's no section on general
conventions, you should add one near the beginning of the manual.  I
can think of plenty of general information that could/should go there
and would improve the doc.

>> I'm guessing that if it's a primary select method, it'll be <group> and
>> if a secondary select method it'll be <method>+<server>:<group>.  Is
>> that correct?
>
> Almost.  If it's a non-native group, it'll be the latter.

*...looks up \<native\> in the manual...* so, if I've got that wrong,
there's something I still don't get: how is "non-native" different from
"secondary select method?"  Am I just using the wrong terminology?
(here's something else for the general conventions).

>> Well, but they're more defensive than they need to be, aren't they?
>> They both will match any of the following three patterns.
>>
>>       <method>+<server>:<group>
>>       <server>:<group>
>>       <group>
>>
>>>From what you've said so far I'm guessing that even if I want to be
>> resilient against servers switching from primary to secondary select
>> methods, the middle pattern is unnecessary.  Is that right?
>
> Yup.

Thanks.  So in general, I'm asking for this kind of information to be
gleanable from the doc, without agumentation by a discussion thread with
Lars :-)

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Message #33 received at 9410 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Dave Abrahams <dave <at> boostpro.com>
Cc: 9410 <at> debbugs.gnu.org
Subject: Re: Manual should clearly define "group name"
Date: Sun, 11 Sep 2011 22:56:27 +0200

Dave Abrahams <dave <at> boostpro.com> writes:

> In a section on general conventions (you'd say, e.g. "when the doc says
> `group name' it means a pattern like this.  The method+server part is
> present under these conditions").  If there's no section on general
> conventions, you should add one near the beginning of the manual.  I
> can think of plenty of general information that could/should go there
> and would improve the doc.

I've now added a couple of sentence to the Terminology section.

> *...looks up \<native\> in the manual...* so, if I've got that wrong,
> there's something I still don't get: how is "non-native" different from
> "secondary select method?"  Am I just using the wrong terminology?
> (here's something else for the general conventions).

There are three types of methods.  See the Terminology section.

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.