GNU bug report logs - #53126
29.0.50; [PATCH] Lazy highlight/count when reading query-replace string, etc.

Previous Next

Full log

View this message in rfc822 format

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 53126 <at> debbugs.gnu.org
Subject: bug#53126: 29.0.50; [PATCH] Lazy highlight/count when reading query-replace string, etc.
Date: Fri, 01 Apr 2022 20:12:32 +0200

[Message part 1 (text/plain, inline)]

On Fri,  1 Apr 2022 at 19:35, Juri Linkov <juri <at> linkov.net> wrote:

> Why do you think query-replace is more complex than other minibuffer commands?
> Other minibuffer commands need to set all the same a dozen of variables that
> control lazy highlighting.  Otherwise, they will highlight some random matches
> that happen to reuse values left from a previous isearch.

Without having tested, the lazy highlight feature for occur would only
require the addition of 4 lines:

[occur.patch (text/x-patch, inline)]

diff --git a/lisp/replace.el b/lisp/replace.el
index a56e493d99..cd1bf9057f 100644
--- a/lisp/replace.el
+++ b/lisp/replace.el
@@ -1741,7 +1741,11 @@ occur-excluded-properties
   :version "22.1")
 
 (defun occur-read-primary-args ()
-  (let* ((perform-collect (consp current-prefix-arg))
+  (when isearch-lazy-highlight
+    (add-hook 'minibuffer-setup-hook 'minibuffer-lazy-highlight-setup))
+  (let* ((isearch-regexp t)
+         (isearch-case-fold-search case-fold-search)
+         (perform-collect (consp current-prefix-arg))
          (regexp (read-regexp (if perform-collect
                                   "Collect strings matching regexp"
                                 "List lines matching regexp")

[Message part 3 (text/plain, inline)]

So yes, I'd say query-replace is very likely to be most complex case
there will be.  And it has several unique features that make it quite
different from other potential uses of lazy highlight:

- The splitting of the TO and FROM strings at "->".
- The value of case-fold-search can change on the fly
- We must clean up the highlight only if the user quits, to avoid
  flickering at the beginning of the perform-replace stage.

Okay, as I write this I realize occur would require some special stuff
if the region is active.  This indeed should be factored out.  But
hopefully you will agree with the 3 points above :-).

>> Right, a preview of the replacement text will also need some extra work.
>> This will probably involve some extension to
>> 'isearch-lazy-highlight-update', making it even more complicated...
>
> Why?  Shouldn't it just highlight the same way the text
> entered into the minibuffer that reads the replacement?

I'm referring to the anzu feature whereby the replacement text is shown
next to each match, like this:

[anzu.png (image/png, inline)]

[Message part 5 (text/plain, inline)]

This will not be totally trivial to implement, right?  And it will add
some extra stuff to query-replace-read-args that is very much
query-replace specific.

Previous Next

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