Re: grep.el regexp

Re: grep.el regexp

[Richard Stallman]

    I guess the original regexp was created to match different grep output
    formats.  From this regexp I can deduce such formats that use space or
    tab as a separator between file name, line number and source line.

    I can't tell is it right to drop support for those formats.

I think that if we wrote a separate regexp for each kind of grep, all
together they would match a lot fewer different strings than the
current regexp does, and they would be much easier to understand.

Re: grep.el regexp

[Juri Linkov]

> I think that if we wrote a separate regexp for each kind of grep,
> all together they would match a lot fewer different strings than the
> current regexp does, and they would be much easier to understand.

This approach has one problem: different rules in grep-regexp-alist
are not mutually exclusive, so information from different regexps can
appear in grep buffers from similar regexps.  In the worst case
this can cause subsequent calls of `next-error' revisiting the
same source line several times for each of separate regexps.

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

Re: grep.el regexp

[Richard M. Stallman]

    This approach has one problem: different rules in grep-regexp-alist
    are not mutually exclusive, so information from different regexps can
    appear in grep buffers from similar regexps.  In the worst case
    this can cause subsequent calls of `next-error' revisiting the
    same source line several times for each of separate regexps.

If that can happen, it is a bug in compile.el.
It should never find more than one match on any given line.

Re: grep.el regexp

[Juri Linkov]

>     This approach has one problem: different rules in grep-regexp-alist
>     are not mutually exclusive, so information from different regexps can
>     appear in grep buffers from similar regexps.  In the worst case
>     this can cause subsequent calls of `next-error' revisiting the
>     same source line several times for each of separate regexps.
>
> If that can happen, it is a bug in compile.el.
> It should never find more than one match on any given line.

Currently it puts information from different rules on the same line
when regexps cover different parts of that line (it works this way due
to the font-lock algorithms).

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

Re: grep.el regexp

[Stefan Monnier]

> Currently it puts information from different rules on the same line
> when regexps cover different parts of that line (it works this way due
> to the font-lock algorithms).

And that's correct the thing to do since lines can contain
several messages.


        Stefan

Re: grep.el regexp

[Richard M. Stallman]

    > Currently it puts information from different rules on the same line
    > when regexps cover different parts of that line (it works this way due
    > to the font-lock algorithms).

    And that's correct the thing to do since lines can contain
    several messages.

How so?  Can you show me an example?

Re: grep.el regexp

[Stefan Monnier]

>> Currently it puts information from different rules on the same line
>> when regexps cover different parts of that line (it works this way due
>> to the font-lock algorithms).

>     And that's correct the thing to do since lines can contain
>     several messages.

> How so?  Can you show me an example?

TeX uses "(<filename>" to say "I'm now beginning to process <filename>" and
then ")" to say "I'm done processing the current file, popping to the
previous one".  So you can have messages like

     (file1 (file2 (file3

     L. 321 Error blabla

     foobar)))


The first line has thus 3 messages which compile.el should notice.
I'm sure there are other examples,


        Stefan

Re: grep.el regexp

[Richard M. Stallman]

	 (file1 (file2 (file3

	 L. 321 Error blabla

	 foobar)))

    The first line has thus 3 messages which compile.el should notice.

Here's what brought up this issue.

>     This approach has one problem: different rules in grep-regexp-alist
>     are not mutually exclusive, so information from different regexps can
>     appear in grep buffers from similar regexps.  In the worst case
>     this can cause subsequent calls of `next-error' revisiting the
>     same source line several times for each of separate regexps.

The example you showed is not an example of THAT.  You're talking
about three disjoint matches in the same line.

So while this could be an example where it is valid to have
multiple matches on the same line, it's only valid because they
match disjoint parts of the same line.

I am not sure whether that relates to the suggestion I made:

> I think that if we wrote a separate regexp for each kind of grep,
> all together they would match a lot fewer different strings than the
> current regexp does, and they would be much easier to understand.

Re: grep.el regexp

[Stefan Monnier]

> The example you showed is not an example of THAT.  You're talking
> about three disjoint matches in the same line.

> So while this could be an example where it is valid to have
> multiple matches on the same line, it's only valid because they
> match disjoint parts of the same line.

> I am not sure whether that relates to the suggestion I made:

>> I think that if we wrote a separate regexp for each kind of grep,
>> all together they would match a lot fewer different strings than the
>> current regexp does, and they would be much easier to understand.

