Re: [PATCH 3/4] diff.*.xfuncname which uses "extended" regex's for hunk header selection
- From
Brandon Casey <casey@nrlssc.navy.mil>
- Date
- Sep 19, 2008, 18:14 UTC
- Message-ID
- <UnIVj68wrBMolSCdIK6HiPbWuYW_tHaOLLRXg8Om13cHwLqzQ8QNNw@cipher.nrlssc.navy.mil>
- In-Reply-To
- <7vd4j212gb.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
Show 41 quoted lines
> I personally think it was a mistake that the loop returns failure when
> there is any pattern that does not match (it is a useful feature that a
> match with a negated one forces an early return, though).
>
> We may want to fix the semantics to be something like:
>
> for (i = 0; i < regs->nr; i++) {
> struct ff_reg *reg = ®s->array[i];
> if (!regexec(®->re, line_buffer, 2, pmatch, 0)) {
> if (reg->negate) {
> free(line_buffer);
> return -1;
> }
> break;
> }
> }
> if (regs->nr <= i) {
> free(line_buffer);
> return -1;
> }
> ... use pmatch() ...
>
> I.e. (1) negative match forces an early return (useful for catching
> language keywords), (2) first positive match is used, and (3) no match is
> a failure.
>
> Of course, by definition the above "fix" changes the semantics, and will
> break people's existing setup if somebody has an existing custom pattern
> string that does use more than one positive regexp anded together with
> "\n", but I somehow suspect nobody sane depends on the current broken
> semantics.
>
> It would help making JdS's ObjC alternates easier to write. You can say:
>
>
> /* A or B */
> "...(A|B)$"
> "\n" /* or C or D */
> "...(C|D)$"
>
> and both captures around A|B and C|D would be saved in $1.Just to let you know another pair of eyes has given the above a once over, I agree with your proposal. "or" semantics makes more sense than "and".
-brandon