From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 2617F6DE0F38 for ; Sun, 17 Feb 2019 11:35:25 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -15.817 X-Spam-Level: X-Spam-Status: No, score=-15.817 tagged_above=-999 required=5 tests=[AWL=-0.119, DKIMWL_WL_MED=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIlB0DT9FSGK for ; Sun, 17 Feb 2019 11:35:24 -0800 (PST) Received: from mail-pf1-f193.google.com (mail-pf1-f193.google.com [209.85.210.193]) by arlo.cworth.org (Postfix) with ESMTPS id 643366DE0F22 for ; Sun, 17 Feb 2019 11:35:24 -0800 (PST) Received: by mail-pf1-f193.google.com with SMTP id n125so134958pfn.5 for ; Sun, 17 Feb 2019 11:35:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=+w3ECN4ue6ek4huHCp2697lBYp2fV5orhdhkHtj6onw=; b=VSu9mkm4XY30I/T3OvjjAOO2eNCLdXvuuUZH9O+PS8tbTkw3Odc/YgEHBiXil/ZWgu BTP3QahZ2PPeWlpmK2j8vukqzfzlZvcmZXnQfwhYljseptvDLwXLbQj6SWMAxQtaHvuQ NMFlEjUoQLq+ohcBeuU9DVgidGNGmkwIdXK15K0Zj4Gz3+E0aMXu4/qgZJtFnClx6Hoo w3USIADyJn5eS3Yr40ubWruypugNuh9PM7ZyVQ+7/OYHkxdFyKC+Ww/OqNtPoGRJiEjC ohP+0s3kw160vNOb8b8Dl8qaJf+uqrHbhiV86Y9YCAsZfTrhrJU4L/7/3HFwic278e7E wtBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=+w3ECN4ue6ek4huHCp2697lBYp2fV5orhdhkHtj6onw=; b=HScgRSUP9myWWxefriSKjf9wA8T4ErBkvTEnUNTCV3hQIz0mcwZf2XAH/LB82r7stM SzAPeKNocgQ1UYqARlcC714ISmhC2gGBpoExEu05Yh4sZiQJwGSQsHMdAnoJu9SZxSj8 RjTBMeXN7Nw3ujCvYMqIpM2HHSw+p68CX8aXTZbLWsKjc+celOxfDhDmmHHyJZnlUsoi TXIndRNU+U9PdWN85NBG+nEb5jwfYuW6N0gqTk2D1yeTd/k3w9XkbOcOq0XbdN+uRUue mHXnhEXQuWEChnLpLxpejTVPQtFfeapoF2MHeLMe+yj7RF70KOndsL363SYvbwAp/Jjs v1Xw== X-Gm-Message-State: AHQUAuamqZhSODg56cQjSsoOo1BoSc29CpkasD+IKDgwiM68ER8SSs/q emkvYGh0TVQ0yWDty+9K/mTql+g3CH8= X-Google-Smtp-Source: AHgI3IbuMHF1q6ot/WiYPong6FnIaPqrqekQUOmG7xV3AUP2bourhwqJXOIg0wPUiKJhO4bqO/zB4A== X-Received: by 2002:a62:5c87:: with SMTP id q129mr8527780pfb.180.1550432123323; Sun, 17 Feb 2019 11:35:23 -0800 (PST) Received: from naz.kir.corp.google.com ([2620:0:1008:11:1808:d974:65ca:bcbe]) by smtp.gmail.com with ESMTPSA id e24sm15178901pfi.153.2019.02.17.11.35.20 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 17 Feb 2019 11:35:20 -0800 (PST) From: Matt Armstrong To: notmuch@notmuchmail.org Subject: On properties and the notmuch CLI Date: Sun, 17 Feb 2019 11:35:19 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2019 19:35:25 -0000 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-- prefix convention for all properties not registered with the notmuch project? That seems to have served well enough for email headers.