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: Fri, 31 Aug 2012 22:55:52 +0800 Message-ID: <8739336rgn.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1346425040 13079 80.91.229.3 (31 Aug 2012 14:57:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 31 Aug 2012 14:57:20 +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 Fri Aug 31 16:57:20 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 1T7Sem-0005Yg-Rg for ged-emacs-devel@m.gmane.org; Fri, 31 Aug 2012 16:57:12 +0200 Original-Received: from localhost ([::1]:46243 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T7Sek-0002e2-Dg for ged-emacs-devel@m.gmane.org; Fri, 31 Aug 2012 10:57:10 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:35316) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T7Seh-0002db-EZ for emacs-devel@gnu.org; Fri, 31 Aug 2012 10:57:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T7Seg-0004wn-4e for emacs-devel@gnu.org; Fri, 31 Aug 2012 10:57:07 -0400 Original-Received: from mail-pz0-f41.google.com ([209.85.210.41]:37850) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T7Sef-0004v3-UW for emacs-devel@gnu.org; Fri, 31 Aug 2012 10:57:06 -0400 Original-Received: by mail-pz0-f41.google.com with SMTP id i14so2085905dad.0 for ; Fri, 31 Aug 2012 07:57:05 -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=Eu9HSM18wR7yB7H+6sWHu3hvN+M26n/J2KEGtk5yO7o=; b=iGFZWnkfGcjNYc4mLq3SffYw7ZLawnSxgDY3zUUfv1BvGZe8sUgb+/FYqEg0OL59IQ a/2zbRssaCCOOi/llpIgkwecS7iBAaKTRPdYSdj4mLEaBB6AxhN7WvEQTxCyoLKn2FBC l7FgFpp8fOLAz2Q871zrVSHvy4EUwkmKvv0vJcIkNQ+YPUPNEzTeF2WAjz0ylG+3xh1c S0vR2n7rPuDZ3EXmyx3pgH0Gi3F3TpHr5hluNZvjZ9DcH4Lz+ooejO/ManW8oswlIDFh kmjd//NRxtbmPWJgqwjwGG2TQoSpTK5qPybGlKhS/cdnR5u40nptww/+wge6VlC9MZWr v7PA== Original-Received: by 10.68.217.202 with SMTP id pa10mr18121895pbc.15.1346425024949; Fri, 31 Aug 2012 07:57:04 -0700 (PDT) Original-Received: from ulysses (cm162.gamma80.maxonline.com.sg. [202.156.80.162]) by mx.google.com with ESMTPS id sr4sm3591300pbc.24.2012.08.31.07.56.16 (version=SSLv3 cipher=OTHER); Fri, 31 Aug 2012 07:57:02 -0700 (PDT) In-Reply-To: <878vcvgzjr.fsf@mail.jurta.org> (Juri Linkov's message of "Fri, 31 Aug 2012 12:31:04 +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:152913 Archived-At: Juri Linkov writes: > Or do you think `-ignore-whitespace' implies a more general > functionality? > it would be also useful to completely ignore all whitespace > differences between the search string and the buffer text with the > following implementation: No, ignoring whitespace differences entirely is not desireable. If the user searches for the word "tome" and isearch hits on "to me", that would be annoying. That's why I suggested the suffix -lax-space-match. Or, if that is too wordy, maybe -lax will do (there's already word-search-*-lax but I think that's OK since this feature doesn't overlap with word search). Or maybe -lazy-spaces. Or feel free to suggest something better. The message for isearch-toggle-whitespace should not speak of "ignoring whitespace", for the same reason. > The prefix `isearch-' is not quite right because these functions > can be used in other packages like replace.el being bound to > `replace-search-function'. `search-' seems more right. Using the search- prefix for the functions is OK. Apart from the above terminology issues, the rest of the patch also looks OK. > When users bind `isearch-forward-regexp' to C-s and use regexp search > as simple search, they will miss this feature. So when leaving it, a > separate variable is needed to disable whitespace mode in regexp mode, > but to enable it in non-regexp simple mode by default. This requires > a new variable `isearch-regexp-ignore-whitespace' but it complicates > the functionality, so maybe it should be removed from the next version > of the patch? I think the simplest, most backward compatible solution is simply to allow search-whitespace-regexp to take a cons cell value :-P Sure, a cons cell is not extensible, but is there any forseeable way in which we'd want to extend this beyond simply distinguishing ordinary and regexp isearch? The feature does not overlap with word search, so that seems pretty irrelevant.