[PATCH] isearch: lazy-highlighting of sub-exps of regexps

[PATCH] isearch: lazy-highlighting of sub-exps of regexps

[Andrew Helsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 382 bytes --]

Hi,

Attached is a patch for `isearch-mode'.  With this enhancement, the user 
can easily see examples of what the groups in their regular expressions 
capture as they type them.  Using this feedback should make it easier for 
the user to accurately build a replacement string when they invoke 
`query-replace-regexp' directly from `isearch-mode'.

--------
regards,
Andrew Helsley

[-- Attachment #2: Type: TEXT/PLAIN, Size: 4993 bytes --]

diff -r -c emacs-1/lisp/ChangeLog emacs-2/lisp/ChangeLog
*** emacs-1/lisp/ChangeLog	2010-11-22 00:28:12.000000000 -0800
--- emacs-2/lisp/ChangeLog	2010-11-22 00:42:23.000000000 -0800
***************
*** 1,3 ****
--- 1,9 ----
+ 2010-11-22  Andrew Helsley <helsleya@cs.ucr.edu>
+ 
+ 	* isearch.el: Added lazy-highlighting of up to 9 sub-expressions of
+ 	isearch regexps using different faces for each
+ 	(isearch-lazy-highlight-propertize-one-match).
+ 
  2010-11-22  Tassilo Horn  <tassilo@member.fsf.org>
  
  	* textmodes/reftex-ref.el (reftex-goto-label): Use the current
diff -r -c emacs-1/lisp/isearch.el emacs-2/lisp/isearch.el
*** emacs-1/lisp/isearch.el	2010-11-21 22:57:58.000000000 -0800
--- emacs-2/lisp/isearch.el	2010-11-22 00:37:55.000000000 -0800
***************
*** 2581,2586 ****
--- 2581,2590 ----
  (defvar isearch-lazy-highlight-regexp nil)
  (defvar isearch-lazy-highlight-space-regexp nil)
  (defvar isearch-lazy-highlight-forward nil)
+ (defvar isearch-lazy-highlight-last-capture-face 9)
+ (defvar isearch-lazy-highlight-minimum-overlay-priority 1000
+   "Minimum priority to assign to `isearch' mode overlays.
+ 1000 is higher than `ediff's 100+.")
  
  (defun lazy-highlight-cleanup (&optional force)
    "Stop lazy highlighting and remove extra highlighting from current buffer.
***************
*** 2717,2729 ****
  			      (forward-char -1)))
  
  			;; non-zero-length match
! 			(let ((ov (make-overlay mb me)))
! 			  (push ov isearch-lazy-highlight-overlays)
! 			  ;; 1000 is higher than ediff's 100+,
! 			  ;; but lower than isearch main overlay's 1001
! 			  (overlay-put ov 'priority 1000)
! 			  (overlay-put ov 'face lazy-highlight-face)
! 			  (overlay-put ov 'window (selected-window))))
  		      (if isearch-lazy-highlight-forward
  			  (setq isearch-lazy-highlight-end (point))
  			(setq isearch-lazy-highlight-start (point)))))
--- 2721,2727 ----
  			      (forward-char -1)))
  
  			;; non-zero-length match
! 			(isearch-lazy-highlight-propertize-one-match))
  		      (if isearch-lazy-highlight-forward
  			  (setq isearch-lazy-highlight-end (point))
  			(setq isearch-lazy-highlight-start (point)))))
***************
*** 2747,2752 ****
--- 2745,2801 ----
  		    (run-at-time lazy-highlight-interval nil
  				 'isearch-lazy-highlight-update)))))))))
  
+ (defun isearch-lazy-highlight-propertize-one-match ()
+   "Propertize the groups of the most recent regexp match."
+   (let* ((matches   (match-data))
+ 	 (n	    0))
+     (while (>= (length matches) 2)
+       (let* ((m   (min n isearch-lazy-highlight-last-capture-face))
+ 	     (beg (car matches))
+ 	     (end (cadr matches))
+ 	     (ov  (make-overlay beg end)))
+ 	(push ov isearch-lazy-highlight-overlays)
+ 	(overlay-put ov 'priority (+ isearch-lazy-highlight-minimum-overlay-priority n))
+ 	(overlay-put ov 'face (intern (format "isearch-lazy-highlight-capture-%02d" m)))
+ 	(overlay-put ov 'window (selected-window)))
+       (setq n (1+ n))
+       (setq matches (cddr matches)))))
+ 
+ (eval-when-compile (require 'cl))
+ (flet ((isearch-lazy-highlight-define-capture-face
+ 	(num foreground-color background-color &rest other-face-attributes)
+ 	(custom-declare-face (intern (format "isearch-lazy-highlight-capture-%02d" num))
+ 			     `((((background dark))
+ 				(:background	,foreground-color
+ 				 :foreground	,background-color
+ 				 :underline	,(> num 0)
+ 				 :overline	,(> num 1)
+ 				 ,@other-face-attributes
+ 				 :inherit	lazy-highlight))
+ 			       (((background light))
+ 				(:background	,background-color
+ 				 :foreground	,foreground-color
+ 				 :underline	,(> num 0)
+ 				 :overline	,(> num 1)
+ 				 ,@other-face-attributes
+ 				 :inherit	lazy-highlight))
+ 			       (t
+ 				(:underline	t)))
+ 			       (concat "Face for lazy highlighting group "
+ 				       (number-to-string num)
+ 				       " of a regexp search.")
+ 			       :group 'lazy-highlight :group 'basic-faces)))
+   (isearch-lazy-highlight-define-capture-face 0 nil "cyan")
+   (isearch-lazy-highlight-define-capture-face 1 "blue" "yellow" :weight 'bold)
+   (isearch-lazy-highlight-define-capture-face 2 "blue" "green" :weight 'bold)
+   (isearch-lazy-highlight-define-capture-face 3 "white" "magenta" :weight 'bold)
+   (isearch-lazy-highlight-define-capture-face 4 "yellow" "red" :weight 'bold)
+   (isearch-lazy-highlight-define-capture-face 5 "yellow" "blue" :weight 'bold)
+   (isearch-lazy-highlight-define-capture-face 6 "white" "blue" :weight 'bold)
+   (isearch-lazy-highlight-define-capture-face 7 "cyan" "blue" :weight 'bold)
+   (isearch-lazy-highlight-define-capture-face 8 "magenta" "blue" :weight 'bold)
+   (isearch-lazy-highlight-define-capture-face 9 "green" "blue" :weight 'bold))
+ 
  (defun isearch-resume (string regexp word forward message case-fold)
    "Resume an incremental search.
  STRING is the string or regexp searched for.

Re: [PATCH] isearch: lazy-highlighting of sub-exps of regexps

[Juri Linkov]

> Attached is a patch for `isearch-mode'.  With this enhancement, the user
> can easily see examples of what the groups in their regular expressions
> capture as they type them.  Using this feedback should make it easier for
> the user to accurately build a replacement string when they invoke
> query-replace-regexp' directly from `isearch-mode'.

Thanks, but we already have a request in the bug database with a set
of different patches to implement it: http://debbugs.gnu.org/6227
There is no decision yet what is the best of them.

Re: [PATCH] isearch: lazy-highlighting of sub-exps of regexps

[Stefan Monnier]

>> Attached is a patch for `isearch-mode'.  With this enhancement, the user
>> can easily see examples of what the groups in their regular expressions
>> capture as they type them.  Using this feedback should make it easier for
>> the user to accurately build a replacement string when they invoke
>> query-replace-regexp' directly from `isearch-mode'.

Of course, to make it yet a bit easier, we should provide an "ireplace"
mode (where the replacement is shown incrementally as the user types
the replacement spec).

> Thanks, but we already have a request in the bug database with a set
> of different patches to implement it: http://debbugs.gnu.org/6227
> There is no decision yet what is the best of them.

Could someone take a close look and install such a feature?


        Stefan

Re: [PATCH] isearch: lazy-highlighting of sub-exps of regexps

[Juri Linkov]

>>> Using this feedback should make it easier for the user to accurately
>>> build a replacement string when they invoke query-replace-regexp'
>>> directly from `isearch-mode'.

This supposes that lazy-highlighting is not removed at the time
when the user types the replacement in the minibuffer.

> Of course, to make it yet a bit easier, we should provide an "ireplace"
> mode (where the replacement is shown incrementally as the user types
> the replacement spec).

Should this interactive replacement modify the buffer or
just show replacements using e.g. overlays?

>> Thanks, but we already have a request in the bug database with a set
>> of different patches to implement it: http://debbugs.gnu.org/6227
>> There is no decision yet what is the best of them.
>
> Could someone take a close look and install such a feature?

The most difficult question (as usual) is color selection
for sub-exps faces.  I think the most intuitive would be a rainbow.

Re: [PATCH] isearch: lazy-highlighting of sub-exps of regexps

[Stefan Monnier]

>> Of course, to make it yet a bit easier, we should provide an "ireplace"
>> mode (where the replacement is shown incrementally as the user types
>> the replacement spec).
> Should this interactive replacement modify the buffer or
> just show replacements using e.g. overlays?

Beggars can't be choosers.

>>> Thanks, but we already have a request in the bug database with a set
>>> of different patches to implement it: http://debbugs.gnu.org/6227
>>> There is no decision yet what is the best of them.
>> Could someone take a close look and install such a feature?
> The most difficult question (as usual) is color selection
> for sub-exps faces.  I think the most intuitive would be a rainbow.

Well, let's first install one of those patches and then see what
improvements are needed.  So what matters is not really the color
selection, but the cleanliness of the code so we can easily change the
color selection.


        Stefan

RE: [PATCH] isearch: lazy-highlighting of sub-exps of regexps

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 1652 bytes --]

> > The most difficult question (as usual) is color selection
> > for sub-exps faces.  I think the most intuitive would be a rainbow.
> 
> Well, let's first install one of those patches and then see what
> improvements are needed.  So what matters is not really the color
> selection, but the cleanliness of the code so we can easily change the
> color selection.

The color selection is somewhat important, IMO.  Wrt this, have a look at the
coloring I use for this kind of thing in Icicles search.

Example:
http://www.emacswiki.org/emacs/Icicles_-_Search_Commands%2c_Overview#SearchHighl
ightingContextLevels (also attached)

I use 8 search-context levels, that is, 8 regexp group levels, with a different
face for each.  Past 8 levels the face sequence repeats.

One of the attached screenshots shows the 8 faces.  For a dark background mode,
there are corresponding dark colors.  In practice these colors work pretty well.
Note that there are two subsequences, the second one (levels 5-8) being a less
saturated (paler) version of the first one (levels 1-4).

The face (color) definitions are here:
http://www.emacswiki.org/emacs/icicles-face.el

Not sure what you had in mind by "cleanliness of the code so we can easily
change the color selection".  In my case, I use separate faces, so users can
easily customize them.

I picked the default colors by tweaking (using palette.el).  I picked the
dark-background colors by starting with the complements of the light-background
colors (and then modifying a bit, IIRC).  I probably got some user feedback on
the dark-background colors (I use a light background, myself), but I don't
remember.

HTH.

[-- Attachment #2: drew-emacs-icicle-search-context-levels.png --]
[-- Type: image/png, Size: 34935 bytes --]

[-- Attachment #3: drew-emacs-icicle-search-context-colors.png --]
[-- Type: image/png, Size: 11424 bytes --]

Re: [PATCH] isearch: lazy-highlighting of sub-exps of regexps

[Juri Linkov]

> I picked the default colors by tweaking (using palette.el).  I picked the
> dark-background colors by starting with the complements of the light-background
> colors (and then modifying a bit, IIRC).  I probably got some user feedback on
> the dark-background colors (I use a light background, myself), but I don't
> remember.

I'm tempted to try a rainbow, because it has a very intuitive palette.

RE: [PATCH] isearch: lazy-highlighting of sub-exps of regexps

[Drew Adams]

> > I picked the default colors by tweaking (using palette.el). 
> > I picked the dark-background colors by starting with the
> > complements of the light-background colors (and then
> > modifying a bit, IIRC).  I probably got some user feedback on
> > the dark-background colors (I use a light background, 
> > myself), but I don't remember.
> 
> I'm tempted to try a rainbow, because it has a very intuitive palette.

FWIW, I deliberately did not do that.

Successive levels should have colors that are quite distinctive; otherwise it
can be more difficult to distinguish their boundaries.  IOW, instead of red
yellow green cyan blue magenta, mix it up so that near hues are not adjacent:
cyan is not next to green or blue, etc.

The order, in the sense of group level, is not significant (helpful).  If it
were, then you could perhaps argue in favor of rainbow order: Seeing green you
could look for cyan as the next level (numerically) etc.

All that is important in terms of matching is visual distinction: telling where
one match ends and the next (adjacent) one begins; that is, distinguishing one
group from another. Cyan is easier to distinguish from red, yellow, or magenta
than it is from green or blue.

But arguments are one thing.  Another is to experiment.