From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gabriele Nicolardi Newsgroups: gmane.emacs.devel Subject: Re: Why don't `occur`, `search-forward*` and `string-match*` respect `isearch-filter-predicate`? Date: Wed, 28 Feb 2024 15:24:29 +0100 Message-ID: References: <87zfvkadjo.fsf@epfl.ch> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------nmLLN6y3Z3KZUibb2stK8lxk" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36507"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: emacs-devel@gnu.org To: "Basil L. Contovounesios" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Feb 28 16:46:41 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rfM8n-0009JR-3G for ged-emacs-devel@m.gmane-mx.org; Wed, 28 Feb 2024 16:46:41 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rfM7d-0004p1-LH; Wed, 28 Feb 2024 10:45:29 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rfKrQ-0005wk-AG for emacs-devel@gnu.org; Wed, 28 Feb 2024 09:24:40 -0500 Original-Received: from smtp04.cbsolt.net ([185.97.217.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rfKrN-000461-Hw for emacs-devel@gnu.org; Wed, 28 Feb 2024 09:24:40 -0500 Original-Received: from [10.0.2.15] (host-79-16-242-199.retail.telecomitalia.it [79.16.242.199]) by smtp04.cbsolt.net (Postfix) with ESMTPSA id 4TlGnr3xGkz3wZc; Wed, 28 Feb 2024 15:24:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cbsolt.net; s=201504-di4k2w; t=1709130274; bh=wADB0rUntx+KZp1nS49L4muW2lHBWl5/d+jFv5oEkD4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=NH1YrsDrraVC1ODJm8V1F+sIBofsjkIAoFOsjjwuene3LaoNFPPdKo6oI+F/MYf2s dOITD42Pm+KB7g5iawCQcEo4CySzPvyYgw+nte/Vp0IQ2q8WmfNwjQEIwgZzL7lanH O9j3CyVYpAZEn4fkeZV0GBcVuG+oHcuHQyeav5gQ= Content-Language: en-US In-Reply-To: <87zfvkadjo.fsf@epfl.ch> Received-SPF: pass client-ip=185.97.217.43; envelope-from=gabriele@medialab.sissa.it; helo=smtp04.cbsolt.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Wed, 28 Feb 2024 10:45:23 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:316623 Archived-At: This is a multi-part message in MIME format. --------------nmLLN6y3Z3KZUibb2stK8lxk Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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. I have already written modified versions of |search-forward*| and |search-backward*| that I have tested and regularly use. I suppose I could ask for a modified version of |match-string*| that adheres to |isearch-filter-predicate|. As for |occur|, it would be useful if this function adhered to |isearch-filter-predicate| by default. Alternatively, this behavior could be managed through a variable. Now that I think about it, the same thing could apply to |search-forward*|, adding the possibility of adhering to |isearch-filter-predicate| through the setting of a variable. Gabriele Nicolardi > Thanks, --------------nmLLN6y3Z3KZUibb2stK8lxk Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

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.

I have already written modified versions of search-forward* and search-backward* that I have tested and regularly use. I suppose I could ask for a modified version of match-string* that adheres to isearch-filter-predicate. As for occur, it would be useful if this function adhered to isearch-filter-predicate by default. Alternatively, this behavior could be managed through a variable.

Now that I think about it, the same thing could apply to search-forward*, adding the possibility of adhering to isearch-filter-predicate through the setting of a variable.

Gabriele Nicolardi

Thanks,
--------------nmLLN6y3Z3KZUibb2stK8lxk--