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

[Augusto Stoffel <arstoffel@gmail.com>]

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

On Fri,  1 Apr 2022 at 19:35, Juri Linkov <juri@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:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: occur.patch --]
[-- Type: text/x-patch, Size: 714 bytes --]

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")

[-- Attachment #3: Type: text/plain, Size: 1040 bytes --]


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:


[-- Attachment #4: anzu.png --]
[-- Type: image/png, Size: 69493 bytes --]

[-- Attachment #5: Type: text/plain, Size: 158 bytes --]


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.