Re: GREP_OPTIONS again

[Juri Linkov]

Stefan <address@hidden> writes:
> I just bumped into a bad side-effect of the GREP_OPTIONS thingy:
> I grepped for MM and then isearched for `MM (', knowing full well there had
> to be a match but it didn't find anything.
>
> The problem was the invisible annotations added by grep because of
> the --color.  I guess we should just remove them rather than make
> them invisible.
>
> The patch below is actually untested (for some reason my grep doesn't want
> to add those annotations any more right now),

This patch doesn't work correctly: it fontified the text 8 positions
to the right (the length of deleted annotations) from the actual match.

Either font-lock should be improved to cope with deleted matches
or maybe its existing capabilities already allow to do that.

I tried to use the PRE-MATCH-FORM parameter.  Basically it works for
the first match on a line, but I don't see how to use it for other
matches on the same line - the current implementation doesn't allow that:

    
("^\\(.+?\\)[:(]+\\([0-9]+\\)\\([:)]\\).*?\\(\033\\[01;41m\\)\\(.*?\\)\\(\033\\[00m\\)"
     1 2
     ((lambda ()
        (setq compilation-error-screen-columns nil)
        (- (match-beginning 5) (match-end 3)))
      .
      (lambda () (- (match-end 5) (match-end 3))))
     nil nil
     ;; Delete annotations with `replace-match' because it updates
     ;; the match-data, whereas `delete-region' would render it obsolete.
     (5 (list 'face compilation-column-face))
     ((lambda (p))  ; faked `MATCHER'
      (progn
        (replace-match "" t t nil 6)
        (replace-match "" t t nil 4)))
     ;; highlight other matches on the same line
     ("\\(\033\\[01;41m\\)\\(.*?\\)\\(\033\\[00m\\)"
      nil nil
      (2 (list 'face compilation-column-face))
;; ???
;;       ((lambda (p))  ; facked `MATCHER'
;;        (progn
;;          (replace-match "" t t nil 3)
;;          (replace-match "" t t nil 1)))
      ))

BTW, the documentation for font-lock is more complete in the docstring
of `font-lock-keywords' than in the Emacs Lisp Reference Manual.
Perhaps, it should be updated.

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