* Re: grep.el regexp [not found] ` <87psuipj8b.fsf@jurta.org> @ 2005-06-20 3:50 ` Richard Stallman 2005-06-22 16:27 ` Juri Linkov 0 siblings, 1 reply; 28+ messages in thread From: Richard Stallman @ 2005-06-20 3:50 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: grep.el regexp 2005-06-20 3:50 ` grep.el regexp Richard Stallman @ 2005-06-22 16:27 ` Juri Linkov 2005-06-23 16:53 ` Richard M. Stallman 0 siblings, 1 reply; 28+ messages in thread From: Juri Linkov @ 2005-06-22 16:27 UTC (permalink / raw) Cc: emacs-devel > 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/ ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: grep.el regexp 2005-06-22 16:27 ` Juri Linkov @ 2005-06-23 16:53 ` Richard M. Stallman 2005-06-27 23:57 ` Juri Linkov 0 siblings, 1 reply; 28+ messages in thread From: Richard M. Stallman @ 2005-06-23 16:53 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: grep.el regexp 2005-06-23 16:53 ` Richard M. Stallman @ 2005-06-27 23:57 ` Juri Linkov 2005-06-28 6:19 ` Stefan Monnier 2005-06-28 18:47 ` Richard M. Stallman 0 siblings, 2 replies; 28+ messages in thread From: Juri Linkov @ 2005-06-27 23:57 UTC (permalink / raw) Cc: emacs-devel > 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/ ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: grep.el regexp 2005-06-27 23:57 ` Juri Linkov @ 2005-06-28 6:19 ` Stefan Monnier 2005-06-28 21:29 ` Richard M. Stallman 2005-06-28 18:47 ` Richard M. Stallman 1 sibling, 1 reply; 28+ messages in thread From: Stefan Monnier @ 2005-06-28 6:19 UTC (permalink / raw) Cc: rms, emacs-devel > 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: grep.el regexp 2005-06-28 6:19 ` Stefan Monnier @ 2005-06-28 21:29 ` Richard M. Stallman 2005-06-29 3:52 ` Stefan Monnier 0 siblings, 1 reply; 28+ messages in thread From: Richard M. Stallman @ 2005-06-28 21:29 UTC (permalink / raw) Cc: juri, emacs-devel > 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? ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: grep.el regexp 2005-06-28 21:29 ` Richard M. Stallman @ 2005-06-29 3:52 ` Stefan Monnier 2005-06-29 20:43 ` Richard M. Stallman 0 siblings, 1 reply; 28+ messages in thread From: Stefan Monnier @ 2005-06-29 3:52 UTC (permalink / raw) Cc: juri, emacs-devel >> 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: grep.el regexp 2005-06-29 3:52 ` Stefan Monnier @ 2005-06-29 20:43 ` Richard M. Stallman 2005-06-30 17:34 ` Stefan Monnier 0 siblings, 1 reply; 28+ messages in thread From: Richard M. Stallman @ 2005-06-29 20:43 UTC (permalink / raw) Cc: juri, emacs-devel (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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: grep.el regexp 2005-06-29 20:43 ` Richard M. Stallman @ 2005-06-30 17:34 ` Stefan Monnier 2005-07-01 4:03 ` Richard M. Stallman 2005-07-09 4:21 ` Richard M. Stallman 0 siblings, 2 replies; 28+ messages in thread From: Stefan Monnier @ 2005-06-30 17:34 UTC (permalink / raw) Cc: juri, emacs-devel > 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: grep.el regexp 2005-06-30 17:34 ` Stefan Monnier @ 2005-07-01 4:03 ` Richard M. Stallman 2005-07-09 4:21 ` Richard M. Stallman 1 sibling, 0 replies; 28+ messages in thread From: Richard M. Stallman @ 2005-07-01 4:03 UTC (permalink / raw) Cc: juri, emacs-devel > 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.) ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: grep.el regexp 2005-06-30 17:34 ` Stefan Monnier 2005-07-01 4:03 ` Richard M. Stallman @ 2005-07-09 4:21 ` Richard M. Stallman 2005-07-09 20:56 ` Juri Linkov 1 sibling, 1 reply; 28+ messages in thread From: Richard M. Stallman @ 2005-07-09 4:21 UTC (permalink / raw) Cc: juri, emacs-devel [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.) ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: grep.el regexp 2005-07-09 4:21 ` Richard M. Stallman @ 2005-07-09 20:56 ` Juri Linkov 2005-07-10 17:35 ` Richard M. Stallman 0 siblings, 1 reply; 28+ messages in thread From: Juri Linkov @ 2005-07-09 20:56 UTC (permalink / raw) Cc: monnier, emacs-devel [-- 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: grep.el regexp 2005-07-09 20:56 ` Juri Linkov @ 2005-07-10 17:35 ` Richard M. Stallman 2005-07-11 0:04 ` Juri Linkov 2005-07-12 6:55 ` Juri Linkov 0 siblings, 2 replies; 28+ messages in thread From: Richard M. Stallman @ 2005-07-10 17:35 UTC (permalink / raw) Cc: monnier, emacs-devel 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: grep.el regexp 2005-07-10 17:35 ` Richard M. Stallman @ 2005-07-11 0:04 ` Juri Linkov 2005-07-11 16:53 ` Richard M. Stallman 2005-07-12 6:55 ` Juri Linkov 1 sibling, 1 reply; 28+ messages in thread From: Juri Linkov @ 2005-07-11 0:04 UTC (permalink / raw) Cc: monnier, emacs-devel > 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/ ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: grep.el regexp 2005-07-11 0:04 ` Juri Linkov @ 2005-07-11 16:53 ` Richard M. Stallman 2005-07-19 15:55 ` Juri Linkov 2005-07-19 15:59 ` Juri Linkov 0 siblings, 2 replies; 28+ messages in thread From: Richard M. Stallman @ 2005-07-11 16:53 UTC (permalink / raw) Cc: monnier, emacs-devel 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: grep.el regexp 2005-07-11 16:53 ` Richard M. Stallman @ 2005-07-19 15:55 ` Juri Linkov 2005-07-22 4:56 ` Richard M. Stallman 2005-07-19 15:59 ` Juri Linkov 1 sibling, 1 reply; 28+ messages in thread From: Juri Linkov @ 2005-07-19 15:55 UTC (permalink / raw) Cc: monnier, emacs-devel 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/ ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: grep.el regexp 2005-07-19 15:55 ` Juri Linkov @ 2005-07-22 4:56 ` Richard M. Stallman 2005-07-22 18:09 ` Juri Linkov 0 siblings, 1 reply; 28+ messages in thread From: Richard M. Stallman @ 2005-07-22 4:56 UTC (permalink / raw) Cc: monnier, emacs-devel 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: grep.el regexp 2005-07-22 4:56 ` Richard M. Stallman @ 2005-07-22 18:09 ` Juri Linkov 2005-07-23 14:02 ` Richard M. Stallman 0 siblings, 1 reply; 28+ messages in thread From: Juri Linkov @ 2005-07-22 18:09 UTC (permalink / raw) Cc: monnier, emacs-devel > 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/ ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: grep.el regexp 2005-07-22 18:09 ` Juri Linkov @ 2005-07-23 14:02 ` Richard M. Stallman 0 siblings, 0 replies; 28+ messages in thread From: Richard M. Stallman @ 2005-07-23 14:02 UTC (permalink / raw) Cc: monnier, emacs-devel 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: grep.el regexp 2005-07-11 16:53 ` Richard M. Stallman 2005-07-19 15:55 ` Juri Linkov @ 2005-07-19 15:59 ` Juri Linkov 2005-07-24 0:01 ` Richard M. Stallman 1 sibling, 1 reply; 28+ messages in thread From: Juri Linkov @ 2005-07-19 15:59 UTC (permalink / raw) Cc: monnier, emacs-devel 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/ ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: grep.el regexp 2005-07-19 15:59 ` Juri Linkov @ 2005-07-24 0:01 ` Richard M. Stallman 2005-08-04 2:14 ` Juri Linkov 0 siblings, 1 reply; 28+ messages in thread From: Richard M. Stallman @ 2005-07-24 0:01 UTC (permalink / raw) Cc: monnier, emacs-devel 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? ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: grep.el regexp 2005-07-24 0:01 ` Richard M. Stallman @ 2005-08-04 2:14 ` Juri Linkov 2005-08-04 20:45 ` Richard M. Stallman 0 siblings, 1 reply; 28+ messages in thread From: Juri Linkov @ 2005-08-04 2:14 UTC (permalink / raw) Cc: monnier, emacs-devel > 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/ ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: grep.el regexp 2005-08-04 2:14 ` Juri Linkov @ 2005-08-04 20:45 ` Richard M. Stallman 2005-08-05 0:05 ` Juri Linkov 0 siblings, 1 reply; 28+ messages in thread From: Richard M. Stallman @ 2005-08-04 20:45 UTC (permalink / raw) Cc: monnier, emacs-devel 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: grep.el regexp 2005-08-04 20:45 ` Richard M. Stallman @ 2005-08-05 0:05 ` Juri Linkov 2005-08-05 20:37 ` Richard M. Stallman 0 siblings, 1 reply; 28+ messages in thread From: Juri Linkov @ 2005-08-05 0:05 UTC (permalink / raw) Cc: monnier, emacs-devel > 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/ ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: grep.el regexp 2005-08-05 0:05 ` Juri Linkov @ 2005-08-05 20:37 ` Richard M. Stallman 0 siblings, 0 replies; 28+ messages in thread From: Richard M. Stallman @ 2005-08-05 20:37 UTC (permalink / raw) Cc: monnier, emacs-devel 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: grep.el regexp 2005-07-10 17:35 ` Richard M. Stallman 2005-07-11 0:04 ` Juri Linkov @ 2005-07-12 6:55 ` Juri Linkov 2005-07-13 5:17 ` Richard M. Stallman 1 sibling, 1 reply; 28+ messages in thread From: Juri Linkov @ 2005-07-12 6:55 UTC (permalink / raw) Cc: monnier, emacs-devel > 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/ ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: grep.el regexp 2005-07-12 6:55 ` Juri Linkov @ 2005-07-13 5:17 ` Richard M. Stallman 0 siblings, 0 replies; 28+ messages in thread From: Richard M. Stallman @ 2005-07-13 5:17 UTC (permalink / raw) Cc: monnier, emacs-devel Please install these patches. Thanks. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: grep.el regexp 2005-06-27 23:57 ` Juri Linkov 2005-06-28 6:19 ` Stefan Monnier @ 2005-06-28 18:47 ` Richard M. Stallman 1 sibling, 0 replies; 28+ messages in thread From: Richard M. Stallman @ 2005-06-28 18:47 UTC (permalink / raw) Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2005-08-05 20:37 UTC | newest] Thread overview: 28+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <E1Djqpn-0003ih-62@fencepost.gnu.org> [not found] ` <87psuipj8b.fsf@jurta.org> 2005-06-20 3:50 ` grep.el regexp Richard Stallman 2005-06-22 16:27 ` Juri Linkov 2005-06-23 16:53 ` Richard M. Stallman 2005-06-27 23:57 ` Juri Linkov 2005-06-28 6:19 ` Stefan Monnier 2005-06-28 21:29 ` Richard M. Stallman 2005-06-29 3:52 ` Stefan Monnier 2005-06-29 20:43 ` Richard M. Stallman 2005-06-30 17:34 ` Stefan Monnier 2005-07-01 4:03 ` Richard M. Stallman 2005-07-09 4:21 ` Richard M. Stallman 2005-07-09 20:56 ` Juri Linkov 2005-07-10 17:35 ` Richard M. Stallman 2005-07-11 0:04 ` Juri Linkov 2005-07-11 16:53 ` Richard M. Stallman 2005-07-19 15:55 ` Juri Linkov 2005-07-22 4:56 ` Richard M. Stallman 2005-07-22 18:09 ` Juri Linkov 2005-07-23 14:02 ` Richard M. Stallman 2005-07-19 15:59 ` Juri Linkov 2005-07-24 0:01 ` Richard M. Stallman 2005-08-04 2:14 ` Juri Linkov 2005-08-04 20:45 ` Richard M. Stallman 2005-08-05 0:05 ` Juri Linkov 2005-08-05 20:37 ` Richard M. Stallman 2005-07-12 6:55 ` Juri Linkov 2005-07-13 5:17 ` Richard M. Stallman 2005-06-28 18:47 ` Richard M. Stallman
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.