Re: Changes to emacs/lisp/progmodes/grep.el

[Juri Linkov <juri@jurta.org>]

dapfy@t-online.de (Daniel Pfeiffer) writes:
> I'm not requiring them to just, as Emacs doesn't require GNU grep, which sadly
> is not omnipresent.  Instead grep.el bends over backwards in horrible ways to
> get something out of simple greps and find.  Mine is just an alternative that
> might or might not be distributed with Emacs.  Being in Perl it has the
> advantage of running as is on very many machines -- no compilation needed.

Perl is definitely superior in its capabilities to grep.  You can
implement many useful search extensions in Perl.  If you make your
Perl script available either within Emacs or separately, many people
might find it useful.  But I think we should also try to exploit the
ability of GNU grep to mark matches by escape sequences.  This means
that `grep-regexp-alist' could have two entries: one for a regexp with
explicit column numbers, and one for matching escape sequences from
GNU grep.

>> +     ("\033\\[01;41m\\([^\033\n]*\\)\033\\[00m"
>> +      (1 (list 'face compilation-column-face
>> +               'font-lock-face compilation-column-face) t)
>> +      ((lambda (p))
>> +       (progn (delete-region (match-end       1) (match-end       0))
>> +              (delete-region (match-beginning 0) (match-beginning 1))))))
>
> This part is bad, because you are removing the basis for the column
> determination.  So if you save the *grep* buffer, you won't get the same
> result when reloading it.  Likewise if you modify the line.  Instead you
> should put an 'invisble and maybe 'intangible property on the escape sequence.

Invisible text often produces unexpected effects, e.g. a search fails
on invisible escape sequences, copying the text reveals the hidden parts
and copies them too...

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