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

[Jambunathan K]

Juri Linkov <juri@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.