aboutsummaryrefslogtreecommitdiff
path: root/piem-gnus.el
AgeCommit message (Collapse)Author
2022-07-10piem-am: Order attached patches by file name prefixKyle Meyer
When extracting patches from attachments, piem-gnus-am-ready-mbox and piem-notmuch-am-ready-mbox construct the mbox messages in the same order as the attachments. This depends on the sender attaching the patches in ascending order. Be a bit more helpful in situations where the sender attaches the patches out of order by reordering patches according to the NNNN- prefix that git-format-patch adds to the start of the patch file name. This approach won't be able to reliably sort patches that aren't generated by git-format-patch, but that's outside of any use case that piem is intended to support. Suggested-by: Ihor Radchenko <yantar92@gmail.com> Link: https://inbox.kyleam.com/piem/87mtdj9dzt.fsf@localhost Message-Id: <878rp2pyx1.fsf@kyleam.com>
2022-06-20gnus: Call message-field-value with lower case headerKyle Meyer
The case doesn't matter; use lower case for consistency with other spots.
2022-02-06Drop dates from copyright linesKyle Meyer
public-inbox has started to drop dates from its copyright lines, pointing to the recommendation at https://www.linuxfoundation.org/blog/copyright-notices-in-open-source-software-projects/ I regularly fail to keep copyright lines up to date, so I'll gladly follow suit. While touching these lines, change "all contributors" to "all piem contributors" to get a bit closer to the variants recommended in the above article.
2021-09-22Prefer mail-decode-encoded-word-string to rfc2047-decode-stringKyle Meyer
mail-parse.el defines mail-decode-encoded-word-string as an alias for rfc2047-decode-string. Use the higher-level wrapper for the reasons described in (emacs-mime)Interface. Message-Id: <20210923012353.256964-1-kyle@kyleam.com>
2021-02-06Update copyright lines for a +1 contributor worldKyle Meyer
I considered having each contributor keep their own copyright line for each file up to date (like in Guix), but I don't want to have to remember to pester patch submitters for that in reviews. Instead go with a public-inbox-inspired "all contributors".
2021-01-20gnus: Add piem-gnus-mid-to-threadXinglu Chen
Inserts a string of the whole thread in mbox format. Message-Id: <796fb84d852f2a5adea1502db144dae1bdc4fe0c.1611132172.git.public@yoctocell.xyz>
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-03Decode more message headersKyle Meyer
piem-extract-mbox-info feeds the "from" header value through rfc2047-decode-string, but the same treatment should be applied to other header values. Message-Id: <20210103063425.22718-1-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-11-22gnus: Prefer mm-handle-media-type over direct accessKyle Meyer
Message-Id: <20201122204609.12604-2-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-10Update defgroup info linksKyle Meyer
When 05f3ca5 (manual: A rough and incomplete start, 2020-08-25) fleshed out the skeleton a bit, the individual nodes for the integration libraries got dropped and the one for b4 got renamed.
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-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-07-24gnus: Enable functions in gnus-summary-modeKyle Meyer
It makes sense for all of these functions to support gnus-summary-mode because point is often in the summary buffer when reading a thread. I punted on doing so initially because something probably should be done to ensure that the gnus-article-* variables that these functions rely on are up to date with the current line in the summary buffer. I'm still not sure of the best way to do that (assuming it really is an issue), but I think for common usage patterns the values won't be stale (e.g., browsing with gnus-summary-next-page and gnus-summary-next-unread-article), so simply relying on the current values may be good enough.
2020-06-11piem-{gnus,notmuch}-am-ready-mbox: Fix docstring typosKyle Meyer
2020-06-06gnus: Add support for piem-am-ready-mboxKyle Meyer
As with the notmuch- counterpart added in the previous commit, I only put this through very light testing, but it at least works in some cases.
2020-05-15Autoload minor modesKyle Meyer
2020-05-12Don't bother with piem-mid-to-thread-functions commentsKyle Meyer
There's not much point in having repeated comments across endpoints that note the fallback behavior in general. Shorten the comment in -gnus to just note that it'd be nice to have a Gnus variant. Assuming the messages are present locally, that'd be better than downloading the mbox from a public-inbox instance.
2020-05-11Add basic support for Gnus articlesKyle Meyer
Implement message ID and inbox getters. As noted in the comment, leave the mid->thread functionality undefined for now, because I don't know if there's a good way to do that in Gnus. These functions should probably learn how to work from gnus-summary-mode too, but leave that for later. (Similarly, -notmuch should also probably support notmuch-{search,tree}-mode in addition to notmuch-show-mode.)
Generated by cgit. Colors based on the Modus themes.