From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: Interpretation of a space in regexp isearch? Date: Sat, 01 Sep 2012 11:15:10 +0800 Message-ID: <87ehmm77sx.fsf@gnu.org> References: <502B2845.9070200@yandex.ru> <878vdgiv2d.fsf@gnu.org> <87r4qu8ffq.fsf@gnu.org> <87haro6v5y.fsf@gnu.org> <87k3wjto4o.fsf@mail.jurta.org> <87k3wihbl1.fsf@mail.jurta.org> <878vcw4wsh.fsf@gnu.org> <87ligwg4ra.fsf@gnu.org> <87ehmnew8r.fsf@mail.jurta.org> <87k3wfipq0.fsf@gnu.org> <878vcvgzjr.fsf@mail.jurta.org> <8739336rgn.fsf@gnu.org> <87txvi8qfd.fsf@mail.jurta.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1346469322 27524 80.91.229.3 (1 Sep 2012 03:15:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 1 Sep 2012 03:15:22 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 01 05:15:24 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 1T7eB9-0007lF-22 for ged-emacs-devel@m.gmane.org; Sat, 01 Sep 2012 05:15:23 +0200 Original-Received: from localhost ([::1]:33378 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T7eB6-0005E4-Cd for ged-emacs-devel@m.gmane.org; Fri, 31 Aug 2012 23:15:20 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52518) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T7eB3-0005Dt-Sc for emacs-devel@gnu.org; Fri, 31 Aug 2012 23:15:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T7eB2-0003Sj-K5 for emacs-devel@gnu.org; Fri, 31 Aug 2012 23:15:17 -0400 Original-Received: from mail-pz0-f41.google.com ([209.85.210.41]:33056) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T7eB2-0003RT-Da for emacs-devel@gnu.org; Fri, 31 Aug 2012 23:15:16 -0400 Original-Received: by dadi14 with SMTP id i14so2424688dad.0 for ; Fri, 31 Aug 2012 20:15:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=z7Ta9a4VmvdF3VUF7fFmTwd1u7em1AVqPnVeoDpVwqU=; b=HVAYwNWtKYFawgqNoG5De65HCSx7F14mAUMTmUrOZFTm6P5kcTqeUXmToe+7IHVCSP I09HidMcZ8YBN/xnyQBMxhcikkxt//BSo7hVVppyRnzshUKlK1KTBPYRBu8obpJvINUd n9Z6LyywAQd44PDnlMUhy0Uv/XGd2ES29D+PUvZhswsBEsQQKbN3BelM4EI4lu32YKLU 8gvvVdCZjVJgC9Uif7iJ6ZZcyb44oaPGGbg/Xsklr3zVsonACRRc5Se93DYxqujz1uhk xJV6G7dyHC8+Dqhe8le1Rn1WcpuTiw8xYrChSp6wJsFCXSNqBHDJSl+46hqcS6EBCnHQ 5a7Q== Original-Received: by 10.68.203.67 with SMTP id ko3mr21428252pbc.126.1346469315682; Fri, 31 Aug 2012 20:15:15 -0700 (PDT) Original-Received: from ulysses (cm162.gamma80.maxonline.com.sg. [202.156.80.162]) by mx.google.com with ESMTPS id pq7sm4726449pbb.25.2012.08.31.20.15.12 (version=SSLv3 cipher=OTHER); Fri, 31 Aug 2012 20:15:14 -0700 (PDT) In-Reply-To: <87txvi8qfd.fsf@mail.jurta.org> (Juri Linkov's message of "Sat, 01 Sep 2012 03:47:34 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.210.41 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:152925 Archived-At: Juri Linkov writes: > It doesn't ignore empty whitespace differences because > `search-whitespace-regexp' matches non-empty strings as a 1+ sequence > of whitespace with "\\s-+". Of course, changing it to "\\s-*" would > be annoying. Right, but the phrase "ignore whitespace" seems to indicate completely ignoring whitespace differences *in the search string*, including empty whitespace differences. So it is a poor name. > The reason why I think that related function and variable names > should contain the word `whitespace' is because it will connect it > with the already existing `search-whitespace-regexp'. I see your point. The naming system for `search-spaces-regexp' and `search-whitespace-regexp' is badly muddled, but I guess we have to live with it. How about -lazy-whitespace or -lax-whitespace? Then the command would be isearch-toggle-lazy-whitespace or isearch-toggle-lax-whitespace. > One message for `isearch-toggle-whitespace' was taken from the defcustom > definition of `search-whitespace-regexp' to display the same meaning as > "treat spaces literally". Instead of "treat spaces literally", I think "match spaces literally" would be more accurate. The opposite message could be "match spaces loosely", which is about the best we can do in a short message, I think. > So the question was rather do we need to support lax whitespace in > regexp mode at all? I don't think we should remove the feature outright, so there ought to be some way to enable it for regexp mode. Adding some complication to the code for this purpose is fine. That is to say, even if we change things so that C-M-s does not do lax space matching by default, it should be easy to get the feature back (by customizing a variable), just in case some user somewhere depends on the feature.