From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.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 4cegJLqiymKcOwEATbCpxg (envelope-from ) for ; Sun, 10 Jul 2022 11:58:18 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id YAgeJLqiymIaQAEA9RJhRA (envelope-from ) for ; Sun, 10 Jul 2022 11:58:18 +0200 Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (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 76B3A11622 for ; Sun, 10 Jul 2022 11:58:15 +0200 (CEST) Received: by mail-pj1-x1035.google.com with SMTP id t5-20020a17090a6a0500b001ef965b262eso2469887pjj.5 for ; Sun, 10 Jul 2022 02:58:15 -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=2mJ2fJGd6D5NsHs9PK/ss38Sj+eUIVSycVjLg9UuZGo=; b=HTfbJ5LuRZkNeUkj1M0S86kgkJnUH0YOe35KXwrs3cgDrKV9jRCMRFhMvGw86qg7RY gRgzRhkB5CaPwsAfMTZXnXvb9F/GB6iNnDRj33IxdbKsqKQQe+LjdAVEtrfMv1d54uR/ YmvAlq2Jhpd8cZLoPP6gmvTNsDOxeI0P+19I6Z8qJhCnypT+Rqc7Zk9N654dLeTLN4h4 w8F7XTs28RjaDb8CTbzQjReZLlTJXgUPHXTiU/w8pGYwB7TRM+20Hz4jRHbzGfDECvvC G+elm+KSh75lBbasbDs4JHBySy5/nLjxspDNlKdyDIFBjWm3loy0LjRYEreZUpibo0j8 qQlQ== 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=2mJ2fJGd6D5NsHs9PK/ss38Sj+eUIVSycVjLg9UuZGo=; b=EFnQgcRnZlwFLdHtXfYDPEFJN6CNqopQq1kuFt4oogXZTVNeKON6ZjhY6XFDOWlUo1 1FQvEXneqHzPc3jEhjKxmajoJ2AYY/S3aiQM8yDDyj6uDNoHB9Kcjy2fGDL9X/XwcrDF /kGX6vlGDz/jyv5k+5eevhgN0523pXKTB2CG4C11JNwIzTFVBWkj7bsT4BTa83UN0/E5 DLzX8DWPQf+m5FDiEuiL4Fh8QPlMC+RHtZo9aNPCdySKpMQ27MvzaiYbQ8AFZcugzKSw 42KSO9Q2RBALfx5oh5SgqWJg7dzlDCtIOyGAqhT5dsN2uTRNSo1BjCwkgnjHhfepCCcN twbA== X-Gm-Message-State: AJIora9lcTuP1q2tiUXKfJLWowx1S34eIeIEtK+eM/sDgOgVY7hpadg+ bznxG15uirqAueZX7Rf6HWM= X-Google-Smtp-Source: AGRyM1sp8sfyyivavqereYhyUaLD2JIgHGpe2I2G8i+WnVbT1FIrecJdAdhKHaT4K2E6Gm7p6RpM3g== X-Received: by 2002:a17:902:f7cc:b0:16c:10a6:9e25 with SMTP id h12-20020a170902f7cc00b0016c10a69e25mr13213121plw.162.1657447093805; Sun, 10 Jul 2022 02:58:13 -0700 (PDT) Received: from localhost ([210.3.160.230]) by smtp.gmail.com with ESMTPSA id 4-20020a621404000000b0052ab764fa78sm2645744pfu.185.2022.07.10.02.58.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 10 Jul 2022 02:58:13 -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: <87czee6x7y.fsf@kyleam.com> References: <87czee6x7y.fsf@kyleam.com> Date: Sun, 10 Jul 2022 17:59:19 +0800 Message-ID: <874jzpuw3s.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Authentication-Results: aspmx1.migadu.com; none X-Migadu-Scanner: scn0.migadu.com X-TUID: swLWisgDC0pC Kyle Meyer writes: > Ihor Radchenko writes: > >> There is certainly some code duplication going on here (; > > For the two repeated blocks of the docstrings, I'm okay with a bit of > repeated documentation in this situation. Another option would be to > put something about the attachment order in the docstring of > piem-am-ready-mbox-functions, but that moves it farther from the > relevant context. (Or to just not document it at all.) > > If you're commenting more generally on the _code_ of > piem-gnus-am-ready-mbox and piem-notmuch-am-ready-mbox, I'm open to > suggestions for extracting out any remaining shared bits, but my hunch > is that most directions would obscure things. I referred to both code and the docstring. I'd define a separate function that inserts am-ready mbox: (defun piem-am-ready-mbox-generic (patches format) "Return a function that inserts PATCHES as an am-ready mbox. FORMAT is --patch-format value passed to `git am'. See `piem-am-ready-mbox-functions'. The PATCHES will be sorted by number before insertion." (cons (lambda () (setq patches (sort patches (lambda (x y) (< (car x) (car y))))) (dolist (patch patches) (insert patch))) format)) and then just call it from piem-notmuch-am-ready-mbox and piem-gnus-am-ready-mbox. >> Why using (and ...)? It feels like (when ...) is more appropriate in >> this context. > > I like the (very soft and fuzzy) style guideline of using `and` to > signal the return value is the primary thing of interest and `when` to > signal the code is executed for side effects. I'm not sure who I first > saw describe this convention [*], when I started to share the > preference, or how consistent I am in how I apply it. > > Due to indentation, nesting, and/or grouping, I think there are cases > where it's more readable to use `when`, such as the top-level `when` > above. Perhaps on a different night I would have felt the same about > the `and` you mentioned and flipped it to a `when`. > > Is there a particular reason you prefer `when` in the above case? > > > [*] I'm not sure how widely this preference is shared among Elisp > coders. Perhaps it mostly comes from elsewhere, like Common Lisp > (): > > As a matter of style, `when` is normally used to conditionally > produce some side effects, and the value of the `when` form is > normally not used. If the value is relevant, then it may be > stylistically more appropriate to use `and` or `if`. > > I recall seeing Nicolas state it several times in reviews on the Org > list. Some examples: > > - https://list.orgmode.org/?q=f%3Anicolas+AND+nq%3Awhen+ADJ+nq%3Aside > - https://list.orgmode.org/87d23sdtod.fsf@nicolasgoaziou.fr/ I do agree that using side-effects inside `and' is confusing and `when' should be preferred. However, we are talking about an opposite situation here. No side effects and we intend to provide a return value. The cites style convention does not necessarily apply in reverse except that `when' should not ideally be used. When choosing between `and' and `if' I personally also dislike using (and condition1 condition2 ... return-value) I find (if (and condition1 condition2 ...) return-value nil) more clear because it signifies that nil is an intended return value. Of course, this is a very minor stylistic comment - something I "feel" right from Elisp experience. I am not even a professional developer for what it's worth. Best, Ihor