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

[Gabriele Nicolardi]

This is an example of what I do:

(defmacro with-ifp-predicates (PREDICATES &rest body)
  "Allows assigning a list of predicates to the
variable `isearch-filter-predicate'.

Below is an example of usage:

(with-ifp-predicates '(skip-maths skip-comments)
  (query-replace \"foo\" \"bar\" nil (point-min) (point-max)))"
  (declare (indent 1))
  `(let ((isearch-filter-predicate isearch-filter-predicate))
     (mapc (lambda (predicate)
               (add-function :before-while isearch-filter-predicate predicate))
             ,PREDICATES)
     ,@body))

I always use let-binding for operations that involve isearch-filter-predicate.

In some cases, I would like to have something like this:

(with-ifp-predicates '(predicate1 predicate2)
  (save-window-excursion
    (occur "foo")
    (query-replace \"foo\" \"bar\" nil (point-min) (point-max))))

with occur showing me only the strings that match the active predicates.

The idea of a new variable that can use the same values as isearch-filter-predicate works for me.

Il 28/02/24 17:53, Drew Adams ha scritto:

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