Il 28/02/24 15:06, Basil L. Contovounesios ha scritto:
Gabriele Nicolardi [2024-02-26 19:02 +0100] wrote:
if I consult the definition of isearch-filter-predicate, I find:
Predicate to filter hits of Isearch and replace commands. Isearch hits
that don’t satisfy the predicate will be skipped.
Over the years, I have found this option very useful as it allows me to perform
targeted searches and replacements in certain parts of the LaTeX documents I
edit for work.
For example, by creating custom predicates, I can ensure that I operate only on
the mathematical part of the document, or only on cross-reference labels; I can
ignore comments inserted by the authors, and so on.
Unfortunately, however, some functions such as occur, search-forward-*,
string-match*, do not take this variable into account.
[...]
However, I couldn’t modify, for instance, occur and string-match(-p). Is there
a reason why these functions don’t adopt this mechanism? Or is it simply a lack
of interest in implementing this option?
isearch-filter-predicate is a user option of the isearch library, which
provides users with convenient, incremental search functionality.
OTOH search-forward, re-search-forward, and string-match are low-level
Elisp matching primitives (even if the first two can be called
interactively): I don't think they should be concerned with the user
options that a user-facing incremental search feature provides.
IOW, Elisp libraries need a simple and reliable way to match strings and
regexps for many of their core functions, outside the influence of any
user-facing conveniences. Existing code relies on the current contract
of string-match & co., and could break if expected matches were skipped
because of isearch-filter-predicate. The fact that these primitives
obey case-fold-search alone already catches some people off guard.
(I understand that the “i” in [i]search stands for interactive,
[ I suspect it stands for incremental.
Or the selfish first person singular pronoun ;). ]
It make sense to open a feature request?
I think it could make sense for occur to obey isearch-filter-predicate,
since it's a more closely related user-facing utility (occur is defined
in the same library as other commands which use
isearch-filter-predicate). If you submit a feature request, others
could be in a better position than me to judge.
Thanks.