Indeed, the two do not conflict.  I.e. I think there's no problem with
compile.el's current behavior in this regard and I believe your suggestion
w.r.t grep.el should work just fine.


        Stefan

Re: grep.el regexp

[Richard M. Stallman]

    > I am not sure whether that relates to the suggestion I made:

    >> I think that if we wrote a separate regexp for each kind of grep,
    >> all together they would match a lot fewer different strings than the
    >> current regexp does, and they would be much easier to understand.

    Indeed, the two do not conflict.  I.e. I think there's no problem with
    compile.el's current behavior in this regard and I believe your suggestion
    w.r.t grep.el should work just fine.

Would someone like to try implementing this?
(Please respond to this message, if so.)

Re: grep.el regexp

[Richard M. Stallman]

[I sent this message a few weeks ago but did not get a response.
Could we get the discussion moving again?]

    > I am not sure whether that relates to the suggestion I made:

    >> I think that if we wrote a separate regexp for each kind of grep,
    >> all together they would match a lot fewer different strings than the
    >> current regexp does, and they would be much easier to understand.

    Indeed, the two do not conflict.  I.e. I think there's no problem with
    compile.el's current behavior in this regard and I believe your suggestion
    w.r.t grep.el should work just fine.

Would someone like to try implementing this?
(Please respond to this message, if so.)

Re: grep.el regexp

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 1267 bytes --]

> [I sent this message a few weeks ago but did not get a response.
> Could we get the discussion moving again?]
>
>     > I am not sure whether that relates to the suggestion I made:
>
>     >> I think that if we wrote a separate regexp for each kind of grep,
>     >> all together they would match a lot fewer different strings than the
>     >> current regexp does, and they would be much easier to understand.
>
>     Indeed, the two do not conflict.  I.e. I think there's no problem with
>     compile.el's current behavior in this regard and I believe your suggestion
>     w.r.t grep.el should work just fine.
>
> Would someone like to try implementing this?
> (Please respond to this message, if so.)

Perhaps what is needed to start with is to ask people to send output
examples of different kinds of grep.  We could put these example in a
new file etc/grep.txt similarly to etc/compilation.txt.

I've collected a few examples in the file attached below.  The section
`grep ???' contains examples deduced from regexps in `grep-regexp-alist'.
Could someone recognize what grep produces them?

Also you can see that with recent changes in GNU grep CVS it produces
escape sequences not handled by grep.el.  This requires a separate rule
in `grep-regexp-alist'.


[-- Attachment #2: grep.txt --]
[-- Type: text/plain, Size: 1716 bytes --]

* Introduction  -*-grep-*-

This shows the different kinds of messages grep recognizes by default and
how they are rendered.  It is intended both to help you decide which matchers
you need and as a test of the matchers.  Move the mouse over a colored part or
use `compilation-message-face', to see how much text was actually matched.


* GNU grep 2.5.1

grep -nH -e "xyzxyz" *
emacs-2:1205:inserts `xyzxyzxyzxyz' in the current buffer.

* GNU grep 2.5.1 without line numbers

grep -e "xyzxyz" *
emacs-2:inserts `xyzxyzxyzxyz' in the current buffer.

* GNU grep 2.5.1 with color matches

