From: Lars Henriksen <Lars.Henriksen@netman.dk>
To: Mel Hatzis <hatzis@juniper.net>
Cc: help-gnats@gnu.org, Yngve Svendsen <yngve.svendsen@sun.com>,
Milan Zamazal <pdm@zamazal.org>
Subject: Re: Subject header matching--once again
Date: Wed, 06 Nov 2002 21:43:00 -0000 [thread overview]
Message-ID: <20021104191125.GA1148639@cluster2.netman.dk> (raw)
Message-ID: <20021106214300.t_qdSL8-wWHLZM3OGiYBQhDqdBmu1bi4MuzJ6RbEHVo@z> (raw)
In-Reply-To: <3DC602D4.1070706@juniper.net>
On Sun, Nov 03, 2002 at 09:17:08PM -0800, Mel Hatzis wrote:
> (snip)
>
> Building on your proposal, I suggest that it'd be even better if an
> array of capture groups could be specified, each associated with a
> field name. This would allow for fields other than 'category' on the
> subject line.
>
> This could take the following form:
>
> subject-matching {
> "\\<PR[ \t#/]?([0-9]+)[ \t]?:(.*)"
> captured-fields {
> "Number" "Synopsis"
> }
> }
I like that, a nice, concise way of identifying the groups and their purpose,
The built-in default would then become
subject-matching {
"\\<(PR[ \t#]?\\|([-\\w+.]+)/)([0-9]+)"
captured-fields {
"" "Category" "Number"
}
}
> The example above would match subject lines of the form:
>
> "PR 333 : missing subject-matching clause causes gnatsd to dump core"
>
> (verifying that the synopsis matched the PR number before accepting it
> as a reference to PR 333)
Would you allow any field name to appear in the list or just an exquisite
selection? I am not well versed in the intricacies of gnatsd. Does the existing
code allow a check of Synopsis as you suggest? There will, of course, have to
be validity checks for each of the field types in the list.
> >It should also be decided which syntax bits to use for Subject: matching.
> >At present only RE_NO_BK_PARENS is set, but why? Setting e.g. RE_NO_BK_VBAR
> >would avoid the need to escape the alternation operator. Milan suggested
> >using the same syntax bits as the rest of gnats:
> >
> > (RE_SYNTAX_POSIX_EXTENDED | RE_BK_PLUS_QM) & ~RE_DOT_NEWLINE
> >
> >but these are an issue in their own right, and this email is already
> >becoming
> >too long.
> >
> I agree with Milan that we should be consistent
Consistency is fine, but not just for its own sake. Subject matching is one
thing, query-expressions another. If both are served by the same syntax, then
by all means. To give two examples: should '.' match a newline? Should
character classes be allowed?
Lars Henriksen
_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats
next prev parent reply other threads:[~2002-11-04 21:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-03 21:40 Lars Henriksen
2002-11-04 11:31 ` Mel Hatzis
2002-11-04 15:41 ` Lars Henriksen [this message]
2002-11-06 21:43 ` Lars Henriksen
2002-11-09 3:26 ` Mel Hatzis
2002-12-02 14:45 ` Lars Henriksen
2002-12-17 6:38 ` Yngve Svendsen
2003-03-02 11:57 ` Andrew J. Gray
2003-03-02 20:47 ` Mark D. Baushke
2003-03-03 20:22 ` Lars Henriksen
2003-03-03 19:51 ` Lars Henriksen
2003-03-09 2:33 ` Andrew J. Gray
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20021104191125.GA1148639@cluster2.netman.dk \
--to=lars.henriksen@netman.dk \
--cc=hatzis@juniper.net \
--cc=help-gnats@gnu.org \
--cc=pdm@zamazal.org \
--cc=yngve.svendsen@sun.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).