From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15796 invoked from network); 4 Nov 2002 19:31:44 -0000 Received: from unknown (HELO monty-python.gnu.org) (199.232.76.173) by sources.redhat.com with SMTP; 4 Nov 2002 19:31:44 -0000 Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 188ms2-0005MB-00; Mon, 04 Nov 2002 14:26:46 -0500 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 188mdN-0000E0-00 for help-gnats@gnu.org; Mon, 04 Nov 2002 14:11:37 -0500 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 188mdJ-0000CS-00 for help-gnats@gnu.org; Mon, 04 Nov 2002 14:11:36 -0500 Received: from cluster2.netman.dk ([193.88.72.48]) by monty-python.gnu.org with esmtp (Exim 4.10) id 188mdJ-0000Ax-00 for help-gnats@gnu.org; Mon, 04 Nov 2002 14:11:33 -0500 Received: (from lh@localhost) by cluster2.netman.dk (8.11.4/8.11.4) id gA4JBPG1151526; Mon, 4 Nov 2002 20:11:25 +0100 (MET) From: Lars Henriksen To: Mel Hatzis Cc: help-gnats@gnu.org, Yngve Svendsen , Milan Zamazal Subject: Re: Subject header matching--once again Message-ID: <20021104191125.GA1148639@cluster2.netman.dk> References: <20021102213505.GB646077@cluster1.netman.dk> <3DC602D4.1070706@juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DC602D4.1070706@juniper.net> User-Agent: Mutt/1.4i Sender: help-gnats-admin@gnu.org Errors-To: help-gnats-admin@gnu.org X-BeenThere: help-gnats@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: General discussion about GNU GNATS List-Archive: Date: Mon, 04 Nov 2002 15:41:00 -0000 X-SW-Source: 2002-q4/txt/msg00040.txt.bz2 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 { > "\\ 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4643 invoked from network); 4 Nov 2002 21:10:59 -0000 Received: from unknown (HELO monty-python.gnu.org) (199.232.76.173) by sources.redhat.com with SMTP; 4 Nov 2002 21:10:59 -0000 Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 188oEM-0007y6-00; Mon, 04 Nov 2002 15:53:54 -0500 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 188me6-0000dL-00 for help-gnats@gnu.org; Mon, 04 Nov 2002 14:12:22 -0500 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 188mdy-0000Ut-00 for help-gnats@gnu.org; Mon, 04 Nov 2002 14:12:18 -0500 Received: from cluster1.netman.dk ([193.88.72.47]) by monty-python.gnu.org with esmtp (Exim 4.10) id 188mdw-0000Ta-00 for help-gnats@gnu.org; Mon, 04 Nov 2002 14:12:13 -0500 Received: (from lh@localhost) by cluster2.netman.dk (8.11.4/8.11.4) id gA4JBPG1151526; Mon, 4 Nov 2002 20:11:25 +0100 (MET) From: Lars Henriksen To: Mel Hatzis Cc: help-gnats@gnu.org, Yngve Svendsen , Milan Zamazal Subject: Re: Subject header matching--once again Message-ID: <20021104191125.GA1148639@cluster2.netman.dk> References: <20021102213505.GB646077@cluster1.netman.dk> <3DC602D4.1070706@juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DC602D4.1070706@juniper.net> User-Agent: Mutt/1.4i Sender: help-gnats-admin@gnu.org Errors-To: help-gnats-admin@gnu.org X-BeenThere: help-gnats@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: General discussion about GNU GNATS List-Archive: Date: Wed, 06 Nov 2002 21:43:00 -0000 X-SW-Source: 2002-q4/txt/msg00041.txt.bz2 Message-ID: <20021106214300.t_qdSL8-wWHLZM3OGiYBQhDqdBmu1bi4MuzJ6RbEHVo@z> 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 { > "\\ 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