bug#7378: 23.2; grep buffer misinterprets result if filename contains colon character

[Juri Linkov <juri@jurta.org>]

> I.e. to resolve this kind of ambiguity, grep-mode would have to check
> all the possible interpretations and see which ones lead to an existing
> file name.  Such a change would require a good bit more work on grep.
> Furthermore such ambiguity would need to be resolved not only when
> the ":N:" comes from the file name but also when it comes from the
> file's content.

One more case where highlighting is currently incorrect is grepping mail
archives where each mail is located in a separate file with the timestamp
in its name like:

grep -inH -e "Date: " *
2011-08-31_11:57:03_1:7:Date: Wed, 31 Aug 2011 11:57:03 +0000
2011-08-31_12:08:20_2:7:Date: Wed, 31 Aug 2011 12:08:20 +0000

In the first line "2011-08-31_11" is highlighted as the file name and
"57" as the line number.  In the second line "2011-08-31_12:08:20_2" is
highlighted as the file name (correctly) and "7" as the line number
(the difference is because "03" has the leading zero).

I see no way to match file names and line numbers correctly
with a regexp in such cases.

The only way to do this reliably with GNU grep is to ask it to output
escape sequences around file names and line numbers.  From `man grep':

  fn=35 SGR substring for file names prefixing any content line.
  The default is a magenta text foreground over the terminal's
  default background.

  ln=32 SGR substring for line numbers prefixing any content line.
  The default is a green text foreground over the terminal's
  default background.

Then `grep-filter' could find these escape sequences and highlight,
and `grep-regexp-alist' could calculate column positions of the highlighted
file names and line numbers.

Is it worth a try?