emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: why does occur depropertize matching lines?


From: Juri Linkov
Subject: Re: why does occur depropertize matching lines?
Date: Thu, 25 Nov 2004 09:27:11 +0200
User-agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux)

Richard Stallman <address@hidden> writes:
> I discovered that changing occur-1 to pass t for the keep-props
> argument to occur-engine inverts this: it preserves the highlighting
> for the actual target line, and discards it for the context lines.

Inverting the meaning of the `keep-props' argument for context lines is
too unnatural thing to do.  It's more natural to expect that users
might want to highlight either everything (matching and context lines)
or nothing.  So I think the argument of `occur-accumulate-lines'
should be reversed.

> That seems like a good idea to me; what do you think?

I suppose someone might not like to keep highlighting at all.
How about a user option for it?

Index: lisp/replace.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/replace.el,v
retrieving revision 1.190
diff -u -r1.190 replace.el
--- lisp/replace.el     20 Nov 2004 22:09:50 -0000      1.190
+++ lisp/replace.el     25 Nov 2004 07:48:48 -0000
@@ -636,6 +636,11 @@
   :type 'hook
   :group 'matching)
 
+(defcustom occur-keep-props nil
+  "Non-nil keeps text properties in *Occur* buffer."
+  :type 'boolean
+  :group 'matching)
+
 (put 'occur-mode 'mode-class 'special)
 (defun occur-mode ()
   "Major mode for output from \\[occur].
@@ -768,7 +774,7 @@
   :type 'face
   :group 'matching)
 
-(defun occur-accumulate-lines (count &optional no-props)
+(defun occur-accumulate-lines (count &optional keep-props)
   (save-excursion
     (let ((forwardp (> count 0))
          (result nil))
@@ -778,9 +784,9 @@
                        (bobp))))
        (setq count (+ count (if forwardp -1 1)))
        (push
-        (funcall (if no-props
-                     #'buffer-substring-no-properties
-                   #'buffer-substring)
+        (funcall (if keep-props
+                     #'buffer-substring
+                   #'buffer-substring-no-properties)
          (line-beginning-position)
          (line-end-position))
         result)
@@ -915,7 +921,7 @@
                    (and case-fold-search
                         (isearch-no-upper-case-p regexp t))
                    list-matching-lines-buffer-name-face
-                   nil list-matching-lines-face nil)))
+                   nil list-matching-lines-face occur-keep-props)))
        (let* ((bufcount (length active-bufs))
               (diff (- (length bufs) bufcount)))
          (message "Searched %d buffer%s%s; %s match%s for `%s'"



> I wonder why occur-engine uses font-lock-face.  It is not font lock
> mode, after all.  Changing it to use `face' instead makes it seem
> to do the right thing.  Does it cause any problem?

Perhaps, yes.

The default value of `occur-mode-hook' is '(turn-on-font-lock),
and `occur-mode' also adds `font-lock-defontify' hook to
`change-major-mode-hook'.

I don't know for what purpose these font-lock related settings were
added, so I can't tell what kinds of problems removing `font-lock-face'
property might cause.

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]