From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id CIgfIxBYQ2HhSAAAgWs5BA (envelope-from ) for ; Thu, 16 Sep 2021 16:43:28 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id CLfHHhBYQ2HHQgAA1q6Kng (envelope-from ) for ; Thu, 16 Sep 2021 14:43:28 +0000 Received: from mail.notmuchmail.org (nmbug.tethera.net [IPv6:2607:5300:201:3100::1657]) (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 3BC5421512 for ; Thu, 16 Sep 2021 16:43:28 +0200 (CEST) Received: from nmbug.tethera.net (localhost [127.0.0.1]) by mail.notmuchmail.org (Postfix) with ESMTP id AD90826CDB; Thu, 16 Sep 2021 10:43:23 -0400 (EDT) Received: from mailproxy03.manitu.net (mailproxy03.manitu.net [217.11.48.67]) by mail.notmuchmail.org (Postfix) with ESMTPS id E896026CD8 for ; Thu, 16 Sep 2021 10:43:21 -0400 (EDT) Received: from localhost (200116b86053f30071ef3627e15627a1.dip.versatel-1u1.de [IPv6:2001:16b8:6053:f300:71ef:3627:e156:27a1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: michael@grubix.eu) by mailproxy03.manitu.net (Postfix) with ESMTPSA id 5C5F412A058F; Thu, 16 Sep 2021 16:43:20 +0200 (CEST) MIME-Version: 1.0 In-Reply-To: <20210916122414.udswscp7hn6tvkae@wrt> References: <20210916102517.1744389-1-andreas@rammhold.de> <163179378465.773443.12112139662488774678.git@grubix.eu> <20210916122414.udswscp7hn6tvkae@wrt> Subject: Re: [RFC 0/2] add --new-tags= to notmuch-new(1) From: Michael J Gruber To: andreas@rammhold.de Message-ID: <163180339093.773443.420431965254110101.git@grubix.eu> Date: Thu, 16 Sep 2021 16:43:10 +0200 User-Agent: alot/0.9.1 Message-ID-Hash: FIVUJIYDBI2J7QIZ3TBRXHC66EO2ZIKG X-Message-ID-Hash: FIVUJIYDBI2J7QIZ3TBRXHC66EO2ZIKG X-MailFrom: michael@grubix.eu 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 CC: notmuch@notmuchmail.org 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=1631803408; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc: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=v4dX3UV/ZfNIbyFxPRPHOrgP0ZxLbW/nCmOtbb3HTm4=; b=IZnr6ABwCY9VgVNo67HwT+V2tqsv6TEIeHOxR50tFUOvdHIJDCVPBceifPnb+VyYiF1Jv7 Vaay3xbauZYl/hwp+zqYP9+grffkFF/4Mm7abYuNdaIiBhlBW8l0TPDtlIGXp9sJpCPCAR l+eCSMWfjijadgvrocoGfqXTDtatZhG5moKzRlKppNftjmJ3RNSXzExmdfSpsFfghNKVjX 2eejG3Zy7cHcWWEE8a2glVAqlZePq39H0NpHIbbwWJ6UM+5rgKvpNMqq/cqyer576+JLLY OsYPTk2irnhQkd/YUckL1RmCSxwX1eorr4VqfZr3ypkZD5pS86s6MTiz8e+FDQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1631803408; a=rsa-sha256; cv=none; b=M6mAzEDGO+hWyO2WuOSQ+hcSt7Wo77zpFdDLC1KhqRv8PwdcMDMPiVT6Itlq7UwnTj5L4z u/G/b3sz53/AVjZil8goEJjtbMOUyfR9yt955EVAMMne0xBkSTDVUyq2T3fEjLu1EF9P/x copynmkKHYaswjQboe8IBd6XNgdNPqzncZJDY//HitGlkK0LXip36roarbZDxvtjE6h7J3 moFW6IREZWVm+5YVRHfxGjLMAwGnNuwsyykbZzotEyel9dJJR6OMaWzxPPaQhEeAMpZJzx n3wneJ+01oqcZdsPMIFzPBnsLTGqm3rVqqoQqxtlhk2xdpn2nKz360LDTUkATg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org designates 2607:5300:201:3100::1657 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Migadu-Spam-Score: -1.11 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org designates 2607:5300:201:3100::1657 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Migadu-Queue-Id: 3BC5421512 X-Spam-Score: -1.11 X-Migadu-Scanner: scn0.migadu.com X-TUID: rF4ywemuk5HD andreas@rammhold.de venit, vidit, dixit 2021-09-16 14:24:14: > On 14:03 16.09.21, Michael J Gruber wrote: > > I very much sympathize with your setup. But I think the real solution > > would be one of these options: > > > > - use a lock file to prevent your scripts from running concurrently OR > > That would work. I'd love if that could be moved into notmuch such > that running `notmuch new` will keep a (global) lock until all of the > messages have been processed and all of the hooks have been executed. > > This is probably tricky to get right consistently across the notmuch > code base. At least that was one of the comments I recall from a > conversation on IRC when that topic was brought up. I don't think it's notmuch's job to do that. But if you call notmuch for a specific folder you can instead call a wrapper script which keeps a folder-specific lock until that notmuch returns, and can you pass the folder to the hooks via environment. > > - match "tag:new and folder:UNIQUEFOLDER" (or "path:FOO/**") > > This should be a perfect substitute for your new-UNIQUE tag. > > How would the files end up in the UNIQUEFOLDER? What I probably forgot > to mention is that I do not sync only on the Mailbox boundary. I have an > IAMP IDLE instance for "Inbox" on all of the accounts and then more for > other folders in those accounts. I could probably script that (wouldn't > take more than an evening I am sure) but requires a lot more additional > code. I assumed that each of your different notmuch calls (from different IDLE instances) act on different folders or sets of folders, so that you can distinguish the messages either way. Depending on your setup, there may still be issues when a second sync interferes so that the "first" notmuch new tags messages from the "second" sync. That's exactly what a lock can prevent if you do the sync in a pre-new hook. > > > As for the implementation you suggest: Basically, you implement > > overriding the "new.tags" config, and I'm wondering whether it would be > > worthwhile to implement "notmuch --config-value" instead: > > > > --config-value=SECTION.ITEM=VALUE > > Override the config setting for SECTION.ITEM with the VALUE for > > this invocation. This takes precedence over any setting in the > > config file. > > That is an interesting idea. How would you implement that? Right now it > looks like all changes in configuration are written to disk when you > change them. That would require keeping a copy of all the settings in > RAM (which is probably already the case) and only mutating those without > writing to disk. ... and notmuch config get called from a hook should return that value, ideally (I don't know how). We already have at least these: notmuch {insert,new,reindex,reply,show} --decrypt overrides index.decrypt NOTMUCH_DATABASE overrides database.path and the env vars for config and profile interacting with --config. So I was hoping for a systematic solution. But I just love "git -c" too much :) Michael