| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
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).
|
|
Notmuch users can set piem-mail-injection-skipif-predicate to the new
function.
Message-Id: <20200822190130.20397-4-kyle@kyleam.com>
|
|
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>
|
|
|
|
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.
|
|
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.
|
|
|
|
This will be used in the upcoming piem-gnus.el as well.
|
|
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.
|
|
|