| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
Move an argument to its own line to avoid the warning from lisp-mode's
lisp--match-hidden-arg. (And while touching that line, fix up the
indentation of piem-notmuch--with-current-message's BODY.)
Message-Id: <20211224213153.8115-1-kyle@kyleam.com>
|
|
`notmuch-extract-patch` might not be available on PATH. This can be the
case if the package wasn't installed through the distro package manager.
[km] Added package-version keyword, and dropped if-let binding.
Message-Id: <20211221191527.11819-1-sourcehut@relevant-information.com>
|
|
notmuch-extract-patch is a command line tool from the elpa-mailscripts
package that extracts patches from a thread. It's a useful way to
extract the latest patch series from an email thread and filter out the
replies and reviews.
Message-Id: <20211216193234.25745-1-sourcehut@relevant-information.com>
|
|
There's no need to switch to the standard-output buffer because it can
be passed as a destination for call-process.
I go back and forth on whether I prefer (with-output-to-string ...) to
(with-temp-buffer ... (buffer-string)), but the main thing I like
about with-output-to-string is that the intention of the code is
declared at the start.
Message-Id: <20211025035505.297281-1-kyle@kyleam.com>
|
|
Allow users to set piem-mail-injection-skipif-predicate to
piem-notmuch-known-mid-p without worrying about whether
piem-notmuch.el is loaded.
Message-Id: <20211023171651.167143-1-kyle@kyleam.com>
|
|
A client may mirror and configure inboxes locally. Doing so enables
fast local access to public-inbox-httpd and public-inbox-nntpd. And
with the next pubic-inbox release (v1.7), it will be necessary to set
up local externals for lei.
That can lead to a good amount of information being duplicated between
the piem-inboxes option and ~/.public-inbox/config. To avoid this,
let users set an option to enable collecting information from
public-inbox's configuration.
This relies on code getting the list of inboxes with
piem-merged-inboxes rather than inspecting piem-inboxes directly.
That should be okay because at this point there should be very few
third-party callers. An alternative would be to merge values from the
configuration into the value of piem-inboxes. That'd let callers
continue to inspect public-inboxes, but I'd prefer not to touch the
value of a user option.
Message-Id: <20210610185943.14155-5-kyle@kyleam.com>
|
|
There are two spots that use (piem-inbox-get :url ...) and
piem-escape-mid to construct the public-inbox link, and there is about
to be another. Extract this shared logic.
Cc: Xinglu Chen <public@yoctocell.xyz>
Message-Id: <20210207075738.8752-2-kyle@kyleam.com>
|
|
|
|
This adds an entry to `notmuch-show-stash-mlarchive-link-alist` that
reads the `piem-inboxes` variable and returns the public-inbox archive
url. This means that users don't have to manually add public-inbox
archive urls to `notmuch-show-stash-mlarchive-link-alist`.
[km: added explicit error when inbox not found and fixed a few typos]
Message-Id: <8e8677cde716973081232aa65a37fa2fc621b15f.1612600790.git.public@yoctocell.xyz>
|
|
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".
|
|
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>
|
|
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>
|
|
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>
|
|
Message-Id: <20210104015435.18397-2-kyle@kyleam.com>
|
|
|
|
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>
|
|
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>
|
|
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.
|
|
|