From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms4r.migadu.com with LMTPS id kLF7GkowyWKeWwEATbCpxg (envelope-from ) for ; Sat, 09 Jul 2022 09:37:46 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id uABLGkowyWKmUgEAauVa8A (envelope-from ) for ; Sat, 09 Jul 2022 09:37:46 +0200 Received: from mail-oa1-x35.google.com (mail-oa1-x35.google.com [IPv6:2001:4860:4864:20::35]) (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 5277330778 for ; Sat, 9 Jul 2022 09:37:46 +0200 (CEST) Received: by mail-oa1-x35.google.com with SMTP id 586e51a60fabf-10be0d7476aso1314813fac.2 for ; Sat, 09 Jul 2022 00:37:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=nlHCN5Hfna/Tk4JVzpTMKLhcfVbG6tNq2HcrqzBCAwI=; b=c3yqqpCSvEkFG7zC6wn4buTbgjsxPxp2vdU3hQnXGUTa3Vsb886fQuNnqDT6veFF52 xKt87Z/IPIW4woChTQnA2KdtXhO16U3iRhTBqQ6QsxLFBaqf1bmLgIW3eC9N1CnMVBPr 1RiaDFSc4wNj4sYkbum/8oskdjnpoo/rD7kSK/XgLJGgT/2XN53kUg0DszGie8tqtrjt ZoRGpEtCEZjO/4LdiMtRXjYrF501tH+AcM++WDW7SU8Ph/g2uwotCY5An6W1G6vlOG/o /v2Y9RjADE1b2BEDTN3fmS+LdmkdfpSE40Z5WhSU7XtHOuISCXA2mEPZ/gWgcatSveFz SQCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=nlHCN5Hfna/Tk4JVzpTMKLhcfVbG6tNq2HcrqzBCAwI=; b=JlmfQjrLLeHDwh3Bl0hp5UvrKmc3opG7xAhOp6YS6YOwkccBnVY61SfyLV0CrN1j7w 6GO8gLm7OE0a5Xkx/4y6aJIwNfQD/LCmgGKgEW/xrUIIqVKY2+O3Be2GjuTvyMZZJI8K 2R8y0j+acbtBM4DA792xt9O5MKl0IAmWTy4IH2lWe3ne2oe/GgXA88OKaxRO52Gw7kP5 ev60ek/lLZgZhppo8uVkOkBQwGaCXOL0ZHeIDk5hanV7a3MgHB99vGnj/WGGOr988fyC UFQt3/nVS+OkUE3CvzaLCCqdT+xUMOa0GgmRrkix3aInDbp90ITR1sZng3XocY8uQXqv O/SQ== X-Gm-Message-State: AJIora9ia3csJpI6Qt3uJq6h6pyGtp1LRkTE4jKa2Fg0GgyEw7hoHiIF tvYaL8RzDRf6TBDHqvaOENeB1Ds2uTacJtSb X-Google-Smtp-Source: AGRyM1sNr8CUudTlJA/SrdnjVgPuIMsbm9P6mKCdHzClP+D1V2PIMC3wqU4XDCIbtRBRest45/O+Xw== X-Received: by 2002:a05:6870:56a3:b0:10c:1548:4bb1 with SMTP id p35-20020a05687056a300b0010c15484bb1mr2110389oao.24.1657352265151; Sat, 09 Jul 2022 00:37:45 -0700 (PDT) Received: from localhost ([134.73.242.163]) by smtp.gmail.com with ESMTPSA id u27-20020a056830231b00b00616d3ec6734sm487944ote.53.2022.07.09.00.37.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 09 Jul 2022 00:37:44 -0700 (PDT) From: Ihor Radchenko To: Kyle Meyer Cc: piem@inbox.kyleam.com Subject: Re: [PATCH] piem-am: Order attached patches by file name prefix In-Reply-To: <878rp2pyx1.fsf@kyleam.com> References: <878rp2pyx1.fsf@kyleam.com> Date: Sat, 09 Jul 2022 15:38:50 +0800 Message-ID: <87fsjaspkl.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Authentication-Results: aspmx1.migadu.com; none X-Migadu-Scanner: scn0.migadu.com X-TUID: lcYYl2TRNk3J Kyle Meyer writes: > Regardless of what you call it, I don't mind piem trying to be more > clever/helpful in these scenarios. How about something like this? > (Tested on <87v8s8n1bm.fsf@heagren.com> from Notmuch and Gnus.) LGTM! I only have some minor comments on the code. > (defun piem-gnus-am-ready-mbox () > "Return a function that inserts an am-ready mbox. > + > If the buffer has any MIME parts that look like a patch, use > -those parts' contents (in order) as the mbox. Otherwise, use the > -message itself if it looks like a patch." > +those parts' contents as the mbox, ordering the patches based on > +the number at the start of the file name. If none of the file > +names start with a number, retain the original order of the > +attachments. > ... > (defun piem-notmuch-am-ready-mbox () > "Return a function that inserts an am-ready mbox. > + > If the buffer has any MIME parts that look like a patch, use > -those parts' contents (in order) as the mbox. Otherwise, use the > -message itself if it looks like a patch." > +those parts' contents as the mbox, ordering the patches based on > +the number at the start of the file name. If none of the file > +names start with a number, retain the original order of the > +attachments. There is certainly some code duplication going on here (; > + (when (listp handle) > + (let ((type (mm-handle-media-type handle)) > + (filename (mm-handle-filename handle))) > + (and (or (member type '("text/x-diff" "text/x-patch")) > + (and filename > + (equal type "text/plain") > + (string-suffix-p ".patch" filename t))) > + (with-temp-buffer > + (mm-display-inline handle) > + (cons > + (string-to-number filename) > + (buffer-substring-no-properties (point-min) (point-max)))))))) Why using (and ...)? It feels like (when ...) is more appropriate in this context. Best, Ihor