On Wed, 27 Apr 2022 at 10:44, Juri Linkov wrote: >>> Maybe this is caused by minibuffer-lazy-highlight-setup >>> that sets filter to replace--region-filter in the minibuffer >>> instead of the original buffer? >> >> Most likely, yes. `replace--region-filter' is modified globally, so a >> similar problem should happen if you temporarily leave the minibuffer >> and do Isearch in any other buffer. >> >> If that's the case, I think we would have two options: >> >> 1) Add a quick fix for the minibuffer Isearch only. >> >> 2) A more complicated change that solves the issue generally by saving >> the region filter in the fashion of isearch-lazy-highlight-regexp et >> alii. >> >> WDYT? > > Recently we fixed a similar problem in `perform-replace' > by creating a dynamically bound value in `let': > > (let ((opos (point-marker)) > ;; Restore original isearch filter to allow > ;; using isearch in a recursive edit even > ;; when perform-replace was started from > ;; `xref--query-replace-1' that let-binds > ;; `isearch-filter-predicate' (bug#53758). > (isearch-filter-predicate #'isearch-filter-visible)) > > So maybe a buffer-local value of `isearch-filter-predicate' > in the minibuffer would help. Yes, that indeed solves the problem. See attached patch. > Also I recommend to make all hooks in `minibuffer-lazy-highlight-setup' > local by adding the argument LOCAL to add-hook/remove-hook. Indeed, the minibuffer lazy highlight feature is currently incompatible with recursive minibuffers. The patch fixes that as well. There's a caveat, though: isearch in a recursive minibuffer is again affected by the presence of an inappropriate filter function. Fixing that in a robust way might require a bigger refactoring of the lazy highlight feature, I think. Another option might be to make `replace--region-filter' also check for the value of `(current-buffer)'.