William Duclot writes:
>> Yup, thanks. Isn't that what I queued as 0719f3ee (userdiff: add
>> built-in pattern for CSS, 2016-06-03)?
>
> It is, my bad
Not your bad at all. I am leaky and was asking you to double check;
it was entirely possible that I
On Mon, Jun 06, 2016 at 11:00:38AM -0700, Junio C Hamano wrote:
> William Duclot writes:
>
> > On Fri, Jun 03, 2016 at 08:50:50AM -0700, Junio C Hamano wrote:
> >> William Duclot writes:
> >>
> >> > Here I have to
William Duclot writes:
> On Fri, Jun 03, 2016 at 08:50:50AM -0700, Junio C Hamano wrote:
>> William Duclot writes:
>>
>> > Here I have to disagree (with you and Junio): the IPATTERN is
>> > case-insensitive only on
On Fri, Jun 03, 2016 at 08:50:50AM -0700, Junio C Hamano wrote:
> William Duclot writes:
>
> > Here I have to disagree (with you and Junio): the IPATTERN is
> > case-insensitive only on the "pattern" regex, not the "word_regex"
> > regex.
>
> Ahh, OK.
Am 03.06.2016 um 14:32 schrieb William Duclot:
CSS is widely used, motivating it being included as a built-in pattern.
It must be noted that the word_regex for CSS (i.e. the regex defining
what is a word in the language) does not consider '.' and '#' characters
(in CSS selectors) to be part of
William Duclot writes:
> Here I have to disagree (with you and Junio): the IPATTERN is
> case-insensitive only on the "pattern" regex, not the "word_regex"
> regex.
Ahh, OK. Obviously both of us overlooked that. Thanks for pushing
back.
> On the
CSS is widely used, motivating it being included as a built-in pattern.
It must be noted that the word_regex for CSS (i.e. the regex defining
what is a word in the language) does not consider '.' and '#' characters
(in CSS selectors) to be part of the word. This behavior is documented
by the test
On Fri, Jun 03, 2016 at 07:52:45AM +0200, Johannes Sixt wrote:
> Am 03.06.2016 um 00:48 schrieb William Duclot:
>>Logic behind the "pattern" regex is:
>
> The name of the macro parameter is "pattern", but the actual meaning
> is "function name" regex.
>
>>diff --git
Am 03.06.2016 um 08:41 schrieb Matthieu Moy:
Rejecting colon anywhere in the line would also reject valid patterns
like this:
a:hover {
Rejecting it at end of line is probably a good trade-off.
Good point. Could be worth another test case.
-- Hannes
--
To unsubscribe from this list: send
Johannes Sixt writes:
>> +IPATTERN("css",
>> + "!^.*;\n"
>
> Is there a difference between this and "!;\n"? Is it necessary to
> anchor the pattern at the beginning of the line?
Also, you don't want to force the end of line right after ;. I know
trailing whitespaces are evil,
Am 03.06.2016 um 00:48 schrieb William Duclot:
Logic behind the "pattern" regex is:
The name of the macro parameter is "pattern", but the actual meaning is
"function name" regex.
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index e3b1de8..81f60ad 100644
William Duclot writes:
> diff --git a/userdiff.c b/userdiff.c
> index 6bf2505..00fc3bf 100644
> --- a/userdiff.c
> +++ b/userdiff.c
> @@ -148,6 +148,18 @@ PATTERNS("csharp",
>"[a-zA-Z_][a-zA-Z0-9_]*"
>
CSS is widely used, motivating it being included as a built-in pattern.
It must be noted that the word_regex for CSS (i.e. the regex defining
what is a word in the language) does not consider '.' and '#' characters
(in CSS selectors) to be part of the word. This behavior is documented
by the test
Junio C Hamano writes:
> William Duclot writes:
>
>> As the CSS pattern
>> does not deal with letters at all it seemed sensible to me to follow
>> the example of the HTML pattern, which use PATTERNS().
>
> Did you notice that HTML
Am 24.05.2016 um 16:25 schrieb William Duclot:
> +PATTERNS("css",
> + "^([^,{}]+)((,[^}]*\\{)|([ \t]*\\{))$",
This hunk header pattern is a bit too restrictive for my taste. Find
below a few more test cases that you should squash in. One case fails
because only the first CSS selector is
William Duclot writes:
> I did have considered IPATTERN(), but assumed that case-sensitive was
> default and case-insensitive was the exception.
Don't assume, but ask ;-)
> As the CSS pattern
> does not deal with letters at all it seemed sensible to me
> It is not a big deal for a small single-patch topic like this, but
> it often is hard to reviewers if you do not respond to comments you
> received and instead just send a new version of the patch with
> "changes since..." comment. Please make it a habit to do both.
Apologies, I am not quite
William Duclot writes:
> CSS is widely used, motivating it being included as a built-in pattern.
>
> It must be noted that the word_regex for CSS (i.e. the regex defining
> what is a word in the language) does not consider '.' and '#' characters
> (in CSS
CSS is widely used, motivating it being included as a built-in pattern.
It must be noted that the word_regex for CSS (i.e. the regex defining
what is a word in the language) does not consider '.' and '#' characters
(in CSS selectors) to be part of the word. This behavior is documented
by the test
William Duclot writes:
> CSS is widely used, motivating it being included as a built-in pattern.
>
> It must be noted that the word_regex for CSS (i.e. the regex defining
> what is a word in the language) does not consider '.' and '#' characters
> (in CSS
CSS is widely used, motivating it being included as a built-in pattern.
It must be noted that the word_regex for CSS (i.e. the regex defining
what is a word in the language) does not consider '.' and '#' characters
(in CSS selectors) to be part of the word. This behavior is documented
by the test
21 matches
Mail list logo