Re: [PATCH] git send-email: edit recipient addresses with the --compose flag

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

 



Le Monday 10 November 2008 01:38:30 Ian Hilt, vous avez écrit :
> On Sun, 9 Nov 2008, Junio C Hamano wrote:
> > Ian Hilt <ian.hilt@xxxxxxx> writes:
> > > On Sun, 9 Nov 2008, Francis Galiegue wrote:
> > >> Le Sunday 09 November 2008 13:59:48 Ian Hilt, vous avez écrit :
> > >> > +	if ($c_file =~ /^To:\s*+(.+)\s*\nCc:/ism) {
> > >>
> > >> Greedy operators are only supported with perl 5.10 or more... I think
> > >> it's a bad idea to use them...
> > >
> > > The problem here was that a space should follow the field, but it may
> > > not.  The user may unwarily backup over it.  "\s*" would match this
> > > case.
> > >
> > > But if there is a space, it is included in the "(.+)".  So I tried
> > > "\s+", which did not include the space, but it won't include the first
> > > address if there isn't a space after the field.
> > >
> > > The quantified subpattern seemed to do the trick.  But, if it could
> > > result in a dependency issue, I would agree this would be a bad idea.
> >
> > You expect something non-blank there anyway, so why not do:
> >
> > 	To:\s*(\S.*?)\s*\n....
>
> That works.  Although, I seem to be missing Francis' point.

No. The _lazy_ quantifiers (*?, ??, *?, +?, {...}?) are supported all right. 
But they should be avoided in general.

> According 
> to perlre, a quantified subpattern is "greedy".  So a "greedy operator"
> is any one of the standard quantified subpatterns.  The "+" and "?"
> modify its matching behavior.  And it seems to me that it _has_ to use a
> q.s. to work ...

My wording may be bad, then. They're not greedy, they just don't allow for 
backtracking. They are more than greedy. Let me explain.

Consider "number 42" for instance. If you match it against:

* .*(\d+) => $1 would be "2": the * eats everything but _has_ to backtrack for 
\d+ to get anything, but just one number is enough;
* .*?(\d+) => $1 would be "42": as *? is lazy, this means that after each 
match, it looks to see whether the next element in the regex would match 
anything; as soon as \d+ matches 4, .*? stops there;
* .*+(\d+) => $1 would match nothing! *+ eats everything, but the + afterwards 
_doesn't allow it to backtrack_.

I hope this makes things a little clearer ;) I think the correct term for *+, 
++, ?+ etc is "possessive" quantifiers, I'm just not sure.

-- 
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 6 83 87 78 75
Tel : +33 (0) 1 78 94 55 52
fge@xxxxxxxxxxxx
40 avenue Raymond Poincaré
75116 Paris
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux