GNU bug report logs - #14427
24.3.50; Highlight symbol at point

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Juri Linkov <juri <at> jurta.org>
Subject: bug#14427: closed (Re: bug#14427: 24.3.50; Highlight symbol at point)
Date: Mon, 03 Jun 2013 08:58:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#14427: 24.3.50; Highlight symbol at point

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 14427 <at> debbugs.gnu.org.

-- 
14427: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14427
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Juri Linkov <juri <at> jurta.org>
To: Jambunathan K <kjambunathan <at> gmail.com>
Cc: 14427-done <at> debbugs.gnu.org
Subject: Re: bug#14427: 24.3.50; Highlight symbol at point
Date: Mon, 03 Jun 2013 11:54:05 +0300

>> If you could commit this change, I can start using it right away.

Thanks for the reminder, this is installed now.

> Small note.  I haven't tested the isearch portions of the patch.

Isearch integration with hi-lock is far from ideal yet.
The limiting factor is that hi-lock is based on font-lock
when font-lock is enabled.  Otherwise, it is plain search-based.

Perhaps we should check in `isearch-highlight-regexp'
whether font-lock is active in the current buffer,
and when font-lock is disabled then let-bind all relevant
search variables like `lax-whitespace', `search-invisible',
filters, etc.  So search-based hi-lock will be able to highlight
correctly the same matches as isearch.

This will provide the correct conversion of the search parameters
to hi-lock (at least partly for the case when font-lock is disabled
and hi-lock is search-based).

[Message part 3 (message/rfc822, inline)]

From: Juri Linkov <juri <at> jurta.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; Highlight symbol at point
Date: Tue, 21 May 2013 01:54:34 +0300

This feature request mostly doesn't depend on the outcome of bug#14405.
I don't know why Jambunathan didn't propose this feature earlier, but it
logically follows from his other improvements in hi-lock.el, i.e. the
feature that doesn't ask for a face and automatically uses the next face
from the list of available faces suggests also a command that doesn't ask
for a symbol and automatically uses the symbol at point:

=== modified file 'lisp/hi-lock.el'
--- lisp/hi-lock.el	2013-03-31 13:34:35 +0000
+++ lisp/hi-lock.el	2013-05-20 22:52:54 +0000
@@ -483,6 +461,27 @@ (defun hi-lock-face-phrase-buffer (regex
   (unless hi-lock-mode (hi-lock-mode 1))
   (hi-lock-set-pattern regexp face))
 
+;;;###autoload
+(defalias 'highlight-symbol-at-point 'hi-lock-face-symbol-at-point)
+;;;###autoload
+(defun hi-lock-face-symbol-at-point ()
+  "Set face of each match of the symbol at point.
+Use `find-tag-default-as-symbol-regexp' to retrieve the symbol at point.
+Use non-nil `hi-lock-auto-select-face' to retrieve the next face
+from `hi-lock-face-defaults' automatically.
+
+Use Font lock mode, if enabled, to highlight symbol at point.
+Otherwise, use overlays for highlighting.  If overlays are used,
+the highlighting will not update as you type."
+  (interactive)
+  (let* ((regexp (hi-lock-regexp-okay
+		  (find-tag-default-as-symbol-regexp)))
+	 (hi-lock-auto-select-face t)
+	 (face (hi-lock-read-face-name)))
+    (or (facep face) (setq face 'hi-yellow))
+    (unless hi-lock-mode (hi-lock-mode 1))
+    (hi-lock-set-pattern regexp face)))
+
 (defun hi-lock-keyword->face (keyword)
   (cadr (cadr (cadr keyword))))    ; Keyword looks like (REGEXP (0 'FACE) ...).
 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.