[Top][All Lists]

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

[debbugs-tracker] bug#11095: closed (24.0.94; hi-lock-face-buffer/unhigh

From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#11095: closed (24.0.94; hi-lock-face-buffer/unhighlight-regexp': Augment?)
Date: Mon, 10 Dec 2012 18:36:01 +0000

Your message dated Mon, 10 Dec 2012 13:34:25 -0500
with message-id <address@hidden>
and subject line Re: bug#11095: [PATCH] Re: bug#11095: 24.0.94; 
hi-lock-face-buffer/unhighlight-regexp': Augment?
has caused the debbugs.gnu.org bug report #11095,
regarding 24.0.94; hi-lock-face-buffer/unhighlight-regexp': Augment?
to be marked as done.

(If you believe you have received this mail in error, please contact

11095: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11095
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 24.0.94; hi-lock-face-buffer/unhighlight-regexp': Augment? Date: Mon, 26 Mar 2012 12:16:55 +0530
Proposal is in two parts.  Part-I deals with `hi-lock-face-buffer'.
Part-II deals with `unhighlight-regexp'.  Part-III has a dump of the
current customization I have in my .emacs.

I believe that my proposal is useful in general.  So I request that it
be folded in to Emacs-24.1.

Part-I: `hi-lock-face-buffer' & Co.

1) Review the face names used in `hi-lock-face-defaults' and make the
   faces customizable.  The defaults may not look good on a user's his
   own font-lock configuration.

2) Make `hi-lock-face-buffer' use a different face on each invocation.  

   Here is a real-world usecase for the above request.

   As a programmer, I use highlighting to trace variable dependencies
   within a function.  For example, in the example below, after
   highlighting the variables in __different__ faces, I will come to the
   conclusion that "a" depends on "d" and "tmp".

     c = d;
     b = c + tmp;
     a = b;

   And I use this very often to track variables and how they get their
   values from.

   If I were to use the default Emacs provided behaviour then I would
   have to press M-n multiple times as I highlight more and more
   symbols. (Typically I have 3-5 symbols highlighted before I turn off

See elisp snippet at the end of the mail.

Part-II: `unhighlight-regexp'

See usecase in Part-I/Item-2 

1) I want to selectively turn-off highlighting for certain regexps
   (arguably) that _specific_ highlighted regexp cursor is stationed on.
   This would happen when I decide that I don't want to factor a
   particular variable for my current refactoring exercise.

   I find the current behaviour of `unhighlight-regexp' slightly

   1. There is no completion for which regexp I want to unhighlight and
      I have to circle through `hi-lock-interactive-patterns'.

   2. Browsing the `hi-lock-interactive-patterns' is tedious for the
      following reasons:

      - The order in which unhighlighting happens could totally be
        unrelated to the order in which highlighting happens.  When I am
        analyzing the variable flow, I don't want to do a "context
        switch" trying to find out what item to choose from the
        `unhighlight-regexp' menu.

2) I want to unhighlight all regexps.  This happens when I am done with
   variable analysis.

ps: I am not questioning the current defaults.  I am only saying that it
the current behaviour is too generic to be immediately useful (atleast
for my usecase) and so needs some sort of extra augmentation.

Part-III: Elisp snippet

;; Why should the color of the faces be encoded in the variable name?
;; Seems counter-intutitive to me.  I cannot relate to a hi-yellow
;; face customized to render in red.

;; (defvar hi-lock-face-defaults
;;   '("hi-yellow" "hi-pink" "hi-green" "hi-blue" "hi-black-b"
;;     "hi-blue-b" "hi-red-b" "hi-green-b" "hi-black-hb")
;;   "Default faces for hi-lock interactive functions.")

;; So roll out my own face for highlighting.  Make them
;; __customizable__.  Note that the name of the face doesn't say what
;; the color of the highlight will be.  Works for the color theme that
;; I have.
 '(highlight1 ((t (:background "yellow" :foreground "black"))))
 '(highlight2 ((t (:background "OrangeRed" :foreground "black"))))
 '(highlight3 ((((class color) (background dark)) (:background "AntiqueWhite" 
:foreground "black"))))
 '(highlight4 ((t (:background "SystemHotTrackingColor"))))
 '(highlight5 ((t (:background "VioletRed" :foreground "black")))))

;; override the Emacs default
(setq hi-lock-face-defaults
      '("highlight1" "highlight2" "highlight3" "highlight4" "highlight5"))

(defvar hi-lock-faces
  (let ((l (copy-list hi-lock-face-defaults)))
    (setcdr (last l) l))
  "Circular list of faces in `hi-lock-face-defaults'.")

;; make `hi-lock-faces' buffer local
(make-variable-buffer-local 'hi-lock-faces)

(defun highlight-symbol ()
  "Highlight symbol at point.  
For illustartion only.  Note the use of `hi-lock-face-buffer'.
Choose a new face from `hi-lock-faces' on each invocation.
Overrides the default behaviour in vanilla Emacs which is to use
the face at the head of the list."
   (concat "\\_<" (regexp-quote (thing-at-point 'symbol)) "\\_>")
   ;; rotate the face list
   (prog1 (car hi-lock-faces)
     (setq hi-lock-faces (cdr hi-lock-faces)))))

(defun my-unhighlight-regexp (arg)
  "Wrapper around `unhighlight-regexp'.
With a prefix argument, turn off all highlighting.

TODO: Check if the symbol is right now on a highlighted regexp.
If yes, unhighlight only that regexp."
  (interactive "P")
  (if arg
      (mapc (lambda (p)
              (unhighlight-regexp (car p)))
    (call-interactively 'unhighlight-regexp)))

--- End Message ---
--- Begin Message --- Subject: Re: bug#11095: [PATCH] Re: bug#11095: 24.0.94; hi-lock-face-buffer/unhighlight-regexp': Augment? Date: Mon, 10 Dec 2012 13:34:25 -0500 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)
> This patch makes sure that faces used for highlighting are always
> distinct and recycles them only when it is inevitable.

Installed with 2 changes:
- replace "delete" with "remove" because it was applied to a list which
  is reachable from other places (basically, from other buffer's
- introduced a helper hi-lock-keyword->face to get rid of those cadadadr
  (some of which needed `cl' even it was not `require'd).


--- End Message ---

reply via email to

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