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

[Juri Linkov <juri@linkov.net>]

>> 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:

I could test it, but I'm quite sure 4 lines would not be sufficient,
because lazy-highlight relies on much more isearch variables.

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

Agreed.

> - The value of case-fold-search can change on the fly

Please clarify when it can be changed 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.

I don't know how important is to avoid flickering at the beginning,
when it flickers after every replacement anyway.

> 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 :-).

I agreed on 1.5 points :-)

>>> 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:
>
> 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.

I very much doubt in usefulness of such a feature.  I thought it could
simply highlight the replacement text to show the places in the buffer
that already contain such replacement text.