From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Lundin Subject: Re: Boolean word/regexp search problem Date: Fri, 27 Nov 2009 14:54:56 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NE6uK-0002ZX-1C for emacs-orgmode@gnu.org; Fri, 27 Nov 2009 14:55:08 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NE6uD-0002TJ-MU for emacs-orgmode@gnu.org; Fri, 27 Nov 2009 14:55:05 -0500 Received: from [199.232.76.173] (port=47634 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NE6uD-0002Sv-1l for emacs-orgmode@gnu.org; Fri, 27 Nov 2009 14:55:01 -0500 Received: from out4.smtp.messagingengine.com ([66.111.4.28]:54771) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NE6uC-0001HP-LJ for emacs-orgmode@gnu.org; Fri, 27 Nov 2009 14:55:00 -0500 Received: from compute1.internal (compute1.internal [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id F2D7EC2C32 for ; Fri, 27 Nov 2009 14:54:59 -0500 (EST) Received: from macbook.local (h-68-165-57-53.chcgilgm.dynamic.covad.net [68.165.57.53]) by mail.messagingengine.com (Postfix) with ESMTPSA id 9014444A062 for ; Fri, 27 Nov 2009 14:54:58 -0500 (EST) In-Reply-To: (Matthew Lundin's message of "Fri, 27 Nov 2009 12:37:56 -0500") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Cc: Org Mode Hi Carsten, Matthew Lundin writes: > Matt Lundin writes: > >> The word/regexp agenda search to work with more than one word or regexp >> unless the first word or regexp is also preceded by a "+" or "-". I've investigated this further and beg your permission to offer a few comments/suggestions. First, I apologize for missing the change in behavior in the org-search-view introduced in Org 6.32. Reading the ChangeLog, I now see the following information: ,---- | Agenda Search view: Search for substrings | | The default in search view (C-c a s) is now that the search expression | is searched for as a substring, i.e. the different words must occur in | direct sequence, and it may be only part of a word. If you want to | look for a number of separate keywords with Boolean logic, all words | must be preceded by + or -. | | This was, more-or-less, requested by John Wiegley. `---- In particular, I see that "all words must be preceded by + or -" for a boolean search. I've also read the manual section 10.3.5 as well as the docstring for org-search-view and appreciate that this new behavior can be turned off with the variable org-agenda-search-view-search-words-only. A few comments: 1) I'm wondering whether the substring search should be the default. I search quite often for two or three words or regexps that I know are in an entry (regardless of order), while I rarely search for a specific phrase or sequence of words. Of course, others might disagree. 2) Many web and database search engines use the following convention: a space between words becomes an automatic AND, while quotation marks indicate searches for a phrase/substring (i.e., words in sequence). Having missed the description of the new behavior in the ChangeLog, I found the new default substring search a bit counter-intuitive. My vote would be for sloppy boolean searches by default, with quotation marks reserved for substring searches. But of course, this is not a huge priority for org-mode development, and I have no idea how difficult it would be to implement! 3) The new substring search changes the behavior of regexp searches. A simple regexp search with brackets (e.g, {Carst}) no longer produces any results unless the brackets are preceded by a +. This is true even if one is searching only for a single regexp. In other words, regexp brackets now *must* always be preceded by a plus or a minus. Is this the intended behavior? 4) Pressing "[" or "]" or "{" or "}" in the agenda buffer adds a "+" or "-" after the first term in the minibuffer. E.g., --8<---------------cut here---------------start------------->8--- [+-]Word/{Regexp} ...: Emacs + --8<---------------cut here---------------end--------------->8--- But if the user simply adds another term at the cursor (i.e., after the "+"), the search will fail, since "Emacs" now must also be preceded by a "+". Thanks for reading this long email. - Matt