bug#6843: grep-mode and filenames with colons

[npostavs@users.sourceforge.net]

On Wed, Jul 26, 2017 at 12:58 PM, Dmitry Gutov <dgutov@yandex.ru> wrote:
>
>> +*** Grep commands will now use GNU grep's '--null' option if
>> +available, which allows distinguishing the filename from contents if
>> +they contain colons.  This can be controlled by the new custom option
>> +'grep-use-null-filename-separator'.
>
>
> Why do the want the option?
>
> And on the same note, are there any versions of Grep in widespread usage
> that don't support '--null'? AFAICT this flag was added to GNU Grep 2.4
> which was released in 1999.

As noted in the emacs-devel thread, non-GNU greps don't support it.

>> +(defconst grep--regexp-alist-bin-matcher
>> +  '("^Binary file \\(.+\\) matches$" 1 nil nil 0 1))
>> +(defconst grep-with-null-regexp-alist
>> +  `(("^\\([^\0]+\\)\\(\0\\)\\([0-9]+\\):" 1 3 ,grep--regexp-alist-column
>> nil nil
>
>
> Any reason to change 2 to 3? Why don't we use a non-capturing group for \0
> here?

It's on the next line, I capture the \0 so as to display it with a nicer
string than "^@".

>> +     (2 '(face unspecified display ":")))

> If the numbers are the same, we could keep the variable's name the same as
> well. As a result, most third-party code would continue to simply work.

Might be worth using explicitly numbered groups to keep the numbers for
FILE and COLUMN the same though.

>> +    ,grep--regexp-alist-bin-matcher)
>> +  "Regexp used to match grep hits.
>> +See `compilation-error-regexp-alist'.")
>> +(defconst grep-fallback-regexp-alist
>
>
> Compensating for the multitude of variables by eliminating newlines between
> them doesn't look too hot to me.

Hmm yeah, I think I had them originally as let-bindings, and then I
forgot to space them out when converting to defconst.