From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.ciao.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#34150: 26.1; Document filtering with `isearch-filter-predicate' in Elisp manual Date: Mon, 21 Jan 2019 10:18:23 -0800 (PST) Message-ID: <8c88ff94-e322-4754-b74a-c792512ec277@default> References: <8c207ca2-39ae-4ec1-acbd-358165964319@default> <83o98a9e2l.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.org; posting-host="ciao.gmane.org:195.159.176.228"; logging-data="132571"; mail-complaints-to="usenet@ciao.gmane.org" Cc: 34150-done@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jan 21 19:53:53 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1glehc-000Xw1-9A for geb-bug-gnu-emacs@m.gmane.org; Mon, 21 Jan 2019 19:53:44 +0100 Original-Received: from localhost ([127.0.0.1]:57971 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gleay-0005PH-Vb for geb-bug-gnu-emacs@m.gmane.org; Mon, 21 Jan 2019 13:46:53 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:55033) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gleA4-0006Ne-0g for bug-gnu-emacs@gnu.org; Mon, 21 Jan 2019 13:19:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gleA3-0006JU-3n for bug-gnu-emacs@gnu.org; Mon, 21 Jan 2019 13:19:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41141) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gleA3-0006JF-0G for bug-gnu-emacs@gnu.org; Mon, 21 Jan 2019 13:19:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gleA2-0004JT-Rw for bug-gnu-emacs@gnu.org; Mon, 21 Jan 2019 13:19:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Jan 2019 18:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34150 X-GNU-PR-Package: emacs Original-Received: via spool by 34150-done@debbugs.gnu.org id=D34150.154809472016539 (code D ref 34150); Mon, 21 Jan 2019 18:19:02 +0000 Original-Received: (at 34150-done) by debbugs.gnu.org; 21 Jan 2019 18:18:40 +0000 Original-Received: from localhost ([127.0.0.1]:40421 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gle9f-0004Ih-Ib for submit@debbugs.gnu.org; Mon, 21 Jan 2019 13:18:39 -0500 Original-Received: from userp2130.oracle.com ([156.151.31.86]:57250) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gle9d-0004IT-I5 for 34150-done@debbugs.gnu.org; Mon, 21 Jan 2019 13:18:38 -0500 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id x0LIDxA6084701; Mon, 21 Jan 2019 18:18:31 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=DcoGrH/6XbuDFKmoAgdkqeGhnW4u1paF8qiY/ypjY0Y=; b=BRiukNKOroqlurL33WpUGDOtt7urn22HG8Fnh8Ll2Oz3cwc/GUXAmRbvDGGL1fieKR0M ZtcKeA1S0GR9F1zqrYzy2/9xKrbF1jTX+AswF1tem0TewXbld44oNmOHp5nd4WjKO/RB XqsMiVYeATrU9lMeq2fGYdpbpkHubGh13Rofz30iPSGSNKU6PdqKRAwUBW8FqICC3PfW W0ygyjh6V9KLBBITpZMedEWSvILTuMlNi8EDRKz8CTr4yJqa1EqQKnvgF7NL9n0I6pWi TdwwB7egdkPXMw+r6BNLRHUmfkHdXekHWGarw+JJb7JECIOr78ifzsnyeo/s/E3+hdGP jw== Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2130.oracle.com with ESMTP id 2q3uaug0m7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 21 Jan 2019 18:18:31 +0000 Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x0LIIPX2012388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 21 Jan 2019 18:18:25 GMT Original-Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x0LIIOcm025410; Mon, 21 Jan 2019 18:18:25 GMT In-Reply-To: <83o98a9e2l.fsf@gnu.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4795.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9143 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901210141 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:154650 Archived-At: > > The only doc I can find about making Isearch and `perform-replace' > (all > > of its uses) ignore/exclude certain matches is the doc string of > > variable `isearch-filter-predicate'. >=20 > I don't see why the doc string shouldn't be enough. This is a quite > obscure feature, so I don't think it warrants to be described in the > manual. I disagree that it is obscure - or that it should be, at least. But of course if it is not well documented and it is (still) hardly ever used by Emacs itself then it will not necessarily be noticed, understood, and used. Its current obscurity is a self-fulfilling prophecy. > > It would also be good to state whether predefined search functions > > such as `re-search-forward' respect it. (I imagine that they do > > not, but I haven't checked, and there's no doc about this AFAIK.) > > I modified the doc string to mention Isearch and replace commands. Thanks. And non-command functions such as `re-search-forward'? > > One thing that it would also be good to make extra clear is that > > filtering takes place _after_ input matching; it is not part of > > matching. >=20 > How can it be part of matching, if the filter needs to be passed the > limits of the matched text? No one contests that impossibility. But it and its consequences are not necessarily obvious - especially to a user searching, as opposed to a programmer writing a filter predicate. Isearch's handling of filter limits is very different from its handling of buffer limits, for example. A filter doesn't constrain search to be inside its limits, in the sense that the search matches take no account of such limits. This is not necessarily obvious to a _user_. (It might or might not be clear to some programmer who defines the filter.) You can easily notice this as a user if you try to regexp-search when a filter excludes text outside a rectangle or a set of columns, for instance. A user could easily, and incorrectly, expect the rectangle to "contain" search, similarly to how a buffer restriction contains it. She could ask herself how it is that a regexp with `.*' doesn't "match" some particular text within the rectangle, the answer being that it instead matched longer text that extended outside the rectangle, and that match was filtered out. If this user-level description makes no sense to you I expect it's because you haven't played with filters enough or, more likely, because you start from an understanding of the code - which a user does not. Just emphasizing explicitly that filtering takes place _after_ input matching can help, I think. As you know, filtering can in general be done before or during querying/searching/matching, as well as after it. IMO, it's worth emphasizing that this is only post-match filtering. If you ask why a _user_ needs to know about filter predicates and filtering then my answer is longer. I'll leave that out, unless you ask for it. Using `isearch-filter-predicate' can be powerful. But it is also somewhat limited/weak because filtering cannot be taken into account as part of matching. Imagine being able to contain search within a rectangle, for instance. That's something you cannot do with only `isearch-filter-predicate'. Whether or not such limitation is obvious to a particular filter writer, it certainly is not obvious to a filter user, I think.