bug#11095: [FINAL] Re: bug#11095: 24.0.94; hi-lock-face-buffer/unhighlight-regexp': Augment?

[Jambunathan K]

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

bug11095-final-r110525.diff
Description: Text Data

bug11095-r110501.diff
Description: Text Data

bug11095-r110502.diff
Description: Text Data

bug11095-r110503.diff
Description: Text Data

bug11095-r110504.diff
Description: Text Data

bug11095-r110505.diff
Description: Text Data

> 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
>    highlighting.)
>
> 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
>    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.