Re: Subject header matching--once again

[Lars Henriksen]

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