problem with recent change to grep-regexp-alist

problem with recent change to grep-regexp-alist

[Emanuele Giaquinta]

Hi,

In the 1.42 revision of grep.el the subpattern for the filename in the
regexps of the first two grep-regexp-alist's elements has been changed
from "\(.+?\)" to "\([^:\n]+\)". Now the matching fails if the
filename contains a colon, while the previous value worked, thanks to the
non greedy "+?" quantifier. Note that the regexp of the third
grep-regexp-alist's element is still correct, and is the one that
matches if grep-highlight-matches's value is "t" (which is the
default).

Emanuele Giaquinta

Re: problem with recent change to grep-regexp-alist

[Juri Linkov]

> In the 1.42 revision of grep.el the subpattern for the filename in the
> regexps of the first two grep-regexp-alist's elements has been changed
> from "\(.+?\)" to "\([^:\n]+\)". Now the matching fails if the
> filename contains a colon, while the previous value worked, thanks to the
> non greedy "+?" quantifier. Note that the regexp of the third
> grep-regexp-alist's element is still correct, and is the one that
> matches if grep-highlight-matches's value is "t" (which is the
> default).

Ok, let's use "\(.+?\)".

You can still get wrong matches with the file names like "abc:123",
but perhaps such file names are rare.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: problem with recent change to grep-regexp-alist

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>> In the 1.42 revision of grep.el the subpattern for the filename in the
>> regexps of the first two grep-regexp-alist's elements has been changed
>> from "\(.+?\)" to "\([^:\n]+\)". Now the matching fails if the
>> filename contains a colon, while the previous value worked, thanks to the
>> non greedy "+?" quantifier. Note that the regexp of the third
>> grep-regexp-alist's element is still correct, and is the one that
>> matches if grep-highlight-matches's value is "t" (which is the
>> default).
>
> Ok, let's use "\(.+?\)".
>
> You can still get wrong matches with the file names like "abc:123",
> but perhaps such file names are rare.