grep -nH --color=always -e "xyzxyz" *
emacs-2:1205:inserts `^[[01;31mxyzxyz^[[00m^[[01;31mxyzxyz^[[00m' in the current buffer.

* GNU grep 2.5.1-cvs

grep -nH --color=always -e "xyzxyz" *
^[[35m^[[Kemacs-2^[[m^[[K^[[36m^[[K:^[[m^[[K^[[32m^[[K1205^[[m^[[K^[[36m^[[K:^[[m^[[Kinserts `^[[01;31m^[[Kxyzxyz^[[m^[[K^[[01;31m^[[Kxyzxyz^[[m^[[K' in the current buffer.

* agrep

agrep -n "xyzxyz" *
emacs-2: 1205: inserts `xyzxyzxyzxyz' in the current buffer.

* sgrep

sgrep -l '"xyzxyz"' *
------------- #1 emacs-2: 6 (6641933,6641938 : 50542,50547)
xyzxyz
------------- #2 emacs-2: 6 (6641936,6641941 : 50545,50550)
xyzxyz
------------- #3 emacs-2: 6 (6641939,6641944 : 50548,50553)
xyzxyz

* grep ???

grep -nH -e "xyzxyz" *
emacs-2:1205:9:inserts `xyzxyzxyzxyz' in the current buffer.
emacs-2:1205:9-15:inserts `xyzxyzxyzxyz' in the current buffer.
emacs-2:1205.9-1205.9:inserts `xyzxyzxyzxyz' in the current buffer.
emacs-2 1205.9-15 inserts `xyzxyzxyzxyz' in the current buffer.
emacs-2 1205.9-1205.9 inserts `xyzxyzxyzxyz' in the current buffer.
emacs-2 1205 inserts `xyzxyzxyzxyz' in the current buffer.

[-- Attachment #3: Type: text/plain, Size: 45 bytes --]


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

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: grep.el regexp

[Richard M. Stallman]

    Perhaps what is needed to start with is to ask people to send output
    examples of different kinds of grep.  We could put these example in a
    new file etc/grep.txt similarly to etc/compilation.txt.

That is a good idea.  Please start that file.

    I've collected a few examples in the file attached below.  The section
    `grep ???' contains examples deduced from regexps in `grep-regexp-alist'.
    Could someone recognize what grep produces them?

The first three seem to follow the GNU spec for column numbers
and ranges.  I don't know whether GNU grep can output these,
but in principle it could do so.

Re: grep.el regexp

[Juri Linkov]

>     I've collected a few examples in the file attached below.  The section
>     `grep ???' contains examples deduced from regexps in `grep-regexp-alist'.
>     Could someone recognize what grep produces them?
>
> The first three seem to follow the GNU spec for column numbers
> and ranges.  I don't know whether GNU grep can output these,
> but in principle it could do so.

With `-b' option GNU grep can output the byte offset of the beginning
of the matching line counting from the beginning of the file, e.g.:

emacs-2:1205:50533:inserts `xyzxyzxyzxyz' in the current buffer.

This format resembles the output of column numbers, but it is not.
It misleads grep.el into interpreting it as a column number.

AFAIK, currently GNU grep doesn't support column number output.

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

Re: grep.el regexp

[Richard M. Stallman]

    With `-b' option GNU grep can output the byte offset of the beginning
    of the matching line counting from the beginning of the file, e.g.:

    emacs-2:1205:50533:inserts `xyzxyzxyzxyz' in the current buffer.

    This format resembles the output of column numbers, but it is not.
    It misleads grep.el into interpreting it as a column number.

    AFAIK, currently GNU grep doesn't support column number output.

It would be rather difficult to handle this byte-count
in Emacs, given the complexities of character set decoding.
So I think we should forget about that.

Meanwhile, if GNU grep doesn't support the column number output,
chances are no other does, and there's no reason for grep.el to
handle that output.  I would guess that it got copied into grep.el
from compile.el and that it was implemented for the sake of some
GCC front ends that do or might someday output this.

So in making this change in grep.el, those formats can be ignored.

Re: grep.el regexp

[Juri Linkov]

Please find below a patch that removes recognition of all grep formats
except those listed in etc/grep.txt.

I'm also tempted to add recognition of column numbers for possible
search scripts that outputs them, with the rule:

 ("^\\([^:\n]+\\)\\(:[ \t]*\\)\\([0-9]+\\)\\2\\(?:\\([0-9]+\\)\\(?:-\\([0-9]+\\)\\)?\\2\\)?"
  1 3 (4 . 5))

but it will recognize lines with the leading number and colon as the
column number (look the example in etc/grep.txt).  This wouldn't be
a problem if fontification was able to skip already fontified lines,
and not to apply the rule with column numbers when the rule that
accepts escape sequences for column calculation was applied.
But I haven't found a way to do that.

Index: lisp/progmodes/grep.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/progmodes/grep.el,v
retrieving revision 1.39
diff -u -r1.39 grep.el
--- lisp/progmodes/grep.el	19 Jul 2005 14:21:23 -0000	1.39
+++ lisp/progmodes/grep.el	19 Jul 2005 15:54:54 -0000
@@ -248,13 +248,8 @@
 
 ;;;###autoload
 (defvar grep-regexp-alist
-  ;; rms: I removed the code to match parens around the line number
-  ;; because it causes confusion and so we will find out if anyone needs it.
-  ;; It causes confusion with a file name that contains a number in parens.
-  '(("^\\(.+?\\)\\([: \t]\\)+\
-\\([0-9]+\\)\\([.:]?\\)\\([0-9]+\\)?\
-\\(?:-\\(?:\\([0-9]+\\)\\4\\)?\\.?\\([0-9]+\\)?\\)?\\2"
-     1 (3 . 6) (5 . 7))
+  '(("^\\([^:\n]+\\)\\(:[ \t]*\\)\\([0-9]+\\)\\2"
+     1 3)
     ("^\\(\\(.+?\\):\\([0-9]+\\):\\).*?\
 \\(\033\\[01;31m\\(?:\033\\[K\\)?\\)\\(.*?\\)\\(\033\\[[0-9]*m\\)"
      2 3
@@ -283,6 +278,9 @@
 (defvar grep-match-face	'match
   "Face name to use for grep matches.")
 
+(defvar grep-context-face 'shadow
+  "Face name to use for grep context lines.")
+
 (defvar grep-mode-font-lock-keywords
    '(;; Command output lines.
      ("^\\([A-Za-z_0-9/\.+-]+\\)[ \t]*:" 1 font-lock-function-name-face)
@@ -297,6 +295,7 @@
       (0 '(face nil message nil help-echo nil mouse-face nil) t)
       (1 compilation-warning-face)
       (2 compilation-line-face))
+     ("^[^\n-]+-[0-9]+-.*" (0 grep-context-face))
      ;; Highlight grep matches and delete markers
      ("\\(\033\\[01;31m\\)\\(.*?\\)\\(\033\\[[0-9]*m\\)"
       ;; Refontification does not work after the markers have been

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

Re: grep.el regexp

[Richard M. Stallman]

    but it will recognize lines with the leading number and colon as the
    column number (look the example in etc/grep.txt).

I don't see any lines in grep.txt which start with a number and a
colon.  So I don't understand this at all.  Would you please show
those lines you mean, instead of just describing them?

      This wouldn't be
    a problem if fontification was able to skip already fontified lines,
    and not to apply the rule with column numbers when the rule that
    accepts escape sequences for column calculation was applied.

I think there is a way to do that, but I never fully understood
all the details of these specs.  Maybe someone else knows it.

Re: grep.el regexp

[Juri Linkov]

>     but it will recognize lines with the leading number and colon as the
>     column number (look the example in etc/grep.txt).
>
> I don't see any lines in grep.txt which start with a number and a
> colon.  So I don't understand this at all.  Would you please show
> those lines you mean, instead of just describing them?

I meant matching lines which start with a number and a colon in source
files, not in grep.txt.  In grep.txt an example of such case is:

grep -nH -e "Universal Time" ../lispref/*
../lispref/os.texi:1010:0:00 January 1, 1970 UTC (Coordinated ^[[01;31mUniversal Time^[[00m)

================== ==== ====================================================================
file name         line# matching line

where the file `../lispref/os.texi' contains the line:

0:00 January 1, 1970 UTC (Coordinated ^[[01;31mUniversal Time^[[00m)

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

Re: grep.el regexp

[Richard M. Stallman]

    I meant matching lines which start with a number and a colon in source
    files, not in grep.txt.

Now I see what you mean.  I guess the simplest solution
is not to implement column numbers in grep.el or in grep.

Re: grep.el regexp

[Juri Linkov]

After adding the underline attribute to compilation and grep faces
now some non-navigational messages are displayed as links.  This is
misleading.  Please see examples of such messages in the section
`* Miscellaneous' in etc/compilation.txt, and `* GNU grep 2.5.1:
other messages' in etc/grep.txt, and try to move the mouse pointer
over link-like underlined parts.

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

Re: grep.el regexp

[Richard M. Stallman]

    After adding the underline attribute to compilation and grep faces
    now some non-navigational messages are displayed as links.  This is
    misleading.  Please see examples of such messages in the section
    `* Miscellaneous' in etc/compilation.txt, and `* GNU grep 2.5.1:
    other messages' in etc/grep.txt, and try to move the mouse pointer
    over link-like underlined parts.

I fixed most of this, but 

    Binary file 2005-06 matches

still matches wrong.  Can you debug that?

Re: grep.el regexp

[Juri Linkov]

>     After adding the underline attribute to compilation and grep faces
>     now some non-navigational messages are displayed as links.  This is
>     misleading.  Please see examples of such messages in the section
>     `* Miscellaneous' in etc/compilation.txt, and `* GNU grep 2.5.1:
>     other messages' in etc/grep.txt, and try to move the mouse pointer
>     over link-like underlined parts.
>
> I fixed most of this, but 
>
>     Binary file 2005-06 matches
>
> still matches wrong.  Can you debug that?

This is already fixed with my latest patch.

But I see now that fontification of compilation messages has
degraded compared to earlier versions.  The process exit status
is no more distinguished by a different color (where green was used
for successful, and red was used for abnormally exited process),
configuration checking results have the same color for yes and no
(where green was used for yes, and red - for no).

I propose a patch that restores these colors with the following values:

In the compilation buffer:

  yes - green
  no - red
  other - orange

  Compilation finished          - green
  Compilation exited abnormally - red

In the grep buffer:

  matches found     - green
  no matches found  - orange
  exited abnormally - red

  Binary file emacs-7 matches

where emacs-7 is displayed as a file link (green underlined)

All this is achieved by adding three new face variables

  compilation-info-text-face
  compilation-warning-text-face
  compilation-error-text-face

which are variants of existing face variables, but without underlines:

Index: lisp/progmodes/compile.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/progmodes/compile.el,v
retrieving revision 1.368
diff -c -r1.368 compile.el
*** lisp/progmodes/compile.el	4 Aug 2005 01:36:10 -0000	1.368
--- lisp/progmodes/compile.el	4 Aug 2005 02:12:14 -0000
***************
*** 377,389 ****
     '(;; configure output lines.
       ("^[Cc]hecking \\(?:[Ff]or \\|[Ii]f \\|[Ww]hether \\(?:to \\)?\\)?\\(.+\\)\\.\\.\\. *\\(?:(cached) *\\)?\\(\\(yes\\(?: .+\\)?\\)\\|no\\|\\(.*\\)\\)$"
        (1 font-lock-variable-name-face)
!       (2 font-lock-keyword-face))
       ;; Command output lines.  Recognize `make[n]:' lines too.
       ("^\\([[:alnum:]_/.+-]+\\)\\(\\[\\([0-9]+\\)\\]\\)?[ \t]*:"
        (1 font-lock-function-name-face) (3 compilation-line-face nil t))
       (" --?o\\(?:utfile\\|utput\\)?[= ]?\\(\\S +\\)" . 1)
!      ("^Compilation finished" . font-lock-keyword-face)
!      ("^Compilation exited abnormally" . font-lock-keyword-face))
     "Additional things to highlight in Compilation mode.
  This gets tacked on the end of the generated expressions.")
  
--- 377,389 ----
     '(;; configure output lines.
       ("^[Cc]hecking \\(?:[Ff]or \\|[Ii]f \\|[Ww]hether \\(?:to \\)?\\)?\\(.+\\)\\.\\.\\. *\\(?:(cached) *\\)?\\(\\(yes\\(?: .+\\)?\\)\\|no\\|\\(.*\\)\\)$"
        (1 font-lock-variable-name-face)
!       (2 (compilation-text-face '(4 . 3))))
       ;; Command output lines.  Recognize `make[n]:' lines too.
       ("^\\([[:alnum:]_/.+-]+\\)\\(\\[\\([0-9]+\\)\\]\\)?[ \t]*:"
        (1 font-lock-function-name-face) (3 compilation-line-face nil t))
       (" --?o\\(?:utfile\\|utput\\)?[= ]?\\(\\S +\\)" . 1)
!      ("^Compilation finished" . compilation-info-text-face)
!      ("^Compilation exited abnormally" . compilation-error-text-face))
     "Additional things to highlight in Compilation mode.
  This gets tacked on the end of the generated expressions.")
  
***************
*** 468,473 ****
--- 468,479 ----
  ;; History of compile commands.
  (defvar compile-history nil)
  
+ (defface compilation-error
+   '((t :inherit font-lock-warning-face))
+   "Face for displaying compilation errors."
+   :group 'font-lock-highlighting-faces
+   :version "22.1")
+ 
  (defface compilation-warning
    '((((class color) (min-colors 16)) (:foreground "Orange" :weight bold))
      (((class color)) (:foreground "cyan" :weight bold))
***************
*** 487,530 ****
       (:foreground "Green" :weight bold))
      (((class color)) (:foreground "green" :weight bold))
      (t (:weight bold)))
!   "Face used to highlight compiler warnings."
    :group 'font-lock-highlighting-faces
    :version "22.1")
  ;; backward-compatibility alias
  (put 'compilation-info-face 'face-alias 'compilation-info)
  
  (defface compilation-error-file-name
!   '((default :inherit font-lock-warning-face)
      (((supports :underline t)) :underline t))
!   "Face for displaying file names in compilation errors."
    :group 'font-lock-highlighting-faces
    :version "22.1")
  
  (defface compilation-warning-file-name
!   '((default :inherit font-lock-warning-face)
      (((supports :underline t)) :underline t))
!   "Face for displaying file names in compilation errors."
    :group 'font-lock-highlighting-faces
    :version "22.1")
  
  (defface compilation-info-file-name
    '((default :inherit compilation-info)
      (((supports :underline t)) :underline t))
!   "Face for displaying file names in compilation errors."
    :group 'font-lock-highlighting-faces
    :version "22.1")
  
  (defface compilation-line-number
    '((default :inherit font-lock-variable-name-face)
      (((supports :underline t)) :underline t))
!   "Face for displaying file names in compilation errors."
    :group 'font-lock-highlighting-faces
    :version "22.1")
  
  (defface compilation-column-number
    '((default :inherit font-lock-type-face)
      (((supports :underline t)) :underline t))
!   "Face for displaying file names in compilation errors."
    :group 'font-lock-highlighting-faces
    :version "22.1")
  
--- 493,536 ----
       (:foreground "Green" :weight bold))
      (((class color)) (:foreground "green" :weight bold))
      (t (:weight bold)))
!   "Face used to highlight compiler information."
    :group 'font-lock-highlighting-faces
    :version "22.1")
  ;; backward-compatibility alias
  (put 'compilation-info-face 'face-alias 'compilation-info)
  
  (defface compilation-error-file-name
!   '((default :inherit compilation-error)
      (((supports :underline t)) :underline t))
!   "Face for displaying file names in error messages."
    :group 'font-lock-highlighting-faces
    :version "22.1")
  
  (defface compilation-warning-file-name
!   '((default :inherit compilation-warning)
      (((supports :underline t)) :underline t))
!   "Face for displaying file names in warning messages."
    :group 'font-lock-highlighting-faces
    :version "22.1")
  
  (defface compilation-info-file-name
    '((default :inherit compilation-info)
      (((supports :underline t)) :underline t))
!   "Face for displaying file names in informational messages."
    :group 'font-lock-highlighting-faces
    :version "22.1")
  
  (defface compilation-line-number
    '((default :inherit font-lock-variable-name-face)
      (((supports :underline t)) :underline t))
!   "Face for displaying line number in messages."
    :group 'font-lock-highlighting-faces
    :version "22.1")
  
  (defface compilation-column-number
    '((default :inherit font-lock-type-face)
      (((supports :underline t)) :underline t))
!   "Face for displaying column number in messages."
    :group 'font-lock-highlighting-faces
    :version "22.1")
  
***************
*** 537,560 ****
  (defvar compilation-error-face 'compilation-error-file-name
    "Face name to use for file name in error messages.")
  
  (defvar compilation-warning-face 'compilation-warning-file-name
    "Face name to use for file name in warning messages.")
  
  (defvar compilation-info-face 'compilation-info-file-name
    "Face name to use for file name in informational messages.")
  
  (defvar compilation-line-face 'compilation-line-number
    "Face name to use for line number in message.")
  
  (defvar compilation-column-face 'compilation-column-number
!   "Face name to use for column number in message.")
  
  ;; same faces as dired uses
  (defvar compilation-enter-directory-face 'font-lock-function-name-face
!   "Face name to use for column number in message.")
  
  (defvar compilation-leave-directory-face 'font-lock-type-face
!   "Face name to use for column number in message.")
  
  
  
--- 543,575 ----
  (defvar compilation-error-face 'compilation-error-file-name
    "Face name to use for file name in error messages.")
  
+ (defvar compilation-error-text-face 'compilation-error
+   "Face name to use for text of error messages.")
+ 
  (defvar compilation-warning-face 'compilation-warning-file-name
    "Face name to use for file name in warning messages.")
  
+ (defvar compilation-warning-text-face 'compilation-warning
+   "Face name to use for text of warning messages.")
+ 
  (defvar compilation-info-face 'compilation-info-file-name
    "Face name to use for file name in informational messages.")
  
+ (defvar compilation-info-text-face 'compilation-info
+   "Face name to use for text of informational messages.")
+ 
  (defvar compilation-line-face 'compilation-line-number
    "Face name to use for line number in message.")
  
  (defvar compilation-column-face 'compilation-column-number
!   "Face name to use for column number in messages.")
  
  ;; same faces as dired uses
  (defvar compilation-enter-directory-face 'font-lock-function-name-face
!   "Face name to use for entering directory messages.")
  
  (defvar compilation-leave-directory-face 'font-lock-type-face
!   "Face name to use for leaving directory messages.")
  
  
  
***************
*** 569,574 ****
--- 584,594 ----
    (or (and (car type) (match-end (car type)) compilation-warning-face)
        (and (cdr type) (match-end (cdr type)) compilation-info-face)
        compilation-error-face))
+ 
+ (defun compilation-text-face (type)
+   (or (and (car type) (match-end (car type)) compilation-warning-text-face)
+       (and (cdr type) (match-end (cdr type)) compilation-info-text-face)
+       compilation-error-text-face))
  
  ;; Internal function for calculating the text properties of a directory
  ;; change message.  The directory property is important, because it is

Index: lisp/progmodes/grep.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/progmodes/grep.el,v
retrieving revision 1.43
diff -c -r1.43 grep.el
*** lisp/progmodes/grep.el	4 Aug 2005 01:36:49 -0000	1.43
--- lisp/progmodes/grep.el	4 Aug 2005 02:12:34 -0000
***************
*** 261,267 ****
        (lambda () (- (match-end 5) (match-end 1)
  		    (- (match-end 4) (match-beginning 4)))))
       nil 1)
!     ("^Binary file \\(.+\\) matches$" 1 nil nil 1 1))
    "Regexp used to match grep hits.  See `compilation-error-regexp-alist'.")
  
  (defvar grep-error "grep hit"
--- 261,267 ----
        (lambda () (- (match-end 5) (match-end 1)
  		    (- (match-end 4) (match-beginning 4)))))
       nil 1)
!     ("^Binary file \\(.+\\) matches$" 1 nil nil 0 1))
    "Regexp used to match grep hits.  See `compilation-error-regexp-alist'.")
  
  (defvar grep-error "grep hit"
***************
*** 272,279 ****
  (defvar grep-hit-face	compilation-info-face
    "Face name to use for grep hits.")
  
! ;; compilation-error-face is wrong for this; it's designed to look like a link.
! (defvar grep-error-face	font-lock-keyword-face
    "Face name to use for grep error messages.")
  
  (defvar grep-match-face	'match
--- 272,278 ----
  (defvar grep-hit-face	compilation-info-face
    "Face name to use for grep hits.")
  
! (defvar grep-error-face	compilation-error-face
    "Face name to use for grep error messages.")
  
  (defvar grep-match-face	'match
***************
*** 290,301 ****
       ;; remove match from grep-regexp-alist before fontifying
       ("^Grep finished \\(?:(\\(matches found\\))\\|with \\(no matches found\\)\\).*"
        (0 '(face nil message nil help-echo nil mouse-face nil) t)
!       (1 font-lock-keyword-face nil t)
!       (2 font-lock-keyword-face nil t))
       ("^Grep \\(exited abnormally\\) with code \\([0-9]+\\).*"
        (0 '(face nil message nil help-echo nil mouse-face nil) t)
!       (1 grep-error-face)
!       (2 grep-error-face))
       ("^[^\n-]+-[0-9]+-.*" (0 grep-context-face))
       ;; Highlight grep matches and delete markers
       ("\\(\033\\[01;31m\\)\\(.*?\\)\\(\033\\[[0-9]*m\\)"
--- 289,300 ----
       ;; remove match from grep-regexp-alist before fontifying
       ("^Grep finished \\(?:(\\(matches found\\))\\|with \\(no matches found\\)\\).*"
        (0 '(face nil message nil help-echo nil mouse-face nil) t)
!       (1 compilation-info-text-face nil t)
!       (2 compilation-warning-text-face nil t))
       ("^Grep \\(exited abnormally\\) with code \\([0-9]+\\).*"
        (0 '(face nil message nil help-echo nil mouse-face nil) t)
!       (1 compilation-error-text-face)
!       (2 compilation-error-text-face))
       ("^[^\n-]+-[0-9]+-.*" (0 grep-context-face))
       ;; Highlight grep matches and delete markers
       ("\\(\033\\[01;31m\\)\\(.*?\\)\\(\033\\[[0-9]*m\\)"

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

Re: grep.el regexp

[Richard M. Stallman]

    But I see now that fontification of compilation messages has
    degraded compared to earlier versions.  The process exit status
    is no more distinguished by a different color (where green was used
    for successful, and red was used for abnormally exited process),
    configuration checking results have the same color for yes and no
    (where green was used for yes, and red - for no).

I changed this code so that those things would not be underlined.

Re: grep.el regexp

[Juri Linkov]

>     But I see now that fontification of compilation messages has
>     degraded compared to earlier versions.  The process exit status
>     is no more distinguished by a different color (where green was used
>     for successful, and red was used for abnormally exited process),
>     configuration checking results have the same color for yes and no
>     (where green was used for yes, and red - for no).
>
> I changed this code so that those things would not be underlined.

Those things are not underlined now, but at the cost of losing
the ability to configure their faces and to distinguish visually
negative results from positive.

My patch fixes this (and leaves their faces not underlined).

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

Re: grep.el regexp

[Richard M. Stallman]

    Those things are not underlined now, but at the cost of losing
    the ability to configure their faces and to distinguish visually
    negative results from positive.

    My patch fixes this (and leaves their faces not underlined).

Ok, now I see.  Please install it.

Re: grep.el regexp

[Juri Linkov]

>     Perhaps what is needed to start with is to ask people to send output
>     examples of different kinds of grep.  We could put these example in a
>     new file etc/grep.txt similarly to etc/compilation.txt.
>
> That is a good idea.  Please start that file.

After visiting this file in `emacs -Q -D' it fails with the error
"Ignoring unknown mode `grep-mode'".  Is it ok to add an autoload cookie
to `grep-mode'?

I also noticed that `C-h f' can't find the definition of `grep-mode'.
The second patch fixes this.

Index: lisp/progmodes/grep.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/progmodes/grep.el,v
retrieving revision 1.38
diff -c -r1.38 grep.el
*** lisp/progmodes/grep.el	4 Jul 2005 16:59:19 -0000	1.38
--- lisp/progmodes/grep.el	12 Jul 2005 06:55:11 -0000
***************
*** 514,519 ****
--- 518,524 ----
  			 command-args)
  		       'grep-mode nil highlight-regexp)))
  
+ ;;;###autoload
  (define-compilation-mode grep-mode "Grep"
    "Sets `grep-last-buffer' and `compilation-window-height'."
    (setq grep-last-buffer (current-buffer))

Index: lisp/emacs-lisp/find-func.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/emacs-lisp/find-func.el,v
retrieving revision 1.58
diff -c -r1.58 find-func.el
*** lisp/emacs-lisp/find-func.el	4 Jul 2005 17:33:35 -0000	1.58
--- lisp/emacs-lisp/find-func.el	12 Jul 2005 06:55:32 -0000
***************
*** 62,68 ****
    ;;  (define-derived-mode foo ...), (define-minor-mode foo)
    (concat
     "^\\s-*(\\(def\\(ine-skeleton\\|ine-generic-mode\\|ine-derived-mode\\|\
! ine-minor-mode\\|un-cvs-mode\\|foo\\|[^cfgv]\\w+\\*?\\)\
  \\|easy-mmode-define-global-mode\\|menu-bar-make-toggle\\)"
     find-function-space-re
     "\\('\\|\(quote \\)?%s\\(\\s-\\|$\\|\(\\|\)\\)")
--- 62,68 ----
    ;;  (define-derived-mode foo ...), (define-minor-mode foo)
    (concat
     "^\\s-*(\\(def\\(ine-skeleton\\|ine-generic-mode\\|ine-derived-mode\\|\
! ine-minor-mode\\|ine-compilation-mode\\|un-cvs-mode\\|foo\\|[^cfgv]\\w+\\*?\\)\
  \\|easy-mmode-define-global-mode\\|menu-bar-make-toggle\\)"
     find-function-space-re
     "\\('\\|\(quote \\)?%s\\(\\s-\\|$\\|\(\\|\)\\)")

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

Re: grep.el regexp

[Richard M. Stallman]

Please install these patches.

Thanks.

Re: grep.el regexp

[Richard M. Stallman]

    > If that can happen, it is a bug in compile.el.
    > It should never find more than one match on any given line.

    Currently it puts information from different rules on the same line
    when regexps cover different parts of that line (it works this way due
    to the font-lock algorithms).

Do you mean, when different compilation-error regexps match
disjoint parts of the line?

If so, could you show me a case where this happens?
Let's try to prevent it.