[Top][All Lists]
[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/