emacs-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]