From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#22043: 25.0.50; search-forward and char folding Date: Mon, 30 Nov 2015 19:32:36 +0200 Message-ID: <83egf7mlzf.fsf@gnu.org> References: <15605.1448748702@allegro.localdomain> <17193.1448823812@allegro.localdomain> <837fl0obox.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1448904868 12711 80.91.229.3 (30 Nov 2015 17:34:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 30 Nov 2015 17:34:28 +0000 (UTC) Cc: 22043@debbugs.gnu.org, m.kupfer@acm.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Nov 30 18:34:16 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1a3SL4-0005kZ-Lw for geb-bug-gnu-emacs@m.gmane.org; Mon, 30 Nov 2015 18:34:10 +0100 Original-Received: from localhost ([::1]:42443 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3SL3-0006ih-Tp for geb-bug-gnu-emacs@m.gmane.org; Mon, 30 Nov 2015 12:34:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32779) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3SKz-0006hk-Nu for bug-gnu-emacs@gnu.org; Mon, 30 Nov 2015 12:34:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a3SKw-00076z-GB for bug-gnu-emacs@gnu.org; Mon, 30 Nov 2015 12:34:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:43403) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3SKw-00076s-Bu for bug-gnu-emacs@gnu.org; Mon, 30 Nov 2015 12:34:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1a3SKv-0006e2-Vv for bug-gnu-emacs@gnu.org; Mon, 30 Nov 2015 12:34:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 30 Nov 2015 17:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22043 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22043-submit@debbugs.gnu.org id=B22043.144890478525429 (code B ref 22043); Mon, 30 Nov 2015 17:34:01 +0000 Original-Received: (at 22043) by debbugs.gnu.org; 30 Nov 2015 17:33:05 +0000 Original-Received: from localhost ([127.0.0.1]:33105 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a3SK0-0006c3-LX for submit@debbugs.gnu.org; Mon, 30 Nov 2015 12:33:05 -0500 Original-Received: from mtaout24.012.net.il ([80.179.55.180]:53379) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a3SJf-0006b2-Gz for 22043@debbugs.gnu.org; Mon, 30 Nov 2015 12:33:02 -0500 Original-Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NYN000001Q1E000@mtaout24.012.net.il> for 22043@debbugs.gnu.org; Mon, 30 Nov 2015 19:25:29 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NYN00NPV1QHN410@mtaout24.012.net.il>; Mon, 30 Nov 2015 19:25:29 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:109456 Archived-At: > Date: Sun, 29 Nov 2015 12:41:16 -0800 (PST) > From: Drew Adams > Cc: m.kupfer@acm.org, 22043@debbugs.gnu.org > > > > IOW, isn't this default behavior true for all incremental > > > search commands except regexp search, and only for those > > > commands (no non-incremental search commands)? > > > > No. Nonincremental vs incremental is not the issue. The issue is > > whether the search function that the command employs uses regexps or > > not. It is a limitation of how these features are implemented that > > they absolutely require regexp search. > > OK, but from a user point of view, is this not the case: > > 1. S?he invokes search using `C-M-s' or `C-s', which are > advertised as regexp and plain (non regexp) search. IOW, > regardless of what might go on under the covers (and a > lot already does, for lax whitespace searching), s?he > thinks of `C-s' as performing a non-regexp search. Perhaps so, but (a) I see that you've dropped the incremental vs nonincremental distinction, which agrees with what I say above; and (b) we cannot really say in the manual something like "commands invoked by `C-s' do character folding", because the reader might not yet know/remember enough for such a distinction to be useful for her. > 2. There is no character folding with the "regexp" commands > (`C-M-s'), because char folding substitutes its own regexp > for the user input, and char folding does not currently > parse regexp-pattern user input. That's implementation. From the user POV, typing "C-M-s M-s '" magically does support character folding, but it also switches the search to a non-regexp one! So is it a regexp search or isn't it? > Perhaps, to be more precise, the difference is search that > does or does not accept general regexp patterns as _input_. > Those that do have "regexp" (or "-re-"?) in their name; > those that do not do not have it. The former do not > support char folding; the latter do. Is that correct (and > complete)? I think neither, because of the subtle behind-the-scenes effect of the "M-s C" toggles (where C is a character like ' or _ or w). > I guess I was mistaken in thinking that non-incremental > search commands, such as `nonincremental-search-forward', > do not support char folding (regardless of whether they > include "-re" in their name). Which ones support it, and > under what circumstances? Each command should tell in its doc string whether it does or doesn't, and the manual should also document that where it describes the command itself. AFAICS, this is currently (as of today ;-) so. I don't think we can do any better. The real criterion is "where it's easy to provide given the limitations of the implementation we have", but that's not useful for user documentation. Anyway, if I return to the original issue, the section with the offending "Search commands in Emacs by default perform character folding" sentence has its main focus on explaining what is character folding and how to enable/disable it; it does not focus on the specific commands. So it uses some vague definitions of the default behavior, which is later described more accurately for each particular command. This is standard practice in user-level documentation, when describing complex issues: you first provide an overview that might not be 100% accurate, but should give the reader a clear and simple enough idea of the subject, leaving the more accurate details for later in-depth coverage. I don't see how we can do significantly better; all of the proposals till now make the description much more complicated and thus confusing, especially upon first reading. If people think that saying something more vague like Some search commands by default perform character folding (whether it does or doesn't is documented for each specific command) will do a better job, maybe we could use that. To me, this sounds worse, because it immediately raises the question: which commands do and which don't. That question will interfere with the reader's attention to the issue at hand, which isn't the particular commands, but the folding in general and how to toggle/disable it.