[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why don't `occur`, `search-forward*` and `string-match*` respect `is
From: |
Basil L. Contovounesios |
Subject: |
Re: Why don't `occur`, `search-forward*` and `string-match*` respect `isearch-filter-predicate`? |
Date: |
Wed, 28 Feb 2024 15:06:35 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
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,
--
Basil