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

[dapfy@t-online.de (Daniel Pfeiffer)]

Hi Juri,

Juri Linkov <juri@jurta.org> skribis:

> Daniel Pfeiffer <occitan@esperanto.org> writes:
> > 	(grep-regexp-alist): Give it the full functionality of gnu style
> > 	compilation messages with line and column ranges.  Ask me for the
> > 	perl script I'm working on, that uses these.
> 
> Requiring Emacs users to use a perl script is not a good solution.

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.

Besides showing column numbers it has some other nice features, like
multi-line matches.  And it doesn't plonk a 98-character long file-name before
some deeply buried file.  Instead it uses compile's recognition of "Entering
directory" lines, to only give the file name.

There's also the possibilty to act upon the file contents with a perl
expression.  This allows you to drop out of files, e.g. if the first line
doesn't look like #! /usr/bin/perl or whatever.  Or you can massage the lines
to eliminate comments or ignore lines in certain sections, like perl's pod
(=xyz ... =cut or EOF).

> But what about using the match highlighting feature of GNU grep?
> With some changes in `compilation-mode-font-lock-keywords' and
> `compilation-error-properties' this will allow to call functions
> to compute columns of matches marked by grep.

Without having tried it yet, this looks like an interesting approach. 
Somebody
had suggested parsing the grep command and creating font-lock-keywords based
on what I think grep matched.  Your approach is much more elegant and bound to
be correct!

+   
("^\\(.+?\\)[:(]+\\([0-9]+\\)\\([:)]\\)[^\033\n]*\033\\[01;41m\\([^\033\n]*\\
)\033\\[00m" 1 2

This won't work if the line contains an ESC before or within the match. 
Better would be

("^\\(.+?\\)[:(]+\\([0-9]+\\)\\([:)]\\).*?\033\\[01;41m\\(.*?\\)\033\\[00m" 1
2

> +     ("\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.

And you don't need to match them twice.  Instead you could additionally put
normal font-lock HIGHLIGHTs into your grep-regexp-alist rule: (REGEXP FILE
[LINE COLUMN TYPE HYPERLINK HIGHLIGHT...]).  Something like '(face nil
invisble t intangible t).

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / lär dig / ucz się    Esperanto:
                              http://lernu.net/