From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#22494: still can't search for two spaces Date: Wed, 3 Feb 2016 06:57:44 -0800 (PST) Message-ID: <450ada88-ae30-4cde-8db0-cc8e625eebf9@default> References: <87h9hvshi3.fsf@jidanni.org>> > <54a07b7d-1fbd-4ed1-a8a0-e22eb5787c97@default>> <871t8yit11.fsf@mbork.pl>> <77b5b6df-4889-4142-a04d-526dd94c3a48@default>> > <6281db1e-d974-4cdc-b111-3e9097ae89db@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1454511503 1572 80.91.229.3 (3 Feb 2016 14:58:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Feb 2016 14:58:23 +0000 (UTC) Cc: 22494@debbugs.gnu.org, mbork@mbork.pl, rms@gnu.org, jidanni@jidanni.org To: John Wiegley Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Feb 03 15:58:10 2016 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 1aQysi-0006Vd-FC for geb-bug-gnu-emacs@m.gmane.org; Wed, 03 Feb 2016 15:58:08 +0100 Original-Received: from localhost ([::1]:35464 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQysh-0006Xc-Vv for geb-bug-gnu-emacs@m.gmane.org; Wed, 03 Feb 2016 09:58:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45987) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQysd-0006XQ-Q9 for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2016 09:58:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aQysc-0005es-LH for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2016 09:58:03 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49631) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQysc-0005eo-Hl for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2016 09:58:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aQysc-0001XX-8g for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2016 09:58: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: Wed, 03 Feb 2016 14:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22494 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug Original-Received: via spool by 22494-submit@debbugs.gnu.org id=B22494.14545114755904 (code B ref 22494); Wed, 03 Feb 2016 14:58:02 +0000 Original-Received: (at 22494) by debbugs.gnu.org; 3 Feb 2016 14:57:55 +0000 Original-Received: from localhost ([127.0.0.1]:58220 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aQysV-0001XA-JZ for submit@debbugs.gnu.org; Wed, 03 Feb 2016 09:57:55 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:45346) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aQysT-0001Wx-7c for 22494@debbugs.gnu.org; Wed, 03 Feb 2016 09:57:53 -0500 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u13EvkQB005039 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Feb 2016 14:57:47 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u13Evkjr020998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 Feb 2016 14:57:46 GMT Original-Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u13Evj8c032309; Wed, 3 Feb 2016 14:57:45 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] 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: 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:112338 Archived-At: > > Heeding what is in the search string means nothing - or anything. >=20 > I don't know why you're saying this Drew. By itself, it could mean anything. What does it mean to "heed" the current search pattern? Nothing implies that a single whitespace char in a row should mean that "heed" means switch to lax whitespace matching. The whole question about what kind of matching to do (lax, literal, regexp,...) is about the meaning of "heeding" the search pattern in a given context. > If the user types something into the search string, and exactly that > something is present in the buffer, Emacs should locate it before any > "lax" variant. Really? Always? I wouldn't have a problem with that (except if you mean for it to apply also to regexp search). But those who are fans of lax whitespace search might not like it. Today, not only is lax whitespace matching a possibility, but it is the default for C-s. What you suggest would mean that even=20 with lax w-s matching, search should first look for an exact match, before finding a lax match (i.e., even if that lax match came before the literal match).=20 > This means that type "nD" where nD exists, should find nD. Typing > " " where two spaces exist, should find the two spaces. I have no problem with that, and have said so multiple times now. I was the first to +1 the motion that multiple, contiguous whitespace chars should automatically turn off lax-ws matching. > Whether or not lax whitespace matching should be the default is an entire= ly > separate matter. I rather like the lax matching, so long as my use of two > spaces in a search string does not mean that I can't find two spaces. Yes, the default behavior is a different matter from whether the matching mode should switch automatically depending on the search string. I think perhaps you misread what I've written. I simply pointed out that, while I agree with the proposal to automatically turn off lax w-s if you type multiple w-s chars, there are some possible questions for what to do in these cases: a. You delete the multiple w-s chars, so there is now only one in a row. Should we then turn lax w-s matching back on? I only raised the question - I didn't propose an answer. b. Instead of _typing_ multiple, contiguous w-s chars (which some of us have agreed should turn off lax w-s), you _paste_ text that includes multiple, contiguous w-s chars. Should we turn off lax w-s in that case too? Again, I only raised the question - I didn't propose an answer. In some cases where you paste such text, you might be well aware that there are multiple such chars in a row, and you might purposefully want to search for them literally. This can be the case if you copy and yank code, for example. And it is more likely to be true if you copy+paste text from an Emacs buffer than non-code text from outside Emacs. In other cases, you might not realize that there are multiple such chars in a row, and you might not really care to search literally. This can happen if you paste text copied from outside Emacs, for instance. In sum: 1. I agree (!) with the proposal to automatically turn OFF lax w-s search if you type multiple, contiguous w-s chars. 2. I proposed that when that happens we clearly indicate the change to users. 3. I raised a question about whether lax w-s matching should be automatically turned back ON if you change the search string (e.g. delete some chars) so that it no longer has multiple, contiguous w-s chars. 4. I raised a question about whether lax w-s matching should be automatically turned OFF if you _paste_ (not type) text that contains multiple, contiguous w-s chars. TL;DR: DWIM is hard. It never does what everyone means, in every context. It's about compromises & judgment. And it requires good feedback about what it's doing for "free". DWIM behind a user's back always bites someone, in the end. ;-) Hope this clears things up a bit.