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 09:43:24 -0700 Message-ID: <6538462ADC534FDDBCCFC07FDCAAEF0C@us.oracle.com> References: <502B2845.9070200@yandex.ru><878vdgiv2d.fsf@gnu.org> <61874483AF75410DB400C72A9306D065@us.oracle.com> <502BB2C3.3060401@lanl.gov> 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 1345049030 24187 80.91.229.3 (15 Aug 2012 16:43:50 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 15 Aug 2012 16:43:50 +0000 (UTC) Cc: 'Bastien' , emacs-devel@gnu.org, cyd@gnu.org, 'Dmitry Gutov' , 'Dani Moncayo' To: "'Davis Herring'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 15 18:43:47 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 1T1ggz-0005dZ-6P for ged-emacs-devel@m.gmane.org; Wed, 15 Aug 2012 18:43:37 +0200 Original-Received: from localhost ([::1]:57905 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T1ggy-0005GG-8t for ged-emacs-devel@m.gmane.org; Wed, 15 Aug 2012 12:43:36 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:33325) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T1ggv-0005Fd-25 for emacs-devel@gnu.org; Wed, 15 Aug 2012 12:43:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T1ggt-0004Bo-Qq for emacs-devel@gnu.org; Wed, 15 Aug 2012 12:43:32 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]:31077) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T1ggr-0004BU-Lz; Wed, 15 Aug 2012 12:43:29 -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 q7FGhQE8017818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Aug 2012 16:43:27 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7FGhQ7f015640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Aug 2012 16:43:26 GMT Original-Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7FGhP4b016459; Wed, 15 Aug 2012 11:43:25 -0500 Original-Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 15 Aug 2012 09:43:25 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <502BB2C3.3060401@lanl.gov> Thread-Index: Ac168q5iWRsaQyOvS1m3LrdS9se2LAABTmrQ 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:152563 Archived-At: > > 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. > > Unless you filled a paragraph (perhaps via auto-fill-mode) and don't > remember doing so. ? Perhaps you mean filling with justification, so there can be stretches of multiple SPC chars? Or perhaps you are referring to `SPC SPC' after a period? Sorry, I don't see the problem you are hinting at. The behavior of SPC meaning to search for a single SPC char is pretty common in other editors (from TextPad to MS Word). And it has always been the default behavior for simple search in Emacs as well. How is it surprising? > If you're searching just for a space, the only differences > will be... We know what the differences are. > Why would you even care? Sure, if you're searching for > "a b" you'll find "a b", You answered your own question. > but when would you search for that, caring about missing > the latter, and not be using a regexp (as to find sentences > with only one space separating them)? You would search for that anytime you would search for it. ;-) Try searching your own message for `a b', for instance - that's `a', `SPC', `b'. Honestly, it is silly to suppose that users never or rarely want to search for a set number of SPC chars, including for just one SPC. Especially programmers. > Is "let's add an isearch toggle key" what you meant by "We've been > through this before"? No. I have a vague recollection that we have discussed before whether Isearch should search for only a single SPC when you type a SPC. I do not have a reference for you, however. > > * Treat both simple and regexp search the same way. > > In regexp search, you can choose between \s-+ and SPC -- that's why so > many have said just now that this magic is appropriate for C-s and not > C-M-s. Yes, I realize that. And yet we still have SPC being magic for regexp search, don't we? Even though it is simple enough to use \s-+, and it always has been. If people have in the past thought that SPC being magic in regexp search was handy (and yes, it can be easier to hit `SPC' than to type `\s-+', especially for multiple such in a long regexp), then their arguments still apply. And yes, "so many" clearly have thought that in the past, including Richard. The magic-space behavior for regexp search is at least as old as Emacs 20. I recognize that SPC acting "magically" can be useful whatever the search mode. Apparently you do not. * I do not see magic-space SPC as something that is useful ONLY for regexp search (the current and traditional approach). And I do not see it as useful ONLY for simple search (which you seem to be arguing). * I do not see literal-space SPC as something that is useful ONLY for regexp search (which you seem to be arguing). And I do not see it as useful ONLY for simple search (the current and traditional approach). Each SPC-search mode can be useful for both simple and regexp search, IMO. > > * 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'.) > > How is M-SPC any easier than C-q? No one said it was. But you are comparing apples and orangutans. C-q does not toggle the search mode wrt SPC; it simply gives a single SPC a literal life raft, to float in an otherwise magic-space sea. > (This is an argument for having the default be "on" for this magic; It's not much of an argument, AFAICT. I don't care much whether the _default_ default is on or off. If users can set the default SPC-search mode themselves, and if they have a simple way to toggle the mode, then a discussion about what the _default_ default behavior should be amounts to much ado about nothing. > otherwise you need a way to summon it for one use and C-q > doesn't fit there.) Not sure what you mean by "one use". Do you mean one search or one occurrence in a search string that also has other occurrences of SPC? If the former, then the answer is to toggle (and then toggle again when that one-off search is over). A quick toggle is perfect for a one-off search in the other mode. If the latter, then I guess you are saying that if magic-space search is off (why talk about the _default_ here?) then in simple search it is hard to search for _both_ a contiguous stretch of whitespace and a single SPC (or a given number N of SPC chars) in the same search string. If that's what you're saying, it is a red herring, Mr Herring. That same situation exists both today and with the proposal from Yidong. That is a difficulty for simple search whether magic is off or on: One cannot easily match both a stretch of whitespace and a single SPC (as opposed to a stretch) in the same search string. It is inherent to simple search - that use case cries out for regexp search instead. As such, this has nothing to do with what the default behavior should be. But as I say, I really do not care much what the default behavior is, as long as users can set their own default behavior and toggle the behavior on the fly. > As always, adding keys to isearch reduces the set you can use on exit > (M-SPC is useful here). Blah. > > * Users can set the variable value in their init files, if > > they want to change the default (i.e., initial) behavior. > > Er, yes? Yes? Dunno what is unclear here. The point is that you and I can each start out with the behavior we want. Today, the _code_ decides in a hard-coded way that regexp search uses magic-space and simple search does not. Yidong proposes the opposite - but still hard-coding. And I guess you are agreeing with that proposal. I'm saying let the user decide. Both what the initial behavior is and on the fly.