Age | Commit message (Collapse) | Author |
|
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>
|
|
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".
|
|
Inserts a string of the whole thread in mbox format.
Message-Id: <796fb84d852f2a5adea1502db144dae1bdc4fe0c.1611132172.git.public@yoctocell.xyz>
|
|
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-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>
|
|
|
|
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>
|
|
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.)
|