| Age | Commit message (Collapse) | Author |
|---|
|
Message-Id: <20201122204609.12604-4-kyle@kyleam.com>
|
|
This will gain another condition. Avoid repeating it across two
spots.
Message-Id: <20201122204609.12604-3-kyle@kyleam.com>
|
|
Message-Id: <20201122204609.12604-2-kyle@kyleam.com>
|
|
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.
|
|
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.
|
|
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).
|
|
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>
|
|
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>
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
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.)
|