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, 29 Aug 2012 09:01:33 -0700 Message-ID: <320E4B7F9BA44C52B835F3975D20EDC0@us.oracle.com> 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> <87r4qq9juw.fsf@mail.jurta.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1346256118 20802 80.91.229.3 (29 Aug 2012 16:01:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 Aug 2012 16:01:58 +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 Wed Aug 29 18:01:59 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 1T6kiJ-0001eP-JO for ged-emacs-devel@m.gmane.org; Wed, 29 Aug 2012 18:01:55 +0200 Original-Received: from localhost ([::1]:42721 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T6kiH-0006XF-6v for ged-emacs-devel@m.gmane.org; Wed, 29 Aug 2012 12:01:53 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:49288) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T6ki9-0006X8-OR for emacs-devel@gnu.org; Wed, 29 Aug 2012 12:01:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T6ki2-0006nu-Cn for emacs-devel@gnu.org; Wed, 29 Aug 2012 12:01:45 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]:50254) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T6ki2-0006nj-6H for emacs-devel@gnu.org; Wed, 29 Aug 2012 12:01:38 -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 q7TG1Zxr019215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 29 Aug 2012 16:01:35 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7TG1Ycd003445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2012 16:01:34 GMT Original-Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7TG1YAa002449; Wed, 29 Aug 2012 11:01:34 -0500 Original-Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 29 Aug 2012 09:01:34 -0700 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <87r4qq9juw.fsf@mail.jurta.org> Thread-Index: Ac2FwcohDVQ3QbtlQW2UNcPJn08BkgAOFz5Q 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:152893 Archived-At: > > But let's not sacrifice some char (e.g. nobreak-space), so that its > > use in a search string means something special, not > searching for itself. > > The space character is special to indicate whitespace. > We need another special character IMO, you are too liberal with the "we need"s. > to indicate literal space in non-regexp searches. I don't buy the assumption that we need a "special char" to indicate a literal space in a non-regexp search. Toggling this new mode on/off should suffice for most simple searches where you want to search for literal SPC chars. For the remainder, i.e., simple searches where both literal spaces and magic-whitespace are searched for in the same search string, I would say that users should take one of these approaches: 1. use regexp search instead (seriously) 2. use C-q (or perhaps C-u?) to escape the following character to be treated literally #2 might require some work by Emacs Dev. > Could you find a better character than nobreak-space? Sorry, I don't buy the claim that "we need another special character to indicate literal space in non-regexp searches." --- Look, we could be doing this kind of thing for other magic search strings also. Essentially the idea is to come up with a shortcut (for typing and visibility) for a regexp (or other complex searching pattern/mechanism) that is used often, for common matches. A second part of the idea is to hide the fact that such complex searching is involved - whether for simple or regexp searching. If a user knows that s?he is doing regexp search, then any shortcut "mode" that enables the user to, say, type only `(' instead of `\(', can be turned on/off with a toggle. Yes, sure, we need to define each mode state completely, e.g., how to indicate a literal `(' when `(' means what `\(' means in the opposite mode state. I proposed long ago, for instance, a toggle for a `.' in regexp search to match also newlines, i.e., any character. IOW, `.' in one mode state of the toggle, `.' would be equivalent to "\\(.\\|[\n]\\)" in the other (traditional) state. I still think that particular enhancement would be helpful. I've used it in Icicles for years, and it is very handy, IMO. I use text properties so the user (optionally, and by default) sees only `.' when s?he types `.', but in fact what is used is the regexp that matches also \n. Such a magic, multi-line dot is (optionally) highlighted in the minibuffer, so you can distinguish it. And you can hit a key to toggle the state. And you can hit another key to toggle whether the `.' is shown as `.' or as its underlying regexp. When such a multi-line dot is present in the minibuffer, editing treats it as a single char; e.g., it DTRT when you delete or transpose chars. How do I deal with the case of mixing multi-line and ordinary dots in the same minibuffer input (analog to a search string)? A prefix arg to `.' flips it from its usual behavior (whether multi-line or normal/literal) to the opposite. We _might_ want to do similarly for Isearch. Here is a bit more explanation. http://www.emacswiki.org/emacs/Icicles_-_Dot%2c_Dot%2c_Dot Consider that food for thought. I'm not actively suggesting that the same approach should be used for Isearch, or that it is "the answer". My point here is: 1. The motivation for the current magic whitespace discussion can be generalized to other magic chars or SOMETHING-ignoring modes. So the discussion should perhaps be more general also. 2. Sacrificing a "special char" (e.g. nobreak-space) for this kind of thing is the wrong approach, IMO. I would also add that whenever we do something like this that hides what's really going on from the user, as a convenience, there is the possibility of confusion and complication. So we had better enable users to alternatively SEE what is otherwise hidden. A toggle to show the ugly, underlying stuff as part of the search string is helpful to users. For one thing, it can help them understand why what they think they are searching for might not be what they are really searching for. It gives them a means to investigate and learn more.