From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: RFC: [PATCH] isearch enhancements: symbol mode; syntactic filtering Date: Thu, 07 Jul 2011 17:49:09 -0700 Message-ID: <4E165405.6010805@gmail.com> References: <4E15C0BA.10400@gmail.com> <87liw9mxrh.fsf@mail.jurta.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1310086184 9968 80.91.229.12 (8 Jul 2011 00:49:44 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 8 Jul 2011 00:49:44 +0000 (UTC) Cc: emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 08 02:49:40 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QezGE-0002iH-OY for ged-emacs-devel@m.gmane.org; Fri, 08 Jul 2011 02:49:39 +0200 Original-Received: from localhost ([::1]:45079 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QezGD-0008Kj-6u for ged-emacs-devel@m.gmane.org; Thu, 07 Jul 2011 20:49:37 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:34850) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QezFv-0008KB-Cg for emacs-devel@gnu.org; Thu, 07 Jul 2011 20:49:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QezFr-0002WB-JM for emacs-devel@gnu.org; Thu, 07 Jul 2011 20:49:18 -0400 Original-Received: from mail-pv0-f169.google.com ([74.125.83.169]:63056) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QezFp-0002Ry-Rx for emacs-devel@gnu.org; Thu, 07 Jul 2011 20:49:15 -0400 Original-Received: by pvc12 with SMTP id 12so1026163pvc.0 for ; Thu, 07 Jul 2011 17:49:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=98hoA3g/fKKyPlcEDxS7EohtaxaVDsrGJYmDMfYGAbY=; b=LVKwBgkkNZPX+HUC7uqcFDUlryCyIdD/z/B6qZf4NFiDuZheHaapP0H63yKhRoyZVn aRHhw/jTffEzJctWcX9d1cVniuWj1m28zjvvYXOF+cfWjZuAxMaRx6D///OV9Rs9+LO6 TfCLiqxtxqqvnaP5dBFE5bLGzbGpZe76ESzdo= Original-Received: by 10.68.12.65 with SMTP id w1mr2056998pbb.294.1310086151852; Thu, 07 Jul 2011 17:49:11 -0700 (PDT) Original-Received: from [0.0.0.0] (c-24-18-179-193.hsd1.wa.comcast.net [24.18.179.193]) by mx.google.com with ESMTPS id e13sm6418999wfd.13.2011.07.07.17.49.10 (version=SSLv3 cipher=OTHER); Thu, 07 Jul 2011 17:49:10 -0700 (PDT) User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 In-Reply-To: <87liw9mxrh.fsf@mail.jurta.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 74.125.83.169 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:141770 Archived-At: On 7/7/2011 5:20 PM, Juri Linkov wrote: >> - Syntactic filtering: control whether to match in comments, strings, and >> normal text. > > This is easier to implement using `isearch-filter-predicate' as shown in > http://thread.gmane.org/gmane.emacs.devel/34742 It may be easier to implement that way, but the results aren't as good. Integrating the filtering mode into isearch allows it to be saved along with all other isearch state. Also, my approach doesn't conflict with other uses of isearch-filter-predicate. I do like the idea of displaying isearch state information in the modeline instead of the minibuffer, however. > Unfortunately, I failed to find a good keybinding for this feature, > so it sunk into obscurity. The ones I proposed should be reasonably accessible, and they don't conflict with anything useful directly from isearch. >> - Symbol search: like word search, but looks only at symbol boundaries > > This is much needed. But I think it should have a keybinding separate > from word search. Currently, `M-s w' toggles word search, > so a new keybinding `M-s _' could toggle symbol search. Adding symbol search as a new kind of word search makes sense because the new search mode is conceptually similar to, and mutually exclusive with, classic word search; having accepted this idea, it naturally follows to allow users to cycle through normal, word, and symbol searches makes sense. I have no objection to providing a way to go directly to symbol search, however: being able to cycle backwards with a prefix argument to M-s w would be sufficient, I think. I like the idea of using M-_ to refer to something having to do with symbols; in my patch, I bind this key to a function that both sets symbol-search mode _and_ filters out matches in comments and strings; I call it identifier-mode. I find myself wanting exactly this behavior fairly frequently. We can certainly bikeshed a bit about the actual keybindings. >> - One ring: optionally share a search ring between normal and regular >> expression searches. The additional history storage described below allows >> this mode to work reliably. > > Maybe sharing a search ring between normal and regexp searches > would be better to implement in the same way as sharing > `from' and `to' histories is implemented in `query-replace'? > Like two variables `query-replace-from-history-variable' and > `query-replace-to-history-variable', isearch could provide > two variables `isearch-ring-variable' and `isearch-regexp-ring-variable'. We can do it that way too. I also considered using a variable alias, to point regexp-search-ring at search-ring, but your approach is cleaner. Speaking of search rings: would anyone object (after feature freeze, of course) to allowing history functions to use something other than equal (e.g., equal-including-properties) as the comparison function for duplicate detection? >> - Case sensitivity is now displayed alongside other isearch settings in the >> isearch prompt. Previously, the only indication we gave of case >> sensitivity was a fleeing message displayed briefly each time the user >> toggled the setting. > > This is a good change as well, but one possible problem is that > its message string "case-insensitive " (17 characters) is too long > for the isearch prompt. "(CI)"? "nocase"? "case"? My isearch strings tend not to be long enough to actually cause problems this way. >> - isearch no longer prints "pending". I don't see why this message would >> be useful. > > "pending" reminds the user that the actual search position doesn't > correspond to the search parameters displayed in the search prompt. > This happens after e.g. changing the search type to regexp or word. > Updating the search position might be more surprising for users. I don't feel that the user needs to be reminded of the situation; I think the user will intuitively understand what's happening when the point fails to move.