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

[Juri Linkov <juri@linkov.net>]

>> This means dozens of new options for every possible command that uses
>> the minibuffer: occur-lazy-highlight, keep-lines-lazy-highlight,
>> flush-lines-lazy-highlight, kill-matching-lines-lazy-highlight,
>> copy-matching-lines-lazy-highlight, how-many-lazy-highlight, ...
>
> I'm experimenting with adding lazy-highlight directly into
> `read-regexp', controlled by a new option `read-regexp-lazy-highlight',
> which, preferably, would be t by default.  Thus, in particular, all the
> above commands would get lazy-highlight by default.
>
> At first this felt somewhat intrusive, and third-party code might
> require adaptation.  The advantage is that the said adaptation is very
> easy.  Namely, a package author would have three options:
>
> - Do nothing.  Then read-regexp will have lazy highlighting as dictated
>   by read-regexp-lazy-highlight.
> - If lazy-highlighting makes no sense at all in a given context, then
>   let-bind read-regexp-lazy-highlight to nil.
> - If customizability is desired, define `package-X-lazy-highlight' and
>   let-bind read-regexp-lazy-highlighting to that.
>
> What do you think?  (This is probably also the approach with the minimal
> number of additional code/changed lines, which seems to be desirable.)

Sorry, I have no idea who and how might want to use lazy-highlighting
in the minibuffer.  I'd just provide a hook that any user can add
to the minibuffer-setup-hook, or any package author can add
to minibuffer-with-setup-hook.  But in any case we need more opinions.