From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ken manheimer Newsgroups: gmane.emacs.help Subject: Re: emacs 22 - regular-expression isearch on spaces extremely lenient Date: Mon, 1 May 2006 18:04:40 +0000 (UTC) Message-ID: References: <2cd46e7f0604281356i582388e2kef07922b6b6a9a3a@mail.gmail.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1146507024 11698 80.91.229.2 (1 May 2006 18:10:24 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 1 May 2006 18:10:24 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon May 01 20:10:22 2006 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Facqj-0005zN-9g for geh-help-gnu-emacs@m.gmane.org; Mon, 01 May 2006 20:10:21 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Facqi-0000bl-Lz for geh-help-gnu-emacs@m.gmane.org; Mon, 01 May 2006 14:10:20 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FacqX-0000bW-HE for help-gnu-emacs@gnu.org; Mon, 01 May 2006 14:10:09 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FacqV-0000aw-2e for help-gnu-emacs@gnu.org; Mon, 01 May 2006 14:10:09 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FacqU-0000aX-Lr for help-gnu-emacs@gnu.org; Mon, 01 May 2006 14:10:06 -0400 Original-Received: from [80.91.229.2] (helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1FacuL-0005PJ-US for help-gnu-emacs@gnu.org; Mon, 01 May 2006 14:14:06 -0400 Original-Received: from root by ciao.gmane.org with local (Exim 4.43) id 1FacqP-0005vx-U1 for help-gnu-emacs@gnu.org; Mon, 01 May 2006 20:10:02 +0200 Original-Received: from c-68-54-251-36.hsd1.dc.comcast.net ([68.54.251.36]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 01 May 2006 20:10:01 +0200 Original-Received: from ken.manheimer by c-68-54-251-36.hsd1.dc.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 01 May 2006 20:10:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-To: help-gnu-emacs@gnu.org Original-Lines: 115 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: main.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 68.54.251.36 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.2) Gecko/20060420 Firefox/1.5.0.2) X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:34743 Archived-At: Drew Adams oracle.com> writes: > [Ken Manheimer wrote:] > > i recently started noticing that emacs 22 regular expression isearches > do not treat spaces exactly - any number of spaces in your search will > map to any number, same or different, of spaces in the target. > > can anyone tell me whether or not it's deliberate, and what the > rationale is? > > (setq search-whitespace-regexp nil) will turn this off. When this is nil, > each space you type matches literally, against one space. thanks! i did infer that from a bit of investigation (in isearch-search), and am kinda mortified by how unobvious it is. i agree very strongly with your analysis, and feel the feature is too elusive in too many ways - all the questions i was asking: behaviorally ("wait a minute, does it really do that, and if so, when?"), properness ("is it really supposed to do that?"), control/inhibition (how the hell do i turn it off?!") - that it's a Real Bad Idea. oh well. i agree that making the control obvious, and defaulting it to off, is a much better way to make the feature available. (i could even see having a transient message in the minibuffer whenever someone types in a space, saying how to make it a fuzzy space with Ctrl-Q.) > `search-whitespace-regexp' is, by default, "\\s-+", which searches for any > amount of whitespace when you type a space. This was introduced for regexp > search in Emacs 21, I believe. There is no such "magic-space" searching in > Emacs 20. Doc: > > If non-nil, regular expression to match a sequence of whitespace chars. > This applies to regular expression incremental search. > When you put a space or spaces in the incremental regexp, it stands for > this, unless it is inside of a regexp construct such as [...] or *, + or ?. > You might want to use something like "[ \t\r\n]+" instead. > In the Customization buffer, that is `[' followed by a space, > a tab, a carriage return (control-M), a newline, and `]+'. i didn't notice anything about it in the documentation for isearch, though now that i look at the section on regular expression search i see something about it. this is a pitfall of rich features - too much functionality to describe adequately without overwhelming. > The rationale was, I believe, that some users might want that: type space to > find any amount of whitespace, in particular, to find two words that are > separated by a newline. i would have suggested using "\ " or "^Q " (which both currently now have the opposite effect). > There was talk of using this "magic-space" searching also for plain > incremental search in Emacs 22, but I don't think that was done. good. > FWIW, I agree with Miles on this - this is a misfeature, if turned on by > default. It should be off by default, and you should be able to turn it on > via a simple toggle during incremental search (regexp or plain). who's miles? > Here is what I wrote 2005/02/06 to emacs-devel on this: > > > > sometimes the actual whitespace matters. > > Right: in *regexp* search. > while people generally expect regexp searches to be a bit > fuzzy, they might expect a non-regexp search to be exact. > Since the fuzzy whitespace matching often "looks" like normal > matching (because the majority of whitespace is in fact a > single space), it might take some time to see what's going on, > resulting in some subtle errors. This is particularly true if > one embeds a search inside a keyboard macro [which I often do]. > > Plain (incremental) search should be a literal search. Regexp > search should rigorously respect the regexp. People don't expect > either to be fuzzy. > > The question is "Under what circumstances should typing a space be > interpreted as wanting to search for any amount of whitespace?" > > This is unrelated to both plain search and regexp search. You > might or might not want this _input effect_ with either plain > or regexp search. > > This is akin to word search (as I think someone mentioned). > Ultimately, a word search or a space-means-whitespace search is > implemented with a regexp search - but the point in both cases > is to provide a user-friendly way to do it, instead of requiring > users to know about regexps. > > By default, neither `C-M-s' nor `C-s' should respect the > user-friendly space-input feature. Or, rather, the default > behavior of each should be determined by a user option - a la > case-fold-search. And, regardless of the value of this option, > you should be able to toggle space-means-whitespace > searching from both `C-M-s' and `C-s', via a key sequence. > > The question then becomes how to toggle this space-means-whitespace > searching? thanks much for the thorough answer - it's good to have the mystery settled, even if i don't agree with the situation. at least i now know various ways to work around it... (i guess it's too late to propose inverting the mode of the feature on emacs-devel? i'd just copy this posting over there, asking if it's worth reopening the discussion. i wouldn't want to do that, though, if the discussion ended on a conclusive pronouncement that even dismissed revisiting in the event of complaints...) ken manheimer http://myriadicity.net