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

Previous Next

Full log

Message #145 received at 53126 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Augusto Stoffel <arstoffel <at> gmail.com>
Cc: 53126 <at> debbugs.gnu.org
Subject: Re: bug#53126: 29.0.50; [PATCH] Lazy highlight/count when reading
 query-replace string, etc.
Date: Sat, 02 Apr 2022 21:23:10 +0300

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

Previous Next

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