From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Interpretation of a space in regexp isearch? Date: Wed, 15 Aug 2012 06:59:21 -0700 Message-ID: <61874483AF75410DB400C72A9306D065@us.oracle.com> References: <502B2845.9070200@yandex.ru><878vdgiv2d.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1345039190 2273 80.91.229.3 (15 Aug 2012 13:59:50 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 15 Aug 2012 13:59:50 +0000 (UTC) Cc: cyd@gnu.org, 'Dmitry Gutov' , emacs-devel@gnu.org To: "'Dani Moncayo'" , "'Bastien'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 15 15:59:48 2012 Return-path: Envelope-to: ged-emacs-devel@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 1T1e8K-0001LS-Rq for ged-emacs-devel@m.gmane.org; Wed, 15 Aug 2012 15:59:41 +0200 Original-Received: from localhost ([::1]:46549 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T1e8J-0002oX-Vx for ged-emacs-devel@m.gmane.org; Wed, 15 Aug 2012 09:59:39 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:40303) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T1e8H-0002oM-Ja for emacs-devel@gnu.org; Wed, 15 Aug 2012 09:59:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T1e8F-0000ua-HK for emacs-devel@gnu.org; Wed, 15 Aug 2012 09:59:37 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]:34038) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T1e8D-0000tt-LR; Wed, 15 Aug 2012 09:59:33 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7FDxUlL028742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Aug 2012 13:59:31 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7FDxUCH016050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Aug 2012 13:59:30 GMT Original-Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7FDxUSX016733; Wed, 15 Aug 2012 08:59:30 -0500 Original-Received: from dradamslap1 (/10.159.221.239) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 15 Aug 2012 06:59:29 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Ac16xgRtiLFEUjyrStql9O7hlbBLygAIgMYQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 141.146.126.227 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:152546 Archived-At: > >>> FWIW, I've long been of the opinion that this feature is > >>> exactly backward. The `search-whitespace-regexp' whitespace > >>> matching feature should apply to ordinary incremental search, > >>> and it should *not* apply to regexp incremental search. > >> > >> I think that would make more sense, too. > > My opinion too. > +1 > > IMO, that feature is what the user usually wants in an ordinary search > (regardless it's incremental or not; even if that search is part of a > ordinary replace command). > > On the other and, in a rexexp search (or regexp search&replace) I > think that the common case is the opposite: the user normally doesn't > want that feature. > > So, what about making that feature optional for these two scenarios? > ("on" by default in the regexp case and "off" by default in the normal > case). +0.2 We've been through this before, I think, but... By default, "magic-space" searching should be OFF for both simple and regexp search. Each SPC you type should search for a single SPC, by default. Simple. No surprise. Others have given reasons for the regexp case (+1). For the simple-search case: I do not think it is appropriate for users, especially newbies, to have to figure out and use `C-q SPC' (WTF?) to search for a single SPC char. I do agree, however, that magic-space searching can be very useful, and it should be easily available, via a toggle key, for both simple and regexp searching. The best approach is to *let users decide*: * Treat both simple and regexp search the same way. * Have a Boolean variable that controls the behavior: literal-SPC or magic-space searching. * Have a toggle key that flips the Boolean value. The new value stays in effect (including in future searches for the same session) until flipped again. (Some candidates for the key: `M-SPC', `M-s SPC'.) * The variable's default value provides literal SPC search as the default (i.e., initial) behavior - for all searches: simple & regexp. * Users can set the variable value in their init files, if they want to change the default (i.e., initial) behavior. (Personally, I would prefer that the variable be a defcustom, but I'm a heretic.) [Even without this proposal, the doc for Isearch (e.g. C-s C-h m) should mention the behavior of SPC in a regexp search - it is currently silent about this. With this proposal, it should mention the two SPC behaviors and the toggle key.]