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

Previous Next

Full log

View this message in rfc822 format

From: Jambunathan K <kjambunathan <at> gmail.com>
To: Juri Linkov <juri <at> jurta.org>
Cc: 11095 <at> debbugs.gnu.org
Subject: bug#11095: 24.0.94; hi-lock-face-buffer/unhighlight-regexp': Augment?
Date: Sat, 13 Oct 2012 22:58:58 +0530

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

Previous Next

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