From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: David Bremner <david@tethera.net>, Notmuch Mail <notmuch@notmuchmail.org>
Subject: Re: [PATCH] add has: query prefix to search for specific properties
In-Reply-To: <87ziphxfl2.fsf@zancas.localnet>
References: <1465779955-5539-9-git-send-email-david@tethera.net>
 <1467969336-7605-1-git-send-email-dkg@fifthhorseman.net>
 <87ziphxfl2.fsf@zancas.localnet>
User-Agent: Notmuch/0.22+77~gaba8744 (https://notmuchmail.org) Emacs/24.5.1
 (x86_64-pc-linux-gnu)
Date: Mon, 18 Jul 2016 01:44:27 +0200
Message-ID: <8760s36d9g.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list

On Sun 2016-07-17 02:39:53 +0200, David Bremner wrote:
> Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:
>
>> We want to be able to query the properties directly, like:
>>
>>    notmuch count has:foo=bar
>>
>> which should return a count of messages where the property with key
>> "foo" has value equal to "bar".
>>
>> This patch could be improved:
>>
>> If no = sign is present (e.g. "has:foo"), it'd be nice to just match
>>  on every message that has property "foo", regardless of value.
>
> At the moment I can't think of a nice easy way to do this.  It could do
> something like that proposed for "tag:*", namely expand it internally
> into an or query, by traversing the
> db->allterms_begin("XPROPERTY"). 
>
>> It would also be good to include some tests.
>
> and update notmuch-search-terms(7) ?

yes, please -- patches welcome ;)

an attempt to describe the distinction between "tags" and "properties":

Tags are user-settable and user-fetchable, and automated systems are
discouraged from adding them (we have some legacy exceptions like
"inbox" and "unread" and "signed" and "encrypted").  Tags are generally
expected to be simple textual labels.

Properties are user-fetchable, but should only be set by automated
systems.  Properties are key=value pairs (though a given message can
have any number of properties with the same key), and while the key is
expected to be a textual string (printable characters except for "=")
and the value can potentially be arbitrary binary data.

I welcome edits on this text if it doesn't capture your current sense of
the distinction.

     --dkg