aboutsummaryrefslogtreecommitdiff
path: root/piem-notmuch.el
AgeCommit message (Collapse)Author
2021-01-29notmuch: Define group for piem-notmuch-modeKyle Meyer
Silence this warning: defcustom for ‘piem-notmuch-mode’ fails to specify containing group (I'm not sure why, but I don't see this when I run `make compile'.) Reported-by: Jonas Bernoulli <jonas@bernoul.li>
2021-01-03gnus, notmuch: Absorb now-shared bits into patch attachment helperKyle Meyer
With the previous commit, -notmuch more closely follows -gnus in its handling of attachments (e.g., getting the content with mm-display-inline). Replace piem-am-patch-attachment-p with a helper that has this shared logic. Message-Id: <20210104015435.18397-4-kyle@kyleam.com>
2021-01-03piem-notmuch-am-ready-mbox: Improve handling of attachmentsKyle Meyer
piem-notmuch-am-ready-mbox tries to get attached patches from the plist returned by notmuch-show-get-message-properties. This works okay for simple cases, but it doesn't find a patch if the content is encoded or if the MIME tree isn't structured as expected. Instead use mm-decode functions to get a list of handles and display their content. This new approach, as well as the previous one, probably isn't compatible with `format-patch --attach' patches, but I'm not going to worry about that until I actually see such a patch in the wild. Message-Id: <20210104015435.18397-3-kyle@kyleam.com>
2021-01-03piem-notmuch--with-current-message: Declare debug and indent specsKyle Meyer
Message-Id: <20210104015435.18397-2-kyle@kyleam.com>
2021-01-03Update copyright year to 2021Kyle Meyer
2020-11-22gnus, notmuch: Consider text/plain patch attachmentsKyle Meyer
When inspecting attachments for generating an am-ready mbox, both -notmuch and -gnus limit the operation to attachments with text/x-diff or text/x-patch content types. That has worked okay for me, though I've run into a few cases where I couldn't apply a patch attachment because it had a text/plain content type. To do something useful in this case, check the file name to see whether it looks like a patch. Message-Id: <20201122204609.12604-5-kyle@kyleam.com>
2020-11-22Use when-let in a few more spotsKyle Meyer
Message-Id: <20201122204609.12604-4-kyle@kyleam.com>
2020-11-22gnus, notmuch: Share "attachment is patch?" logicKyle Meyer
This will gain another condition. Avoid repeating it across two spots. Message-Id: <20201122204609.12604-3-kyle@kyleam.com>
2020-09-19Fill in missing library commentariesKyle Meyer
These aren't too useful (and I don't want to duplicate what is or at least should be in the manual), but they're better than nothing.
2020-09-06Drop version header from most librariesKyle Meyer
I haven't decided how I want to deal with packaging, but in any case there's no point in having a version heading for each library. Keep the one in piem.el since there's no *-pkg.el file (at this point, at least).
2020-08-23notmuch: Extract "known message?" logic to functionKyle Meyer
Notmuch users can set piem-mail-injection-skipif-predicate to the new function. Message-Id: <20200822190130.20397-4-kyle@kyleam.com>
2020-08-10Fix handling of -am-ready-mbox valuesKyle Meyer
0ee97e9 (Explicitly specify --patch-format in git-am calls, 2020-08-09) made it possible for a piem-am-ready-mbox-functions member to specify the format of the mbox by returning (FUNCTION FORMAT). If FUNCTION is returned, then mboxrd is supposed to be taken as the default format. The handling is broken, though, because piem-am-ready-mbox tries to detect the (FUNCTION FORMAT) form with listp, but that of course also returns true when the return value is simply a function. Instead, check to see whether the element matches a valid format value. Switch from (FUNCTION FORMAT) to (FUNCTION . FORMAT) to make it more convenient to pull out FORMAT with cdr-safe. Message-Id: <877du5c1nz.fsf@kyleam.com>
2020-08-10Explicitly specify --patch-format in git-am callsKyle Meyer
The sources of mbox patches fed to git-am are 1) threads downloaded from a public-inbox HTTP instance, 2) mboxes generated via piem-mid-to-thread-functions, and 3) those generated via piem-am-ready-mbox-functions. The first source should always be mboxrd. For the second, piem-notmuch-mid-to-thread is currently the only function suitable for piem-mid-to-thread-functions, and it uses mboxrd. The third source is a mix between mbox and mboxrd. By default, git-am tries to auto-detect the patch format, but let's explicitly specify --patch-format to avoid any incorrect guesses. Message-Id: <20200810020704.30150-1-kyle@kyleam.com>
2020-06-11piem-{gnus,notmuch}-am-ready-mbox: Fix docstring typosKyle Meyer
2020-06-06notmuch: Add support for piem-am-ready-mboxKyle Meyer
I was able to apply both an inline patch and a two-part patch attachment, though I'm not at all confident that the message property handling works in general. Let's see how this fares.
2020-06-05notmuch: Drop piem-notmuch-executableKyle Meyer
I just mindlessly added this, but I don't see any advantage of using a separate variable rather than notmuch-command. And if the option were to stay, it should default to notmuch-command. Drop the piem-notmuch defgroup as well, since there are now no options.
2020-05-15Autoload minor modesKyle Meyer
2020-05-11piem: Extract "inbox from headers" logic from -notmuchKyle Meyer
This will be used in the upcoming piem-gnus.el as well.
2020-05-10notmuch: Use more specific message-narrow-to-* variantKyle Meyer
message-narrow-to-headers-or-head will narrow to the message headers based on hitting two consecutive new lines or based on a match for mail-header-separator (by default "--text follows this line--"). Only the former condition is relevant in the context of a non-draft message, so use message-narrow-to-headers, which doesn't consider mail-header-separator.
2020-05-08Add basic support for NotmuchKyle Meyer
Generated by cgit. Colors based on the Modus themes.