aboutsummaryrefslogtreecommitdiff
path: root/piem-gnus.el
AgeCommit message (Collapse)Author
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.)