> 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.
> 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
> highlighting.)
> 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
> tedious.
> 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.
> ;; 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.
> ;; 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.
> (custom-set-faces
> '(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")))))
> (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."
> (interactive)
> (hi-lock-face-buffer
> (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)))
> hi-lock-interactive-patterns)
> (call-interactively 'unhighlight-regexp)))
> 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.
> 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
> highlighting.)
> 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
> tedious.
> 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.
> ;; 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.
> ;; 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.
> (custom-set-faces
> '(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")))))
> (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."
> (interactive)
> (hi-lock-face-buffer
> (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)))
> hi-lock-interactive-patterns)
> (call-interactively 'unhighlight-regexp)))
The patch allows highlighting of tag at point. (Note that for all
practical purposes, tag at point is the symbol at point.) See
Part_I/Item-2 below for a usecase.
> 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.
> 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
> highlighting.)
> 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
> tedious.
> 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.
> ;; 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.
> ;; 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.
> (custom-set-faces
> '(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")))))
> (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."
> (interactive)
> (hi-lock-face-buffer
> (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)))
> hi-lock-interactive-patterns)
> (call-interactively 'unhighlight-regexp)))
> The patch allows highlighting of tag at point. (Note that for all
> practical purposes, tag at point is the symbol at point.) See
> Part_I/Item-2 below for a usecase.
> [2. bug11095-part3.patch --- text/x-diff; bug11095-part3.patch]...
Here is the Changelog entry for bug11095-part3.patch. (Sorry for the
confusion, if any)
> The patch allows highlighting of tag at point. (Note that for all
> practical purposes, tag at point is the symbol at point.) See
> Part_I/Item-2 below for a usecase.
> [...]
> + (cond ((not tag) "")
> + ((eq tagf 'find-tag-default)
> + (format "\\_<%s\\_>" (regexp-quote tag)))
> [...]
>> 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
>> highlighting.)
Would you agree that a better way to implement your proposal is to add a new
command to hi-lock.el with a name like `highlight-symbol'? I mean there are
already such hi-lock commands as:
1. highlight-lines-matching-regexp (that corresponds to occur)
2. highlight-regexp (that corresponds to isearch-forward-regexp)
3. highlight-phrase (that corresponds to isearch-forward-word)
what is currently missing is this command:
4. highlight-symbol (that corresponds to isearch-forward-symbol)
Then both highlight-phrase and highlight-symbol could use internally
isearch functions that turn words and symbols into regexps
and that will do the right thing using search-upper-case and
search-whitespace-regexp.
Juri Linkov <j...@jurta.org> writes:
>> The patch allows highlighting of tag at point. (Note that for all
>> practical purposes, tag at point is the symbol at point.) See
>> Part_I/Item-2 below for a usecase.
>> [...]
>> + (cond ((not tag) "")
>> + ((eq tagf 'find-tag-default)
>> + (format "\\_<%s\\_>" (regexp-quote tag)))
>> [...]
>>> 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
>>> highlighting.)
> Would you agree that a better way to implement your proposal is to add a new
> command to hi-lock.el with a name like `highlight-symbol'? I mean there are
> already such hi-lock commands as:
> 1. highlight-lines-matching-regexp (that corresponds to occur)
> 2. highlight-regexp (that corresponds to isearch-forward-regexp)
> 3. highlight-phrase (that corresponds to isearch-forward-word)
> what is currently missing is this command:
> 4. highlight-symbol (that corresponds to isearch-forward-symbol)
> Then both highlight-phrase and highlight-symbol could use internally
> isearch functions that turn words and symbols into regexps
> and that will do the right thing using search-upper-case and
> search-whitespace-regexp.
Have you tried the patches?
With my current patches, M-s h r will highlight symbol at point (more
precisely tag at point). It may not be the best thing, but achieves the
task at hand.
Let me emphasize that the patches are mostly concerned with easy and
hands-off highlighting and un-highlighting (i.e., the highlighting
process itself - the "how" - rather than "what (regexp)" is highlighted
and how those regexes are composed.) So the patches are valid
candidates for consideration, irrespective of your observations above.
As for handling of regexes themselves, I will rather leave it to more
experienced hands.
ps: I have one more patch to circulate - wrt unhighlighting - before I
leave the table open for further discussion. Once I get some initial
comments, I can rework the changes and provide a (revised) consolidated
patch.
> 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.
> 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
> highlighting.)
> 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
> tedious.
> 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.
> ;; 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.
> ;; 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.
> (custom-set-faces
> '(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")))))
> (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."
> (interactive)
> (hi-lock-face-buffer
> (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)))
> hi-lock-interactive-patterns)
> (call-interactively 'unhighlight-regexp)))
> 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.
> 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
> highlighting.)
> 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
> tedious.
> 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.
> ;; 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.
> ;; 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.
> (custom-set-faces
> '(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")))))
> (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."
> (interactive)
> (hi-lock-face-buffer
> (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)))
> hi-lock-interactive-patterns)
> (call-interactively 'unhighlight-regexp)))
Here goes the final set for this bug. The revnos. reflect the (local)
bzr revision.
0. bug11095-final-r110525.diff :: Consolidated final patch.
1. bug11095-r110501.diff :: Introduce hi-lock-* faces.
2. bug11095-r110502.diff :: Let each highlight command choose a new face
3. bug11095-r110503.diff :: By default, highlight symbol at point
4. bug11095-r110504.diff :: Un-highlight text at point
5. bug11095-r110505.diff :: Un-highlight all highlighted text
> 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.
> 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
> highlighting.)
> 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
> tedious.
> 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.
I'm trying your patches now, thanks. My initial reaction was to using
a symbol regexp "\\_<%s\\_>" in `read-regexp' to match a symbol at point.
I think such symbol specific defaults could be specified by callers of
`read-regexp' in its argument `DEFAULTS'.
Juri Linkov <j...@jurta.org> writes:
>> Have you tried the patches?
> I'm trying your patches now, thanks. My initial reaction was to using
> a symbol regexp "\\_<%s\\_>" in `read-regexp' to match a symbol at point.
> I think such symbol specific defaults could be specified by callers of
> `read-regexp' in its argument `DEFAULTS'.
(This is not a response to your post, but only to record my observations
for further consideration by the reviewer)
1. Highlighting (M-shr) can happen via isearch or through hi-lock mode
(C-xwh).
I don't use isearch much. So the patch merely formalizes what I had
in my .emacs and it is done with my hi-lock mode glasses.
2. In `read-regexp' there is a `find-tag-default-function' but no
`find-tag-regexp-function'. i.e., `find-tag-default' returns a
symbol at point. But using `regexp-quote' on the result is a poor
choice when in should actually be returning a symbol regexp. (When I
am renaming symbols, I highlight them and then re-name. In that
case, the looser regexp is unreliable and annoying. As you may very
well agree, it is not uncommon to have variables share a common
prefix.)
3. `read-regexp' will use tag at point as the default regexp. If a
caller - say a `highlight-symbol' function or a symbol yank from
isearch context - then it is the responsibility of the caller to
provide the right regexp.
I'm not sure it's an improvement. When choosing a face in
hi-lock-face-buffer, "hi-lock-1" doesn't speak much to me contrary to
"hi-yellow".
So, could you expand on your motivations for this change, so we can find
another solution that satisfies your use case and mine?
I've installed your second patch (the hi-lock-auto-select-face, tho
using `pop' to simplify the code), but when hi-lock-auto-select-face is
t the user can't specify a face any more, which I think is too drastic,
which should provide a C-u override or something.
I also installed the 4th patch (the defaults for unhighlight), tho
I removed the docstring change (we usually don't document which default
is used in minibuffer arguments). Also I moved your code to a separate
function, to clarify the code. Furthermore I did not install your
change to the completion table so only the regexps that match at point
get completed. Instead the list of regexps is passed as a list
of defaults.
BTW the hi-lock-auto-select-face should be fixed to just hash-cons (aka
uniquify) regexps, so you don't need your maphash loop to recover the
regexp from the unique "serialized" number.
I also installed the 5th patch (the "unhighlight all") tho I'm not
yet sure this is the right interface. OT1H I think it would be nicer to
provide this "all" as one of the choices in the minibuffer, but OTOH
I can't think of any way to do that which is not hideously hackish.
As for the 3rd patch, I haven't installed it yet because I'm worried
that (format "\\_<%s\\_>" (regexp-quote tag)) may sometimes fail to
match `tag', so I think it needs some additional sanity check.
> I'm not sure it's an improvement. When choosing a face in
> hi-lock-face-buffer, "hi-lock-1" doesn't speak much to me contrary to
> "hi-yellow".
Not specifically related to this face, but it is a bad idea, in general (no
doubt there are exceptions), for a face name to advertize particular face
attributes, such as the color.
The color is presumably something that the user can customize, and is typically
not something that speaks to the use or meaning of the face.
>> > -(defface hi-yellow
>> > +(defface hi-lock-1
>> I'm not sure it's an improvement. When choosing a face in
>> hi-lock-face-buffer, "hi-lock-1" doesn't speak much to me contrary to
>> "hi-yellow".
> Not specifically related to this face, but it is a bad idea, in general (no
> doubt there are exceptions), for a face name to advertize particular face
> attributes, such as the color.
Depends. In the present case, the face has no particular purpose, so
saying that "its purpose to highlight in yellow" doesn't sound like such
a bad idea. Not really worse than "its purpose is to be number 2".
> The color is presumably something that the user can customize, and is
> typically not something that speaks to the use or meaning of the face.
"2" doesn't "speak to the use or meaning of the face" very much either.
I think the real issue here is that hi-lock should have a customizable
set of faces rather than a set of customizable faces.
So if the user doesn't like hi-yellow (which should be called
hi-lock-yellow, BTW) because she never highlights in yellow, she can
replace it with her own face with the name she likes.
> >> > -(defface hi-yellow
> >> > +(defface hi-lock-1
> >> I'm not sure it's an improvement. When choosing a face in
> >> hi-lock-face-buffer, "hi-lock-1" doesn't speak much to me > >> contrary to "hi-yellow".
> > Not specifically related to this face, but it is a bad > > idea, in general (no doubt there are exceptions), for a
> > face name to advertize particular face attributes, such
> > as the color.
> Depends.
I too suggested that it depends. But it depends on what "depends" means ;-).
I.e., depends on what? The dependence I see is that there could be exceptions
where the purpose/use/meaning of the face is in fact related to a particular
color.
> In the present case, the face has no particular purpose,
So in particular, it is NOT related to any particular color, including yellow.
> so saying that "its purpose to highlight in yellow" doesn't > sound like such a bad idea.
That makes as much sense (to me) as to say that its name should be
`hi-lock-rumpelstiltskin". Unless it is true that it really always should
"highlight in yellow", regardless of the face's current color.
If all we can say is that this face is about highlighting, then the only
operative word is "highlight". If we can be more specific - e.g., highlighting
like a marker pen, then that's what is called for.
In `highlight.el', for instance, I have a command for highlighting text by
dragging the mouse over it, like using a marker pen, aka a highlighter.
That command is called `hlt-highlighter' (it can use any face, like all `hlt-*'
commands). If `hl-lock-yellow' were intended for this kind of highlighting then
you might call it `hl-lock-highlighter' or some such.
I have no idea what `hl-lock-yellow' is really for. You yourself have just said
that its use has nothing to do with "yellow", however.
> Not really worse than "its purpose is to be number 2".
Is its purpose really "to highlight in yellow"? You seem to say no, above. But
if so then you probably don't need to define a customizable face for that. Just
highlight in yellow.
Or if the color must always be (or is always intended to be) yellow, but users
can customize other face attributes, then using "yellow" in the name would make
sense. In that case, the doc string should say something about this
restriction/intention wrt the color being constant.
> > The color is presumably something that the user can > > customize, and is typically not something that speaks
> > to the use or meaning of the face.
> "2" doesn't "speak to the use or meaning of the face" very > much either.
You didn't hear me argue in favor of using `2' here. Those are presumably not
the only two choices: 2 vs yellow.
On the other hand, if absolutely nothing can be said about this face other than
it is one of N hi-lock faces (none of which we can say anything else about),
then `2' is better than nothing.
It is certainly better than being overly specific and misleading, and doubly
certainly better than suggesting a specific face attribute such as a particular
color.
`hi-lock-2' does not suggest that any particular face attribute has the value
`2', unless it is something like a box line width of 2 pixels. `hi-lock-yellow'
misleads immediately, suggesting that the face always has the color yellow.
> I think the real issue here is that hi-lock should have a customizable
> set of faces rather than a set of customizable faces.
> So if the user doesn't like hi-yellow (which should be called
> hi-lock-yellow, BTW) because she never highlights in yellow, she can
> replace it with her own face with the name she likes.
Ah, in that case you are really talking, I think, about having one or more user
options, which each has a face (or a set of faces) as value.
I don't see how that is related to the above, however. If you call such an
option `*-yellow' then its name would still be misleading, no? And if on the
other hand you feel that `hi-lock-2' is OK as an option name here, but not as a
face name, then I don't follow the logic.
Just why would you prefer a "customizable set of faces" over a "set of
customizable faces"? And how does that relate to the names?
>> I think the real issue here is that hi-lock should have a customizable
>> set of faces rather than a set of customizable faces.
>> So if the user doesn't like hi-yellow (which should be called
>> hi-lock-yellow, BTW) because she never highlights in yellow, she can
>> replace it with her own face with the name she likes.
> Ah, in that case you are really talking, I think, about having one or
> more user options, which each has a face (or a set of faces) as value.
Just one option `hi-lock-faces'.
> Just why would you prefer a "customizable set of faces" over a "set of
> customizable faces"? And how does that relate to the names?
Because the user can then choose the names that make sense to her.
Stefan Monnier <monn...@iro.umontreal.ca> writes:
>>> I think the real issue here is that hi-lock should have a customizable
>>> set of faces rather than a set of customizable faces.
>>> So if the user doesn't like hi-yellow (which should be called
>>> hi-lock-yellow, BTW) because she never highlights in yellow, she can
>>> replace it with her own face with the name she likes.
>> Ah, in that case you are really talking, I think, about having one or
>> more user options, which each has a face (or a set of faces) as value.
> Just one option `hi-lock-faces'.
1. I want the name to be opaque and semantic.
2. I also want a pre-defined set of faces for highlighting apart from
the one "core" highlight face. I think there are 9 hi-* faces and
these numbers are good enough.
Think of them as extra colors in my palette.
Having a set of highlighting faces will help in theming. For
example, consider finding file in ido-mode. When I do C-x C-f, I see
various faces - the minibuffer prompt, ido-first-match, ido-subdir,
ido-indicator all occurring /next/ to each other. If there are
hi-lock-N faces, chosen by a theme designed, one can simply have ido
faces inherit from these themed faces. It is much cleaner.
Remember choosing faces that can co-exist in buffer without much
trouble to eyes is challenging task - one needs to balance harmony
and contrast. A theme designer is likely to work with a palette and
can go with color-picking techniques like triad, tetrad schemes. See
Triad and tetrads apparently are colors that are 120 and 90 degrees
apart in the color wheel. So if there are N highlighting faces, they
can be spaced 360/N degree apart in a color wheeel.
Drew's reasoning that it is the N-th highlighting face in a sequence.
3. Configuring an yellow face in red is a bit ugly. It is declaring a
variable name FALSE that is assigned a variable value true.
>> Just why would you prefer a "customizable set of faces" over a "set of
>> customizable faces"? And how does that relate to the names?
> Because the user can then choose the names that make sense to her.
While reading a face name from minibuffer, if the face name itself is
highlighted in that face - think rainbow mode - then the name of the
face shouldn't matter.
What you are asking for is a constant face whose properties don't change
at all. One can have an elpa packages which provides constant faces,
that are immediately useful.
> Issue-2: Various issues with unhighlighting > ============================================
> Once you fix Issue-1 you will run in to other issues with
> un-highlighting. Try highlighting and UN-highlighting in following 3
> ways
> 1. Buffer with font-lock-mode ON
> 2. Buffer with font-lock-mode OFF
> 3. Unhighlight from the menu
> Caveat: Extra testing needed if /type/ of face names are changed > =================================================================
> hi-lock-face-defautls is currently a list of face names (stringp). If
> it is made a defcustom, it will be cast to a list of symbols (symbolp).
> In some places, face names are expected and in some other places face as
> a symbol is used. So you need to re-run the tests if move from
> string->symbols.
> Suggestion: In default faces, don't mix bold and foreground/background
> =======================================================================
> Bonus points if the default settings of the faces that go in there is
> revised as part of this bug. I want to highlight variables in a buffer.
> So consistent policy of highlighting - a changed background of normal
> face - will require no additional work.
> Here is how my own faces look like. Note that the first 4 come from
> "blue" space and the later 4 or so come from "pink" space, all chosen
> using agave.
> ps: I will let you install a change for the above issues.
> Issue-2: Various issues with unhighlighting > ============================================
> Once you fix Issue-1 you will run in to other issues with
> un-highlighting. Try highlighting and UN-highlighting in following 3
> ways
> 1. Buffer with font-lock-mode ON
> 2. Buffer with font-lock-mode OFF
> 3. Unhighlight from the menu
Seems to be working now (haven't tried before my recent changes, tho).
I think it'd be important to make it possible/easy for the user to add
new faces of his own creation in there. So we'd need a :setter that
creates those faces as needed.
BTW, I wouldn't spend too much time on hi-lock-auto-select-face since
setting it to t just saves you from typing RET RET instead of RET.
I'm not even sure we want to keep such configuration.
> I think it'd be important to make it possible/easy for the user to add
> new faces of his own creation in there. So we'd need a :setter that
> creates those faces as needed.
The code still defines and uses faces named for colors. Bad idea. There is no
need for that, and nothing gained by it.
Look at the doc for each of those faces - it should give you a clue.
It says only that this is a face for hi-lock mode. It says nothing about the
color that is in the name, and rightfully so.
The default color used to define the face is irrelevant to the
use/meaning/purpose of the face. These faces should be renamed.
If you need a separate bug report for that I will be glad to file it.
>> Issue-2: Various issues with unhighlighting >> ============================================
>> Once you fix Issue-1 you will run in to other issues with
>> un-highlighting. Try highlighting and UN-highlighting in following 3
>> ways
>> 1. Buffer with font-lock-mode ON
>> 2. Buffer with font-lock-mode OFF
>> 3. Unhighlight from the menu
> Seems to be working now (haven't tried before my recent changes, tho).
By now, if you mean 111134, the unhighlighting is not working as
expected.
My patch has hints on where the brokenness comes from.
>> Seems to be working now (haven't tried before my recent changes, tho).
> By now, if you mean 111134, the unhighlighting is not working as
> expected.
>>>> Seems to be working now (haven't tried before my recent changes, tho).
>>> By now, if you mean 111134, the unhighlighting is not working as
>>> expected.
>> Can you give a recipe, because "it works for me",
> How about a screenshot?
That can work as well, tho since it's not a display problem,
explanations work at least as well, usually better.
I never use hi-lock, so don't assume I know how it's expected to behave.
> Recipe-1:
> Couple of C-x w h, followed by C-x w r. Note the cursor position
> and the choice offered.
I don't see anything wrong with the cursor position. Please explain.
> See screenshot. Why is there no default offered
Don't know, should there be one?
> and why even absurd candidates are offered?
Which absurd candidates are you talking about?
> Recipe-2:
> Turn off font-lock-mode.
> Couple of C-x w h and then try C-x w r, C-u C-x w r, try from menu.
Stefan Monnier <monn...@iro.umontreal.ca> writes:
>>>>> Seems to be working now (haven't tried before my recent changes, tho).
>>>> By now, if you mean 111134, the unhighlighting is not working as
>>>> expected.
>>> Can you give a recipe, because "it works for me",
>> How about a screenshot?
> That can work as well, tho since it's not a display problem,
> explanations work at least as well, usually better.
> I never use hi-lock, so don't assume I know how it's expected to
> behave.
This is the behaviour I am expecting. This is what I
circulated in etc/NEWS entry.
*** Unhighlighting command (`hi-lock-unface-buffer') now un-highlights
text at point. When called interactively with C-u, removes all
highlighting in current buffer.
We seem to be talking too much but not taking a moment to understand to
each other. I will exchange no more mails with you in this thread,
sorry. You reply, but with no effort on your part to understand what I
am saying or showing you. I am happy with whatever you conceive to be
useful.
