From unknown Sun Jun 22 17:14:52 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34150: 26.1; Document filtering with `isearch-filter-predicate' in Elisp manual Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Jan 2019 00:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 34150 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 34150@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.15480298772625 (code B ref -1); Mon, 21 Jan 2019 00:18:01 +0000 Received: (at submit) by debbugs.gnu.org; 21 Jan 2019 00:17:57 +0000 Received: from localhost ([127.0.0.1]:39295 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1glNHo-0000gH-Gd for submit@debbugs.gnu.org; Sun, 20 Jan 2019 19:17:56 -0500 Received: from eggs.gnu.org ([209.51.188.92]:34743) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1glNHn-0000g2-0m for submit@debbugs.gnu.org; Sun, 20 Jan 2019 19:17:55 -0500 Received: from lists.gnu.org ([209.51.188.17]:45800) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1glNHh-0007UO-Ry for submit@debbugs.gnu.org; Sun, 20 Jan 2019 19:17:49 -0500 Received: from eggs.gnu.org ([209.51.188.92]:44937) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1glNHg-000722-RQ for bug-gnu-emacs@gnu.org; Sun, 20 Jan 2019 19:17:49 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_50,RCVD_IN_DNSWL_MED autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1glNHf-0007PQ-K5 for bug-gnu-emacs@gnu.org; Sun, 20 Jan 2019 19:17:48 -0500 Received: from aserp2130.oracle.com ([141.146.126.79]:33030) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1glNHf-0007OF-B1 for bug-gnu-emacs@gnu.org; Sun, 20 Jan 2019 19:17:47 -0500 Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id x0L0F68A025583 for ; Mon, 21 Jan 2019 00:17:44 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=0KZhYKg0k4awq5DxsmK7fFVrATjxxnOBTkcDfcdWk4o=; b=p/CN3HjeOnIZYzazRqbsxcgcI2gcMfyC1apAY94uwAa6H01tYQevXD51DXFak0ptDg/R 5e7oUCGbrh9Tf9C3miidqNW6kj0GQLS5KYQwcyth4yBgu4WTf6nknr3j3ElaoH54l8T1 NXRP9c5XoV9I4ovJO1FF8c7Eg0zw7uZzQZuA1ALtvKz+c50Dn0yojNrKzAhiKisxOQjA Duh9SN/SbKjkYjN+CgV2VgWzdYi82dpinPGVhBsjhcCSwMiBCbEiGyegVg1kjPPPRF4r Zxluy6V7UAMoNPgFzakiFfmR3kG2tiTiVJq5apLWWTRH4pwXs5GQMt5Mw6c/7zXKzT0Q eQ== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp2130.oracle.com with ESMTP id 2q3sde47rx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 21 Jan 2019 00:17:43 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x0L0HgDE008890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 21 Jan 2019 00:17:43 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x0L0Hgfu027413 for ; Mon, 21 Jan 2019 00:17:42 GMT MIME-Version: 1.0 Message-ID: <8c207ca2-39ae-4ec1-acbd-358165964319@default> Date: Sun, 20 Jan 2019 16:17:41 -0800 (PST) From: Drew Adams X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4795.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9142 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-1901210001 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 141.146.126.79 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) See https://emacs.stackexchange.com/q/47302/105, as one possible motivaton. 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'. And that doc string isn't very precise about the args of the predicate. It says only: "The function has two arguments: the positions of start and end of text matched by the search." It would help to add that these positions are `(match-beginning 0)' and `(match-end 0)', respectively, and to say that the match start position is the first of the two args. (Sure, start coming first is not surprising, but it also doesn't follow from the description.) I suggest adding a short topic about filtering with this predicate, perhaps with a simple example. At least mention that this is used in the predefined search commands (including Isearch) and the predefined replacement commands. 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.) You could guess no, based on the `isearch' part of the variable name. But if you guess like that then you likely won't also guess that the variable applies to `perform-replace' - it's not just about Isearch. 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. Not getting this can be a gotcha with greedy regexp matching. For example, a filter predicate that excludes matches that extend past column 70 does not keep the part of a match before column 70, even if that part also matches the same regexp. In GNU Emacs 26.1 (build 1, x86_64-w64-mingw32) of 2018-05-30 Repository revision: 07f8f9bc5a51f5aa94eb099f3e15fbe0c20ea1ea Windowing system distributor `Microsoft Corp.', version 10.0.17134 Configured using: `configure --without-dbus --host=3Dx86_64-w64-mingw32 --without-compress-install 'CFLAGS=3D-O2 -static -g3'' From unknown Sun Jun 22 17:14:52 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Drew Adams Subject: bug#34150: closed (Re: bug#34150: 26.1; Document filtering with `isearch-filter-predicate' in Elisp manual) Message-ID: References: <83o98a9e2l.fsf@gnu.org> <8c207ca2-39ae-4ec1-acbd-358165964319@default> X-Gnu-PR-Message: they-closed 34150 X-Gnu-PR-Package: emacs Reply-To: 34150@debbugs.gnu.org Date: Mon, 21 Jan 2019 16:22:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1548087722-6047-1" This is a multi-part message in MIME format... ------------=_1548087722-6047-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #34150: 26.1; Document filtering with `isearch-filter-predicate' in Elisp m= anual which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 34150@debbugs.gnu.org. --=20 34150: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D34150 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1548087722-6047-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 34150-done) by debbugs.gnu.org; 21 Jan 2019 16:21:44 +0000 Received: from localhost ([127.0.0.1]:40370 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1glcKW-0001Z4-Ig for submit@debbugs.gnu.org; Mon, 21 Jan 2019 11:21:44 -0500 Received: from eggs.gnu.org ([209.51.188.92]:47840) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1glcKU-0001Yp-KF for 34150-done@debbugs.gnu.org; Mon, 21 Jan 2019 11:21:43 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40309) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1glcKP-0006eS-1m; Mon, 21 Jan 2019 11:21:37 -0500 Received: from [176.228.60.248] (port=1401 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1glcKO-0007pz-M4; Mon, 21 Jan 2019 11:21:37 -0500 Date: Mon, 21 Jan 2019 18:21:22 +0200 Message-Id: <83o98a9e2l.fsf@gnu.org> From: Eli Zaretskii To: Drew Adams In-reply-to: <8c207ca2-39ae-4ec1-acbd-358165964319@default> (message from Drew Adams on Sun, 20 Jan 2019 16:17:41 -0800 (PST)) Subject: Re: bug#34150: 26.1; Document filtering with `isearch-filter-predicate' in Elisp manual References: <8c207ca2-39ae-4ec1-acbd-358165964319@default> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 34150-done Cc: 34150-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > Date: Sun, 20 Jan 2019 16:17:41 -0800 (PST) > From: Drew Adams > > See https://emacs.stackexchange.com/q/47302/105, as one possible > motivaton. > > 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'. 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. > And that doc string isn't very precise about the args of the predicate. > It says only: "The function has two arguments: the positions of start > and end of text matched by the search." > > It would help to add that these positions are `(match-beginning 0)' and > `(match-end 0)', respectively, and to say that the match start position > is the first of the two args. To me, "the positions of start and end of the matched text" says precisely that. I don't see what can references to match-beginning and match-end add; if anything, they might confuse, because at least some readers will be sent down the rabbit hole to the descriptions of those two, something that IMO is entirely unnecessary for writing a filter. > 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.) You could guess > no, based on the `isearch' part of the variable name. But if you guess > like that then you likely won't also guess that the variable applies to > `perform-replace' - it's not just about Isearch. I modified the doc string to mention Isearch and replace commands. > 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. How can it be part of matching, if the filter needs to be passed the limits of the matched text? ------------=_1548087722-6047-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 21 Jan 2019 00:17:57 +0000 Received: from localhost ([127.0.0.1]:39295 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1glNHo-0000gH-Gd for submit@debbugs.gnu.org; Sun, 20 Jan 2019 19:17:56 -0500 Received: from eggs.gnu.org ([209.51.188.92]:34743) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1glNHn-0000g2-0m for submit@debbugs.gnu.org; Sun, 20 Jan 2019 19:17:55 -0500 Received: from lists.gnu.org ([209.51.188.17]:45800) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1glNHh-0007UO-Ry for submit@debbugs.gnu.org; Sun, 20 Jan 2019 19:17:49 -0500 Received: from eggs.gnu.org ([209.51.188.92]:44937) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1glNHg-000722-RQ for bug-gnu-emacs@gnu.org; Sun, 20 Jan 2019 19:17:49 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_50,RCVD_IN_DNSWL_MED autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1glNHf-0007PQ-K5 for bug-gnu-emacs@gnu.org; Sun, 20 Jan 2019 19:17:48 -0500 Received: from aserp2130.oracle.com ([141.146.126.79]:33030) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1glNHf-0007OF-B1 for bug-gnu-emacs@gnu.org; Sun, 20 Jan 2019 19:17:47 -0500 Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id x0L0F68A025583 for ; Mon, 21 Jan 2019 00:17:44 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=0KZhYKg0k4awq5DxsmK7fFVrATjxxnOBTkcDfcdWk4o=; b=p/CN3HjeOnIZYzazRqbsxcgcI2gcMfyC1apAY94uwAa6H01tYQevXD51DXFak0ptDg/R 5e7oUCGbrh9Tf9C3miidqNW6kj0GQLS5KYQwcyth4yBgu4WTf6nknr3j3ElaoH54l8T1 NXRP9c5XoV9I4ovJO1FF8c7Eg0zw7uZzQZuA1ALtvKz+c50Dn0yojNrKzAhiKisxOQjA Duh9SN/SbKjkYjN+CgV2VgWzdYi82dpinPGVhBsjhcCSwMiBCbEiGyegVg1kjPPPRF4r Zxluy6V7UAMoNPgFzakiFfmR3kG2tiTiVJq5apLWWTRH4pwXs5GQMt5Mw6c/7zXKzT0Q eQ== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp2130.oracle.com with ESMTP id 2q3sde47rx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 21 Jan 2019 00:17:43 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x0L0HgDE008890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 21 Jan 2019 00:17:43 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x0L0Hgfu027413 for ; Mon, 21 Jan 2019 00:17:42 GMT MIME-Version: 1.0 Message-ID: <8c207ca2-39ae-4ec1-acbd-358165964319@default> Date: Sun, 20 Jan 2019 16:17:41 -0800 (PST) From: Drew Adams To: bug-gnu-emacs@gnu.org Subject: 26.1; Document filtering with `isearch-filter-predicate' in Elisp manual X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4795.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9142 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-1901210001 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 141.146.126.79 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) See https://emacs.stackexchange.com/q/47302/105, as one possible motivaton. 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'. And that doc string isn't very precise about the args of the predicate. It says only: "The function has two arguments: the positions of start and end of text matched by the search." It would help to add that these positions are `(match-beginning 0)' and `(match-end 0)', respectively, and to say that the match start position is the first of the two args. (Sure, start coming first is not surprising, but it also doesn't follow from the description.) I suggest adding a short topic about filtering with this predicate, perhaps with a simple example. At least mention that this is used in the predefined search commands (including Isearch) and the predefined replacement commands. 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.) You could guess no, based on the `isearch' part of the variable name. But if you guess like that then you likely won't also guess that the variable applies to `perform-replace' - it's not just about Isearch. 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. Not getting this can be a gotcha with greedy regexp matching. For example, a filter predicate that excludes matches that extend past column 70 does not keep the part of a match before column 70, even if that part also matches the same regexp. In GNU Emacs 26.1 (build 1, x86_64-w64-mingw32) of 2018-05-30 Repository revision: 07f8f9bc5a51f5aa94eb099f3e15fbe0c20ea1ea Windowing system distributor `Microsoft Corp.', version 10.0.17134 Configured using: `configure --without-dbus --host=3Dx86_64-w64-mingw32 --without-compress-install 'CFLAGS=3D-O2 -static -g3'' ------------=_1548087722-6047-1-- From unknown Sun Jun 22 17:14:52 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34150: 26.1; Document filtering with `isearch-filter-predicate' in Elisp manual 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 X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 34150-done@debbugs.gnu.org Received: via spool by 34150-done@debbugs.gnu.org id=D34150.154809472016539 (code D ref 34150); Mon, 21 Jan 2019 18:19:02 +0000 Received: (at 34150-done) by debbugs.gnu.org; 21 Jan 2019 18:18:40 +0000 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 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 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== 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 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 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 MIME-Version: 1.0 Message-ID: <8c88ff94-e322-4754-b74a-c792512ec277@default> Date: Mon, 21 Jan 2019 10:18:23 -0800 (PST) From: Drew Adams References: <8c207ca2-39ae-4ec1-acbd-358165964319@default> <83o98a9e2l.fsf@gnu.org> 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)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > 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. From unknown Sun Jun 22 17:14:52 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34150: 26.1; Document filtering with `isearch-filter-predicate' in Elisp manual Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Jan 2019 18:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34150 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Drew Adams Cc: 34150@debbugs.gnu.org Received: via spool by 34150-submit@debbugs.gnu.org id=B34150.154809527517369 (code B ref 34150); Mon, 21 Jan 2019 18:28:02 +0000 Received: (at 34150) by debbugs.gnu.org; 21 Jan 2019 18:27:55 +0000 Received: from localhost ([127.0.0.1]:40426 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gleIc-0004W5-KG for submit@debbugs.gnu.org; Mon, 21 Jan 2019 13:27:54 -0500 Received: from eggs.gnu.org ([209.51.188.92]:47196) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gleIa-0004Vr-6k for 34150@debbugs.gnu.org; Mon, 21 Jan 2019 13:27:52 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:42342) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gleIT-0006JO-7B; Mon, 21 Jan 2019 13:27:45 -0500 Received: from [176.228.60.248] (port=1611 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gleIR-0007K7-JP; Mon, 21 Jan 2019 13:27:44 -0500 Date: Mon, 21 Jan 2019 20:27:29 +0200 Message-Id: <83h8e1amsu.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <8c88ff94-e322-4754-b74a-c792512ec277@default> (message from Drew Adams on Mon, 21 Jan 2019 10:18:23 -0800 (PST)) References: <8c207ca2-39ae-4ec1-acbd-358165964319@default> <83o98a9e2l.fsf@gnu.org> <8c88ff94-e322-4754-b74a-c792512ec277@default> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > Date: Mon, 21 Jan 2019 10:18:23 -0800 (PST) > From: Drew Adams > Cc: 34150-done@debbugs.gnu.org > > > 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. ??? Most searches don't need any filtering at all. > > I modified the doc string to mention Isearch and replace commands. > > Thanks. And non-command functions such as `re-search-forward'? Not primitives, no. This is a Lisp-only (application-level) feature. > > > 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. > > > > 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. This is not a user-level facility, so the user perspective is not relevant. From unknown Sun Jun 22 17:14:52 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34150: 26.1; Document filtering with `isearch-filter-predicate' in Elisp manual Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Jan 2019 18:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34150 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , Drew Adams Cc: 34150@debbugs.gnu.org Received: via spool by 34150-submit@debbugs.gnu.org id=B34150.154809605118567 (code B ref 34150); Mon, 21 Jan 2019 18:41:02 +0000 Received: (at 34150) by debbugs.gnu.org; 21 Jan 2019 18:40:51 +0000 Received: from localhost ([127.0.0.1]:40433 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gleV8-0004pP-UF for submit@debbugs.gnu.org; Mon, 21 Jan 2019 13:40:51 -0500 Received: from userp2120.oracle.com ([156.151.31.85]:45534) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gleV7-0004pB-Ba for 34150@debbugs.gnu.org; Mon, 21 Jan 2019 13:40:49 -0500 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id x0LIdvxs067466; Mon, 21 Jan 2019 18:40:43 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=j8peNFKkrcbE9iVwZcR5f65GvqF354Z1xOwWukTQD3s=; b=gzTa6UVlh6IZoaJ28p8zLRPO6BGFl2wG1GXDJX6nO6AzAnpvASnrmUvbshgLBP9mzQE+ vdJl81FSxZj3ZBkzc2gN6ZPPrT0U6hrnF9O/MFMLU49V6OvJ6/11pBJdY/EW0ccNZAjm uA2D6wSqEzoADtNBJykn1dDyF8KzIXbJDOAfyLogiNWM0CkbgMWvFm7J1/J8myXa3E32 5XAVGXbzA9nMsCWq+qa+2bJSZJU6mVtbMk5GKvv/ju8tBnFD2JC7Z4vL3Gx7d0EOSR2n kI0MDPCIIZWUhKKo1Zn4SRLSAYMxRsoKx1NhyoG/HTZfKJFtkumQe7dXrNI4fQz14DTp oQ== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2120.oracle.com with ESMTP id 2q3vhrfxqr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 21 Jan 2019 18:40:43 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id x0LIebLm011847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 21 Jan 2019 18:40:38 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x0LIeb31015774; Mon, 21 Jan 2019 18:40:37 GMT MIME-Version: 1.0 Message-ID: <208f2037-8fa0-4475-a9cf-b2417613af5c@default> Date: Mon, 21 Jan 2019 10:40:36 -0800 (PST) From: Drew Adams References: <<8c207ca2-39ae-4ec1-acbd-358165964319@default>> <<83o98a9e2l.fsf@gnu.org>> <<8c88ff94-e322-4754-b74a-c792512ec277@default>> <<83h8e1amsu.fsf@gnu.org>> In-Reply-To: <<83h8e1amsu.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)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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-1901210145 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > But it and its consequences are not necessarily > > obvious - especially to a user searching, as opposed > > to a programmer writing a filter predicate. >=20 > This is not a user-level facility, so the user perspective is not > relevant. The "user perspective" is always relevant for Emacs. We are all users. Searching is a user-level facility. If a search imposes/provides filtering, that certainly affects user-visible behavior. Users should understand that behavior. Anyone imposing such filtering on users should consider its effects on users, including the considerations raised by this bug report. That starts with making the behavior and consequences clear to filter implementors. From unknown Sun Jun 22 17:14:52 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34150: 26.1; Document filtering with `isearch-filter-predicate' in Elisp manual Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Jan 2019 19:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34150 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Drew Adams Cc: 34150@debbugs.gnu.org Received: via spool by 34150-submit@debbugs.gnu.org id=B34150.154809754721145 (code B ref 34150); Mon, 21 Jan 2019 19:06:02 +0000 Received: (at 34150) by debbugs.gnu.org; 21 Jan 2019 19:05:47 +0000 Received: from localhost ([127.0.0.1]:40465 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gletH-0005Uz-7b for submit@debbugs.gnu.org; Mon, 21 Jan 2019 14:05:47 -0500 Received: from eggs.gnu.org ([209.51.188.92]:56362) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gletF-0005Ul-7Z for 34150@debbugs.gnu.org; Mon, 21 Jan 2019 14:05:46 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:42852) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1glet5-000236-Uo; Mon, 21 Jan 2019 14:05:37 -0500 Received: from [176.228.60.248] (port=3956 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1glet3-000108-Rh; Mon, 21 Jan 2019 14:05:35 -0500 Date: Mon, 21 Jan 2019 21:05:19 +0200 Message-Id: <83ef95al1s.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <208f2037-8fa0-4475-a9cf-b2417613af5c@default> (message from Drew Adams on Mon, 21 Jan 2019 10:40:36 -0800 (PST)) References: <<8c207ca2-39ae-4ec1-acbd-358165964319@default>> <<83o98a9e2l.fsf@gnu.org>> <<8c88ff94-e322-4754-b74a-c792512ec277@default>> <<83h8e1amsu.fsf@gnu.org>> <208f2037-8fa0-4475-a9cf-b2417613af5c@default> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > Date: Mon, 21 Jan 2019 10:40:36 -0800 (PST) > From: Drew Adams > Cc: 34150@debbugs.gnu.org > > > > But it and its consequences are not necessarily > > > obvious - especially to a user searching, as opposed > > > to a programmer writing a filter predicate. > > > > This is not a user-level facility, so the user perspective is not > > relevant. > > The "user perspective" is always relevant for Emacs. > We are all users. > > Searching is a user-level facility. If a search > imposes/provides filtering, that certainly affects > user-visible behavior. Users should understand > that behavior. > > Anyone imposing such filtering on users should > consider its effects on users, including the > considerations raised by this bug report. That > starts with making the behavior and consequences > clear to filter implementors. All true, but the filtering itself is not on the user level: the _results_ of the filtering are. So the behavior on the user level should be described and understood by users in higher-level terms. For example, with the default filtering, the behavior should be described in terms of searching inside invisible text, not in terms of filtering out some of the hits; the latter is just the implementation, not the user-level behavior. Therefore, the details of how filtering of matches works, and how to write a filter, is not user-level information. If you re-read what you wrote above, you will see that your arguments are all consistent with what I said, they don;'t contradict that in any way. From unknown Sun Jun 22 17:14:52 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34150: 26.1; Document filtering with `isearch-filter-predicate' in Elisp manual Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Jan 2019 23:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34150 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , Drew Adams Cc: 34150@debbugs.gnu.org Received: via spool by 34150-submit@debbugs.gnu.org id=B34150.154811222419002 (code B ref 34150); Mon, 21 Jan 2019 23:11:01 +0000 Received: (at 34150) by debbugs.gnu.org; 21 Jan 2019 23:10:24 +0000 Received: from localhost ([127.0.0.1]:40647 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1glii0-0004wP-BU for submit@debbugs.gnu.org; Mon, 21 Jan 2019 18:10:24 -0500 Received: from userp2120.oracle.com ([156.151.31.85]:44894) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1glihy-0004wC-Pn for 34150@debbugs.gnu.org; Mon, 21 Jan 2019 18:10:23 -0500 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id x0LN9W1n043148; Mon, 21 Jan 2019 23:10:16 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=d/gHyAIL4Y7/Xlh/XCM7r2/FciLjbbNicHZvpchGk1Q=; b=QIZGF92MEe/zXap7kmelXOHQ3VO2ckn3WWjT2x+YwLwJhaQ75LxVyKh2kcEYN6v9JDzp htT7+DEyPxek9f9zArwIR4etg2qUoddzxT/dF5OJ+Y+pWMe/s2eA6pQNcOOTvdR5hSzF GvpFLTXqzvDwqdV2yxSs8wkSUBijSFqDIqBTQHHR91CuX0Arm7OatgPfUF7T14ithIlR 2Rd7l+aEmHqxVOED3QGvh0TWvzEU6F/miPrjQMSPZMYGySQviEofV8U3zxTK1kn7TFXg iOLeCRSvMjUjGe67+ACXr7poMeTkmbBY/uRRgjRvWB69u/tqLbeNQ5LTIQ1ImF1Xjww0 tw== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2120.oracle.com with ESMTP id 2q3vhrghyk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 21 Jan 2019 23:10:16 +0000 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 x0LNABj0012820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 21 Jan 2019 23:10:11 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x0LNAAqI007187; Mon, 21 Jan 2019 23:10:10 GMT MIME-Version: 1.0 Message-ID: <41cc72fc-ee87-4164-b7f8-982435ccb453@default> Date: Mon, 21 Jan 2019 15:10:09 -0800 (PST) From: Drew Adams References: <<<8c207ca2-39ae-4ec1-acbd-358165964319@default>>> <<<83o98a9e2l.fsf@gnu.org>>> <<<8c88ff94-e322-4754-b74a-c792512ec277@default>>> <<<83h8e1amsu.fsf@gnu.org>>> <<208f2037-8fa0-4475-a9cf-b2417613af5c@default>> <<83ef95al1s.fsf@gnu.org>> In-Reply-To: <<83ef95al1s.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)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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-1901210181 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > > This is not a user-level facility, so the user perspective is not > > > relevant. > > > > The "user perspective" is always relevant for Emacs. > > We are all users. > > > > Searching is a user-level facility. If a search > > imposes/provides filtering, that certainly affects > > user-visible behavior. Users should understand > > that behavior. > > > > Anyone imposing such filtering on users should > > consider its effects on users, including the > > considerations raised by this bug report. That > > starts with making the behavior and consequences > > clear to filter implementors. >=20 > All true, but the filtering itself is not on the user level: the > _results_ of the filtering are. So the behavior on the user level > should be described and understood by users in higher-level terms. Correct. It should be. But those who implement filter predicates also need to be aware of the behavior, and to think in user terms, in order to think of documenting it for their users. I know, speaking as one such implementor. When the resulting filtering behavior does not have an obvious explanation without understanding something about filtering, an explanation for users is called for. > For example, with the default filtering, the behavior should be > described in terms of searching inside invisible text, not in terms of > filtering out some of the hits; the latter is just the implementation, > not the user-level behavior. Uh, no, aside from Isearch being able to "open" hidden text containing matches - which is something else again, use of such filtering by Isearch is not about searching inside INvisible text. It's about filtering out some of what would otherwise be considered search hits. Aside from the exceptional behavior of being able to "open" invisible text, search with filtering is about search visible, not invisible, text. Not to mention that users can, themselves, add filters to exclude searchable text. (With my Isearch+ code they can even do that on the fly, interactively.) Thinking in terms of filtering, excluding possible matches is entirely appropriate at the user level. It's akin to narrowing a set of completion candidates by progressively imposing additional match constraints. And even for completion there are two possibilities of filtering candidates: before matching user input or afterward. There are specific advantages to each. And yes, when one or the other is employed (or both) it can be important for users to know this, as it can affect not only what they see but how they choose to interact with the completion UI. The grain of truth in what you say is that in some cases users need not be aware of _some_ filtering that goes on. And even in those cases the possibility of their ignorance can depend on the kind of matching employed. See my example of regexp matching within a rectangle - no such problem for simple string matching. For simple, non-regexp searching users generally need not think in terms of (1) searching the whole buffer for matches and then (2) excluding matches that extend beyond the visible text. In that case a user-level description wouldn't need to mention filtering at all. Not so for the regexp-search case, however. Users need some description/explanation to provide them a conceptual model that explains the behavior they'll run into.=20 > Therefore, the details of how filtering of matches works, and how to > write a filter, is not user-level information. Certainly user-visible behavior should be described to users in user terms, not implementation terms. The implementation is irrelevant to them (unless they dig into Lisp during interaction). But a user description here must cover what I said, one way or another. They need to know why their regexp of .* does not find a match in the visible text, when they can see a match for it. Their conceptual model of what's happening, what's going on, needs to make this clear to them. It need _not_ be in terms that mirror the implementation. But it needs to describe/explain the behavior they see, one way or another. > If you re-read what > you wrote above, you will see that your arguments are all consistent > with what I said, they don;'t contradict that in any way. Dunno what expected contradictions you want me to look for. I would like to see doc that makes users aware of the behavior they run into. Today that's not the case. And a separation of programmer-level from user-level doc does not preclude making programmers themselves aware of what behavior users need to expect or know about. If they don't themselves understand the behavior then they can't manage it well or explain it to their users.