I see that notmuch supports a tag-like concept called a property. They seem to differ from tags in three ways: (a) they aren't shown as user visible "tags", so they can be set on messages without confusing users with message specific metadata that is not related to how they want to classify their mail. (b) they are key/value pairs, not merely a tag. (c) it is not possible to set or modify properties from the command line. First, a confirming question: it is possible to efficiently search for all messages that set a given property 'P' with a search for: property:P= True? Are queries like these any more efficient than tag doing a prefix regex search over tags? By this I mean, does the Xapian side keep an efficient index of all messages that have at least one property "P"? Second, a question: is there any possibility of relaxing restriction (c) above? My rationale is this: I'd like it to be possible to write notmuch "extensions" without binding to the notmuch C API (which feels quite low level, and an installation point of friction for those who might want to use the extension). I'd like, for example, to be able to write fully capable extension logic in Emacs itself (let's ignore Emacs C "modules" for now). Currently, I am writing code that interacts with notmuch from Go, and while there are some Go bindings, using them is an extra level of complexity I'd rather avoid. Concrete use case ideas: - were someone to write a fully functional Gnus backend (nnnotmuch?), it would be useful to store Gnus metadata directly in notmuch itself (e.g. the message numbers knows to Gnus itself). I don't have a full design for this, nor do I intend to do it, but the *idea* of doing this feels very much like what Free Software is all about enabling. - were someone (me) writing a Go program that used the GMail API to sync messages to notmuch, I'd love to be able to set properties on messages at "notmuch insert" time. This would let me leverage the notmuch database instead of having to resort to hacks (like avoiding "notmuch insert" entirely, and playing games with filename encoding schemes to encode the same data with the message). As far as the risk of property name collisions, perhaps encourage an x-<project>- prefix convention for all properties not registered with the notmuch project? That seems to have served well enough for email headers. _______________________________________________ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch