* [Lute.Kamstra.lists@xs4all.nl: Re: junk in *grep* buffers]
@ 2005-04-26 10:06 Richard Stallman
2005-04-26 21:24 ` Fwd: Re: junk in *grep* buffers Stefan Monnier
2005-05-10 12:33 ` [Lute.Kamstra.lists@xs4all.nl: Re: junk in *grep* buffers] Kai Großjohann
0 siblings, 2 replies; 11+ messages in thread
From: Richard Stallman @ 2005-04-26 10:06 UTC (permalink / raw)
Would someone please investigate this bug?
Please respond to this message if you investigate it.
------- Start of forwarded message -------
To: Dave Love <fx@gnu.org>
In-Reply-To: <rzqd5t8g8x2.fsf@dpcsport.dl.ac.uk> (Dave Love's message of "Tue,
05 Apr 2005 23:23:21 +0100")
From: Lute Kamstra <Lute.Kamstra.lists@xs4all.nl>
Date: Wed, 06 Apr 2005 01:46:34 +0200
Cc: emacs-pretest-bug@gnu.org
Subject: Re: junk in *grep* buffers
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63
Dave Love <fx@gnu.org> writes:
> Escape sequences appear randomly in *grep* buffers, at least on
> lines with two matches. You can get different results from running
> the same grep multiple times, but not reproducibly, and you may not
> see the escapes the first time.
[...]
I've noticed a problem that's likely related.
When I do M-x grep and use
grep -nH -e "(define-minor-mode" lisp/*.el
I get a *grep* buffer with occurrences of "(define-minor-mode" in lisp
files. Every time that I tried, most lines in this buffer give the
text "(define-minor-mode" the grep-match-face, but a few lines don't
fontify "(define-minor-mode". The strange thing is that the lines
that don't fontify "(define-minor-mode" are different every time I
invoke grep.
I've got a sneaky suspicion that something goes awry with the
interaction between font-locking and the code in
grep-mode-font-lock-keywords that removes the escape sequences.
Lute.
_______________________________________________
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
------- End of forwarded message -------
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Fwd: Re: junk in *grep* buffers 2005-04-26 10:06 [Lute.Kamstra.lists@xs4all.nl: Re: junk in *grep* buffers] Richard Stallman @ 2005-04-26 21:24 ` Stefan Monnier 2005-04-27 11:29 ` Lute Kamstra ` (2 more replies) 2005-05-10 12:33 ` [Lute.Kamstra.lists@xs4all.nl: Re: junk in *grep* buffers] Kai Großjohann 1 sibling, 3 replies; 11+ messages in thread From: Stefan Monnier @ 2005-04-26 21:24 UTC (permalink / raw) Cc: emacs-devel > Would someone please investigate this bug? > Please respond to this message if you investigate it. I can't investigate it (no time, and no coloring-grep to try it on), but here is a suggestion. > When I do M-x grep and use > grep -nH -e "(define-minor-mode" lisp/*.el > I get a *grep* buffer with occurrences of "(define-minor-mode" in lisp > files. Every time that I tried, most lines in this buffer give the > text "(define-minor-mode" the grep-match-face, but a few lines don't > fontify "(define-minor-mode". The strange thing is that the lines > that don't fontify "(define-minor-mode" are different every time I > invoke grep. The problem, most likely is the following: 1 - grep sends a partial line like foo:123:toto \033[01;41mMATCH\033[00m 2 - font-lock fontifies this, which adds a face property and removes the markers, so the text is now: foo:123:toto MATCH 3 - grep sends the rest of the line bar baz\n so the complete line is now foo:123:toto MATCH bar baz\n 4 - font-lock is triggered again to fontify the added text, but it works a line-at-a-time so it re-fontifies the whole line, what begins by removing the `face' property and never re-adds it since the merkers are now lost. So the patch below should fix the problem because it uses the font-lock-face property which is not cleared by font-lock. If you find the patch works, please just install it for me, Stefan Index: grep.el =================================================================== RCS file: /cvsroot/emacs/emacs/lisp/progmodes/grep.el,v retrieving revision 1.34 diff -u -u -b -r1.34 grep.el --- grep.el 9 Feb 2005 15:50:36 -0000 1.34 +++ grep.el 26 Apr 2005 21:17:45 -0000 @@ -1,7 +1,7 @@ ;;; grep.el --- run compiler as inferior of Emacs, parse error messages ;; Copyright (C) 1985, 1986, 1987, 1993, 1994, 1995, 1996, 1997, 1998, 1999, -;; 2001, 2002, 2004 Free Software Foundation, Inc. +;; 2001, 2002, 2004, 2005 Free Software Foundation, Inc. ;; Author: Roland McGrath <roland@gnu.org> ;; Maintainer: FSF @@ -294,7 +294,7 @@ (2 compilation-line-face)) ;; Highlight grep matches and delete markers ("\\(\033\\[01;41m\\)\\(.*?\\)\\(\033\\[00m\\(\033\\[K\\)?\\)" - (2 grep-match-face) + (2 (list 'face nil 'font-lock-face grep-match-face)) ((lambda (p)) (progn ;; Delete markers with `replace-match' because it updates ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Fwd: Re: junk in *grep* buffers 2005-04-26 21:24 ` Fwd: Re: junk in *grep* buffers Stefan Monnier @ 2005-04-27 11:29 ` Lute Kamstra 2005-04-28 11:00 ` Richard Stallman 2005-05-08 13:44 ` Andreas Schwab 2 siblings, 0 replies; 11+ messages in thread From: Lute Kamstra @ 2005-04-27 11:29 UTC (permalink / raw) Cc: rms, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> When I do M-x grep and use >> >> grep -nH -e "(define-minor-mode" lisp/*.el >> >> I get a *grep* buffer with occurrences of "(define-minor-mode" in lisp >> files. Every time that I tried, most lines in this buffer give the >> text "(define-minor-mode" the grep-match-face, but a few lines don't >> fontify "(define-minor-mode". The strange thing is that the lines >> that don't fontify "(define-minor-mode" are different every time I >> invoke grep. > > The problem, most likely is the following: > > 1 - grep sends a partial line like > > foo:123:toto \033[01;41mMATCH\033[00m > > 2 - font-lock fontifies this, which adds a face property and removes > the markers, so the text is now: > > foo:123:toto MATCH > > 3 - grep sends the rest of the line > > bar baz\n > > so the complete line is now > > foo:123:toto MATCH bar baz\n > > 4 - font-lock is triggered again to fontify the added text, but it works > a line-at-a-time so it re-fontifies the whole line, what begins by > removing the `face' property and never re-adds it since the merkers are > now lost. > > So the patch below should fix the problem because it uses the font-lock-face > property which is not cleared by font-lock. > > If you find the patch works, please just install it for me, Your patch fixes the problem I described. I'll add a comment explaining the need to use font-lock-face and commit it. Lute. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Fwd: Re: junk in *grep* buffers 2005-04-26 21:24 ` Fwd: Re: junk in *grep* buffers Stefan Monnier 2005-04-27 11:29 ` Lute Kamstra @ 2005-04-28 11:00 ` Richard Stallman 2005-05-08 13:44 ` Andreas Schwab 2 siblings, 0 replies; 11+ messages in thread From: Richard Stallman @ 2005-04-28 11:00 UTC (permalink / raw) Cc: Lute.Kamstra.lists, emacs-devel Thanks for fixing this. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Fwd: Re: junk in *grep* buffers 2005-04-26 21:24 ` Fwd: Re: junk in *grep* buffers Stefan Monnier 2005-04-27 11:29 ` Lute Kamstra 2005-04-28 11:00 ` Richard Stallman @ 2005-05-08 13:44 ` Andreas Schwab 2005-05-09 21:03 ` Richard Stallman 2 siblings, 1 reply; 11+ messages in thread From: Andreas Schwab @ 2005-05-08 13:44 UTC (permalink / raw) Cc: rms, Lute Kamstra, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: > So the patch below should fix the problem because it uses the font-lock-face > property which is not cleared by font-lock. This is still not enough when there are multiple matches on the same line close to each other. Since we delete some text during fontification font-lock-fontify-keywords-region will skip over some of the following text when it readjusts point. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Fwd: Re: junk in *grep* buffers 2005-05-08 13:44 ` Andreas Schwab @ 2005-05-09 21:03 ` Richard Stallman 2005-05-09 21:16 ` Juri Linkov 0 siblings, 1 reply; 11+ messages in thread From: Richard Stallman @ 2005-05-09 21:03 UTC (permalink / raw) Cc: monnier, Lute.Kamstra.lists, emacs-devel This is still not enough when there are multiple matches on the same line close to each other. Since we delete some text during fontification font-lock-fontify-keywords-region will skip over some of the following text when it readjusts point. Is it possible to adjust the position at which font-lock-fontify-keywords-region will set point, to compensate for the deletion? Could the code use a marker to maintain that position? Then it would be relocated automatically. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Fwd: Re: junk in *grep* buffers 2005-05-09 21:03 ` Richard Stallman @ 2005-05-09 21:16 ` Juri Linkov 2005-05-10 16:26 ` Richard Stallman 0 siblings, 1 reply; 11+ messages in thread From: Juri Linkov @ 2005-05-09 21:16 UTC (permalink / raw) Cc: emacs-devel > This is still not enough when there are multiple matches on the same line > close to each other. Since we delete some text during fontification > font-lock-fontify-keywords-region will skip over some of the following > text when it readjusts point. > > Is it possible to adjust the position at which > font-lock-fontify-keywords-region will set point, to compensate for > the deletion? Could the code use a marker to maintain that position? > Then it would be relocated automatically. The following hack fixes the problem, but this is an imperfect solution. It sets the local variable `pos' from `font-lock-fontify-keywords-region' to avoid changing the current position on the line: ;; Ensure forward progress. (if (< (point) pos) (goto-char pos)) Index: lisp/progmodes/grep.el =================================================================== RCS file: /cvsroot/emacs/emacs/lisp/progmodes/grep.el,v retrieving revision 1.36 diff -u -r1.36 grep.el --- lisp/progmodes/grep.el 7 May 2005 16:21:12 -0000 1.36 +++ lisp/progmodes/grep.el 9 May 2005 22:16:22 -0000 @@ -303,7 +303,8 @@ ;; Delete markers with `replace-match' because it updates ;; the match-data, whereas `delete-region' would render it obsolete. (replace-match "" t t nil 3) - (replace-match "" t t nil 1))))) + (replace-match "" t t nil 1) + (setq pos (point)))))) "Additional things to highlight in grep output. This gets tacked on the end of the generated expressions.") -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Fwd: Re: junk in *grep* buffers 2005-05-09 21:16 ` Juri Linkov @ 2005-05-10 16:26 ` Richard Stallman 2005-05-10 17:36 ` Stefan Monnier 0 siblings, 1 reply; 11+ messages in thread From: Richard Stallman @ 2005-05-10 16:26 UTC (permalink / raw) Cc: emacs-devel The following hack fixes the problem, but this is an imperfect solution. It sets the local variable `pos' from `font-lock-fontify-keywords-region' to avoid changing the current position on the line: Could the code in font-lock-fontify-keywords-region use a marker to maintain that position? Then it would be relocated automatically. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Fwd: Re: junk in *grep* buffers 2005-05-10 16:26 ` Richard Stallman @ 2005-05-10 17:36 ` Stefan Monnier 2005-05-11 8:23 ` Juri Linkov 0 siblings, 1 reply; 11+ messages in thread From: Stefan Monnier @ 2005-05-10 17:36 UTC (permalink / raw) Cc: Juri Linkov, emacs-devel > The following hack fixes the problem, but this is an imperfect solution. > It sets the local variable `pos' from `font-lock-fontify-keywords-region' > to avoid changing the current position on the line: > Could the code in font-lock-fontify-keywords-region use a marker to > maintain that position? Then it would be relocated automatically. Would the patch below do the trick? Stefan --- font-lock.el 05 mai 2005 16:09:23 -0400 1.245 +++ font-lock.el 10 mai 2005 13:35:07 -0400 @@ -1405,6 +1405,7 @@ (let ((case-fold-search font-lock-keywords-case-fold-search) (keywords (cddr font-lock-keywords)) (bufname (buffer-name)) (count 0) + (pos (make-marker)) keyword matcher highlights) ;; ;; Fontify each item in `font-lock-keywords' from `start' to `end'. @@ -1439,12 +1440,13 @@ (while highlights (if (numberp (car (car highlights))) (font-lock-apply-highlight (car highlights)) - (let ((pos (point))) + (set-marker pos (point)) (font-lock-fontify-anchored-keywords (car highlights) end) ;; Ensure forward progress. - (if (< (point) pos) (goto-char pos)))) + (if (< (point) pos) (goto-char pos))) (setq highlights (cdr highlights)))) - (setq keywords (cdr keywords))))) + (setq keywords (cdr keywords))) + (set-marker pos nil))) ;;; End of Keyword regexp fontification functions. \f ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Fwd: Re: junk in *grep* buffers 2005-05-10 17:36 ` Stefan Monnier @ 2005-05-11 8:23 ` Juri Linkov 0 siblings, 0 replies; 11+ messages in thread From: Juri Linkov @ 2005-05-11 8:23 UTC (permalink / raw) Cc: rms, emacs-devel >> Could the code in font-lock-fontify-keywords-region use a marker to >> maintain that position? Then it would be relocated automatically. > > Would the patch below do the trick? Yes, it fixes the problem of too close multiple matches. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Lute.Kamstra.lists@xs4all.nl: Re: junk in *grep* buffers] 2005-04-26 10:06 [Lute.Kamstra.lists@xs4all.nl: Re: junk in *grep* buffers] Richard Stallman 2005-04-26 21:24 ` Fwd: Re: junk in *grep* buffers Stefan Monnier @ 2005-05-10 12:33 ` Kai Großjohann 1 sibling, 0 replies; 11+ messages in thread From: Kai Großjohann @ 2005-05-10 12:33 UTC (permalink / raw) Richard Stallman <rms@gnu.org> writes: > Would someone please investigate this bug? > Please respond to this message if you investigate it. Lute Kamstra writes: > I get a *grep* buffer with occurrences of "(define-minor-mode" in lisp > files. Every time that I tried, most lines in this buffer give the > text "(define-minor-mode" the grep-match-face, but a few lines don't > fontify "(define-minor-mode". The strange thing is that the lines > that don't fontify "(define-minor-mode" are different every time I > invoke grep. Very wild guess. Please do C-h v tramp-chunksize RET and run the Lisp code shown in the documentation for tramp-chunksize and report your findings. The Lisp snippet contains a number, 1000. If you do not observe a problem (i.e., you that bytes sent always equals bytes received), then please also try larger values, 10000 or 100000 or 1000000. Kai ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2005-05-11 8:23 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-04-26 10:06 [Lute.Kamstra.lists@xs4all.nl: Re: junk in *grep* buffers] Richard Stallman 2005-04-26 21:24 ` Fwd: Re: junk in *grep* buffers Stefan Monnier 2005-04-27 11:29 ` Lute Kamstra 2005-04-28 11:00 ` Richard Stallman 2005-05-08 13:44 ` Andreas Schwab 2005-05-09 21:03 ` Richard Stallman 2005-05-09 21:16 ` Juri Linkov 2005-05-10 16:26 ` Richard Stallman 2005-05-10 17:36 ` Stefan Monnier 2005-05-11 8:23 ` Juri Linkov 2005-05-10 12:33 ` [Lute.Kamstra.lists@xs4all.nl: Re: junk in *grep* buffers] Kai Großjohann
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).