[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Subject header matching--once again

From: Lars Henriksen
Subject: Re: Subject header matching--once again
Date: Mon, 4 Nov 2002 20:11:25 +0100
User-agent: Mutt/1.4i

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]