From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:bcc0::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id tRnsKcv/h2CWTgAAgWs5BA (envelope-from ) for ; Tue, 27 Apr 2021 14:12:59 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id gP2UJMv/h2AaQQAAbx9fmQ (envelope-from ) for ; Tue, 27 Apr 2021 12:12:59 +0000 Received: from mail.notmuchmail.org (nmbug.tethera.net [144.217.243.247]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 7EEFE26ABD for ; Tue, 27 Apr 2021 14:12:58 +0200 (CEST) Received: from nmbug.tethera.net (localhost [127.0.0.1]) by mail.notmuchmail.org (Postfix) with ESMTP id 3AA0A27168; Tue, 27 Apr 2021 08:12:52 -0400 (EDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.18.15]) by mail.notmuchmail.org (Postfix) with ESMTPS id A0A9326874 for ; Tue, 27 Apr 2021 08:12:49 -0400 (EDT) Received: from [46.244.213.44] (helo=condition-alpha.com) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1lbMM7-0001M1-Lh; Tue, 27 Apr 2021 13:58:19 +0200 Message-Id: From: Alexander Adolf To: David Bremner , notmuch@notmuchmail.org Subject: Re: Two perceived query language imbalances In-Reply-To: <87lf992o99.fsf@tethera.net> References: <87lf992o99.fsf@tethera.net> Date: Tue, 27 Apr 2021 13:34:03 +0200 MIME-Version: 1.0 X-Df-Sender: YWxleGFuZGVyLmFkb2xmQGNvbmRpdGlvbi1hbHBoYS5jb20= Message-ID-Hash: TFXD6DGTJPMMUSRFVNNPV6M7B2GFH25U X-Message-ID-Hash: TFXD6DGTJPMMUSRFVNNPV6M7B2GFH25U X-MailFrom: alexander.adolf@condition-alpha.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-notmuch.notmuchmail.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header X-Mailman-Version: 3.2.1 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1619525578; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=5sSBkBwBpI5GHLWw2dFlrWXgJUOfqfAWkG0vGYxeXAc=; b=PwBuurw4G+VRRLnw34zsXom5n9rCUMdzKKztetf4X9xwFOL/pjvVbqjdM7BZjYuKrWcFDz awLdFpz5vIVASiyU71ZVnv8gHRlJWBkDgCrPdw+1vpqHJ2FPsDFKe+pbGbTEGn01891XKG b26gDZSlyBikujCXdS5fvsgUURGBTblKFA67MYEe4oCIOgli9Xm9pjlC1WfY4Ogozer990 CV5SFi5x6XYbWRGlHrxI8KKcggbpdtYX/i/U9OdRNOBPEECv7g50FwlonRzgtLDX/CxEPg 9Iach78NBGA57b3RfI6n0Ykz9vpHRSHefhkIit9ydIeodWbhA9Y4uq2TQJc/mQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1619525578; a=rsa-sha256; cv=none; b=N1lptIE0LFRp+cLk5UfqrKpkqVRwZirNf1LUxOpjAl+XgaHl9bUdWSX1dpuRm476BcKbKi 0xBmEuVrFer3fMbrlBFj6ahM6aRZFUycn61wiMbsaYWx7HIRMYgnOSz300Q43uWlYVn7jo AUDNRo8HbpeDNn2eZOfawx11iB7ZuJuuUo2627oo/RuroXqahHofskUS9IshKPwjgzAnsM QsQNDsMy6tNYdLlXNwCWzmMA8YFVjJTkfzg2ZD+zpPmN4vTMgRfDAX+qwDqk0wawZ3A1pX /pJb//pKy/B+HgQRLHWOFdyqNHAGW1MqcuCsmgKJTI8cQDyqE42e6qspzR+DAA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org designates 144.217.243.247 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Migadu-Spam-Score: -2.14 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org designates 144.217.243.247 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Migadu-Queue-Id: 7EEFE26ABD X-Spam-Score: -2.14 X-Migadu-Scanner: scn0.migadu.com X-TUID: Auv9PKiyh/u6 Hello David, Many thanks for your swift response, and explanations. David Bremner writes: > [...] >> Any technical reason for "from" having a regex search, but "to" not? > > Yes, it is purely technical. The regex support relies on the existence > of a Xapian value slot for the field in question. It isn't clear what > the time / space impact of adding another value slot would be. It is > probably not unbearable, but someone needs to do the tests. Showing of my lack of knowledge about Xapian, and hence what a "value slot" in that context is, it seems that for giving me the suggested, new regex capability on the "to" field would require extending the db schema, an would therefore and inevitably have a performance impact which would need to be evaluated before committing to adding this feature. Understood, and fair enough. Is there a "wish list" of sorts, and if so, could it perhaps seem worthwhile adding this to the wish list? >>> id: or mid: or mid:// >>> For id: and mid:, message ID values are the literal contents of >>> the Message-ID: header of email messages, but without the '<', >>> '>' delimiters. >> >> Similar thing here: "id:" and "mid:" can be used interchangeably, except >> for regex search. Adding "id:/regex/" would seem most useful to me. >> > > This was intentional, to avoid breaking existing scripts / internals > that rely on treating id: as the primary key for the database. At least > that was the concensus when we added it. It seems like one answer would > be for you to just use mid: all the time, since it already has the > behaviour you like. > [...] I see, thanks for the insight. In that light, what would be your take on featuring "id" less prominently in the documentation, so as to foster the sole use of "mid" for all new script developments? You could maybe even go as far as marking "id" as "deprecated and kept for backwards compatibility with legacy scripts only"; but without actually ever removing it, of course, since as you say it's needed for internal purposes. My intent on both points is not to give the impression anything were broken, but to have the query language and its documentation cause as little confusion as possible, even for the casual user (i.e. myself). Many thanks and looking forward to your thoughts, --alexander