From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Lundin Subject: Re: How to do Properties search by define an agenda command Date: Sat, 13 Nov 2010 10:31:17 -0500 Message-ID: <87bp5tb5q2.fsf@fastmail.fm> References: <87mxphuj4d.wl%dmaus@ictsoc.de> <8762w3z4u9.fsf@fastmail.fm> <87oc9tkb4l.wl%dmaus@ictsoc.de> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from [140.186.70.92] (port=49809 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PHI4a-0007Mf-UB for emacs-orgmode@gnu.org; Sat, 13 Nov 2010 10:31:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PHI4W-0000W3-WE for emacs-orgmode@gnu.org; Sat, 13 Nov 2010 10:31:24 -0500 Received: from out3.smtp.messagingengine.com ([66.111.4.27]:38181) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PHI4W-0000VM-Tx for emacs-orgmode@gnu.org; Sat, 13 Nov 2010 10:31:20 -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 To: David Maus Cc: Chao LU , emacs-orgmode@gnu.org David Maus writes: > At Thu, 11 Nov 2010 20:51:58 -0500, > Matt Lundin wrote: >> > Looks like to use the intended functionality someone has to patch Org >> > mode's tag search to handle multivalue properties. AFAICT, the OP was not inquiring about a multivalue search, but rather simply asking how to match an entire property value string (i.e., the title of a book). The problems was caused not by unescaped spaces in property values, but rather by how the custom agenda search was constructed (e.g., incorrect property key, unescaped quote marks, etc.). >> I don't believe the space in property values is meant to indicate >> multiple values (i.e., in the same way that ":" separates tags). Here's >> an example from the manual: > > This is a misunderstanding: Yes, you can use space characters in > single value properties and use regexps to simulate multivalue > properties. > > But you can't use Org's multivalue properties (C-h f > org-entry-put-multivalued-property RET). Good to know. I wasn't aware of multivalued properties. I think my comment still stands: currently, for normal tags/property searches, single spaces are not intended to indicate multiple values. The function org-tags-view invokes only the single value property mechanism (i.e., org-cached-entry-get). AFAICT, multivalued properties were introduced to accommodate org-attach but they have not (yet) been used elsewhere in Org-mode. See the following commit: --8<---------------cut here---------------start------------->8--- commit d043e31182595983df3d191e80ca941ee171c400 Author: Carsten Dominik Date: Wed Oct 1 09:25:18 2008 +0200 Integrate John Wiegley's org-attach.el. --8<---------------cut here---------------end--------------->8--- > Looks like an inconsistency or a glitch: Org supports putting multiple > values in a property but has no reserved separator for multiple > values. So there is no way for a function recognize multivalue > properties -- what makes it hard to perform a search for properties > with multiple values w/o having the user enter a regular expression. Currently, the only way to extract multivalue properties is to use the API functions: (info "(org) Using the property API") I believe single value properties should be the default behavior for searches (that is how the manual presents properties). I would certainly *not* want to have to escape spaces in property drawers when, say, entering AUTHOR and TITLE property values. Currently, the search logic of is relatively straightforward: 1. to force an exact property match, use TITLE="Quantum Mechanics" 2. to allow partial matches, use a regexp: TITLE={Quantum} Perhaps a patch could introduce an user option to use the multivalued API in property searches. This could be a nice option for custom commands. But I would recommend that the single value remain the default. Best, Matt