From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,AWL,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 827A61F953; Mon, 15 Nov 2021 00:31:36 +0000 (UTC) Date: Mon, 15 Nov 2021 00:31:36 +0000 From: Eric Wong To: Leah Neukirchen Cc: meta@public-inbox.org Subject: Re: lei spawns mua before results are written Message-ID: <20211115003136.GA10976@dcvr> References: <871r3izczl.fsf@vuxu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <871r3izczl.fsf@vuxu.org> List-Id: Leah Neukirchen wrote: > I tried building some tooling to use lei with mblaze and stumbled upon > the fact that lei seems to spawn the mua before all mails are written > into the -o maildir; at least, adding a "sleep 1" in front of my > script fixes it. Any way to wait for it? I guess I could just run lei > and my mua scripts afterwards. Yes, it's intentional to allow Maildir and IMAP to allow MUAs to work progressively while loading similar to how less(1) and typical web browsers work. It's not really practical to do for mbox* because of locking and potential incompatible locking protocols. You should be able to use --alert=COMMAND to run any arbitrary command(s) (including an MUA, as an alternative to --mua). I'm not sure if adding a --no-early-mua switch is needed. My gut reaction is having yet another switch to document increases the learning curve and support overhead... *shrug*