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

[Augusto Stoffel]

On Thu, 17 Mar 2022 at 22:40, Juri Linkov <juri@linkov.net> wrote:

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

Dmitry -- I've CC'ed you because I noticed project.el makes a bunch of
calls to read-regexp, and also a call query-replace-read-args at one
point.  To summarize the story here: would you like to have lazy
highlight and lazy count (in “anzu” style) while reading regexps and
query-replace arguments in package.el?  How fine-grained would you like
the user options to be here, and what should the defaults be?