RE: [External] : Re: Why don't `occur`, `search-forward*` and `string-match*` respect `isearch-filter-predicate`?

[Drew Adams]

Dunno whether it makes sense to have such
a variable, to allow code to change the
behavior of calls to such functions (e.g.
by let-binding it around such code).  I
think it's maybe something to consider.

But if that were done, it should be a new
variable, not `isearch-filter-predicate'.

`isearch-filter-predicate' needs to be
separate, for use by Isearch, query-* etc.,
which are essentially for interactive use.

Their interactive use can even let users
change the predicate (thus filtering) on
the fly (e.g. by advising its value):

https://www.emacswiki.org/emacs/DynamicIsearchFiltering

Values for `isearch-filter-predicate'
shouldn't affect the use of the functions
you mention.  That would be wildly unfair
to such code. ;-)  And the new variable
shouldn't directly affect Isearch etc.

As Basil mentioned, however, `occur', as
such, is also interactive.  A case could
I think be made for it too to respect
`isearch-filter-predicate'.  (Maybe this
was already considered at some point?)

Of course nothing prevents code for which
it makes sense to bind the new variable
(assuming one) to the current value of
`isearch-filter-predicate'.

Similarly, nothing prevents some code/user
from binding `isearch-filter-predicate'
to the current value of the new variable.

IOW, they should be different, but their
values can easily be made the same for
some context/use.

In sum, a new, separate variable could be
used for "worker" functions not directly
related to interactive use.  Variable
`isearch-filter-predicate' shouldn't
affect such functions directly, IMO.