Maybe \([A-Za-z]:\| ...
or something?  It is not like there are many Unix file names starting
with a single letter followed by colon.

But Linux has file names like

/proc/driver/uhci/0000:00:07.2

which might not be terribly relevant, but better safe than sorry...

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: problem with recent change to grep-regexp-alist

[Emanuele Giaquinta]

> > Ok, let's use "\(.+?\)".
> >
> > You can still get wrong matches with the file names like "abc:123",
> > but perhaps such file names are rare.
> 
> Maybe \([A-Za-z]:\| ...
> or something?  It is not like there are many Unix file names starting
> with a single letter followed by colon.
> 
> But Linux has file names like
> 
> /proc/driver/uhci/0000:00:07.2

For those files the matching will be fine.
The wrong matches occur when the filename contains somewhere the
pattern ":[0-9]+:" or ends with the pattern ":[0-9]+" (like Juri's example)
Juri, wouldn't be good to add a comment about this in grep.el or grep.txt?

Re: problem with recent change to grep-regexp-alist

[Juri Linkov]

>> > Ok, let's use "\(.+?\)".
>> >
>> > You can still get wrong matches with the file names like "abc:123",
>> > but perhaps such file names are rare.
>> 
>> Maybe \([A-Za-z]:\| ...
>> or something?  It is not like there are many Unix file names starting
>> with a single letter followed by colon.
>> 
>> But Linux has file names like
>> 
>> /proc/driver/uhci/0000:00:07.2
>
> For those files the matching will be fine.

It can't be fine, because the grep output is ambiguous.  For example,
for the grep output line:

1:2:3:4:text

there are three different interpretations:

file name `1:2:3', line number `4', source line `text'
file name `1:2', line number `3', source line `4:text'
file name `1', line number `2', source line `3:4:text'

One way to resolve them is to match markup escape sequences that new
GNU grep puts around file names and line numbers.  You can see them in
grep.txt under the title `GNU grep 2.5.1-cvs with default colors'.

> The wrong matches occur when the filename contains somewhere the
> pattern ":[0-9]+:" or ends with the pattern ":[0-9]+" (like Juri's example)
> Juri, wouldn't be good to add a comment about this in grep.el or grep.txt?

Since Richard doesn't want to document even `-n' option in grep.el,
I am not sure I can add a comment in grep.el about such rare cases
with numbers and colons in the file name.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: problem with recent change to grep-regexp-alist

[Emanuele Giaquinta]

>>> But Linux has file names like
>>>
>>> /proc/driver/uhci/0000:00:07.2
>>
>> For those files the matching will be fine.
>
> It can't be fine, because the grep output is ambiguous.

Yes, I've misread the filename (seen only a colon); this is the first
case I mentioned, when the filename includes the ":[0-9]+:" pattern.

> For example, for the grep output line:
>
> 1:2:3:4:text
>
> there are three different interpretations:
>
> file name `1:2:3', line number `4', source line `text'
> file name `1:2', line number `3', source line `4:text'
> file name `1', line number `2', source line `3:4:text'

But, using the non greedy '+?' quantifier, the interpretation will
always be of the last type.

> One way to resolve them is to match markup escape sequences that new
> GNU grep puts around file names and line numbers.  You can see them in
> grep.txt under the title `GNU grep 2.5.1-cvs with default colors'.

I'm aware of them, are you waiting for the 2.5.2 release to add the
corresponding element to grep-regexp-alist?

-- 
Emanuele Giaquinta

Re: problem with recent change to grep-regexp-alist

[Juri Linkov]

>> One way to resolve them is to match markup escape sequences that new
>> GNU grep puts around file names and line numbers.  You can see them in
>> grep.txt under the title `GNU grep 2.5.1-cvs with default colors'.
>
> I'm aware of them, are you waiting for the 2.5.2 release to add the
> corresponding element to grep-regexp-alist?

I am not sure it's good to recognize rare cases at the cost of the
overhead of processing these additional escape sequences for file
names and line numbers.  But this is possible with

GREP_COLORS='mt=01;31:fn=35:ln=32:bn=:se=:ml=36:cx=37:ne'

and the regexp

    ("^\\(\033\\[35m\\(.+?\\)\033\\[m.*?\033\\[32m\\([0-9]+\\)\033\\[m.*?\033\\[36m\\).*?\
\\(\033\\[01;31m\\(?:\033\\[K\\)?\\)\\(.*?\\)\\(\033\\[[0-9]*m\\)"
     2 3
     ;; Calculate column positions (beg . end) of first grep match on a line
     ((lambda ()
	(setq compilation-error-screen-columns nil)
        (- (match-beginning 4) (match-end 1)))
      .
      (lambda () (- (match-end 5) (match-end 1)
		    (- (match-end 4) (match-beginning 4)))))
     nil 1)

But it still doesn't fontifify grep matches correctly because other
font-lock rules interfere.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: problem with recent change to grep-regexp-alist

[Stefan Monnier]

>> In the 1.42 revision of grep.el the subpattern for the filename in the
>> regexps of the first two grep-regexp-alist's elements has been changed
>> from "\(.+?\)" to "\([^:\n]+\)". Now the matching fails if the
>> filename contains a colon, while the previous value worked, thanks to the
>> non greedy "+?" quantifier. Note that the regexp of the third
>> grep-regexp-alist's element is still correct, and is the one that
>> matches if grep-highlight-matches's value is "t" (which is the
>> default).

> Ok, let's use "\(.+?\)".

> You can still get wrong matches with the file names like "abc:123",
> but perhaps such file names are rare.

It doesn't matter whether they're rare or not: they result in ambiguous
output from grep, so in such cases Emacs can't be sure to get it right.
I.e. the .+? regexp is as good as it gets: when it's not ambiguous it works
right, and when it's ambiguous it chooses one of the possibilities
"arbitrarily".


        Stefan