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 15:10:09 -0800 (PST) Message-ID: <41cc72fc-ee87-4164-b7f8-982435ccb453@default> 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>> 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="61740"; mail-complaints-to="usenet@ciao.gmane.org" Cc: 34150@debbugs.gnu.org To: Eli Zaretskii , Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jan 22 00:15:12 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 1glimZ-000Ftw-Mv for geb-bug-gnu-emacs@m.gmane.org; Tue, 22 Jan 2019 00:15:07 +0100 Original-Received: from localhost ([127.0.0.1]:35739 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1glimX-0001O8-Ig for geb-bug-gnu-emacs@m.gmane.org; Mon, 21 Jan 2019 18:15:05 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:45218) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1glimM-0001Hu-P2 for bug-gnu-emacs@gnu.org; Mon, 21 Jan 2019 18:14:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gliic-00079X-10 for bug-gnu-emacs@gnu.org; Mon, 21 Jan 2019 18:11:05 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41366) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gliib-00079R-Td for bug-gnu-emacs@gnu.org; Mon, 21 Jan 2019 18:11:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gliib-0004xI-Nj for bug-gnu-emacs@gnu.org; Mon, 21 Jan 2019 18:11:01 -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 23:11:01 +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-submit@debbugs.gnu.org id=B34150.154811222419002 (code B ref 34150); Mon, 21 Jan 2019 23:11:01 +0000 Original-Received: (at 34150) by debbugs.gnu.org; 21 Jan 2019 23:10:24 +0000 Original-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 Original-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 Original-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== Original-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 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 x0LNABj0012820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 21 Jan 2019 23:10:11 GMT Original-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 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)] 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-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:154667 Archived-At: > > > 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.