| Age | Commit message (Collapse) | Author |
|---|
|
This should have been done as part of 9faded3 (Use appropriate
message-narrow-* variant, 2020-06-06).
|
|
Neither of these belong in the "Options" section.
|
|
I follow some public-inbox-archived projects over NNTP with Gnus.
However, once I get involved in a thread, I usually want the entire
thread in my local mail/Notmuch database (or at least the message I'm
replying to).
With this new command, if I see a message in Gnus (or EWW or Elfeed)
that I want to reply to, I can get it into Notmuch, assuming
piem-inboxes and piem-maildir-directory are wired up. And through
piem-after-mail-injection-functions, it's possible to jump straight to
the message with notmuch-show.
|
|
|
|
:/
|
|
Requiring that the patch prefix be at the beginning prevents matching
subjects for projects in which senders commonly put other prefixes
like "[bug#NNN]" before "[PATCH]".
|
|
The piem-{notmuch,gnus}-am-ready-mbox functions will need this regexp
too.
|
|
b4 is great, and I have no desire to create an Elisp implementation of
its complex patch series extraction. However, in cases where projects
permit patches as attachments, using b4 isn't an option. And even for
inline patches, it's useful to be able to git-am the patch associated
with the current buffer.
To support the above cases, teach piem-am to get an mbox from
piem-am-ready-mbox when called interactively.
|
|
This will be used to feed git-am the buffer returned by
piem-am-ready-mbox.
|
|
This will enable libraries to provide an mbox that piem-am can use.
|
|
If the caller doesn't enter a base, an empty string is passed as the
starting point to 'git checkout', causing it to fail. Instead, map
the empty string to nil, resulting in HEAD being used as the starting
point.
|
|
This logic will be used in another spot.
|
|
With encoded values, piem-name-branch-who-what-v of course comes up
with an unhelpful suggestion derived from the charset rather than the
sender's name.
|
|
|
|
piem-am will become a command that works with mboxes outside of -b4.
In this context, it's easier and cleaner to deal with a buffer than
temporary files.
|
|
In 0b81766 (notmuch: Use more specific message-narrow-to-* variant,
2020-05-10), I described the distinction between -head and -headers,
but I flipped around which was which! -head is the one that narrows
based on newlines.
|
|
The end goal is to turn piem-am into a command that can work with
patches extracted from the current buffer. Pull out the logic that
can be reused for this.
|
|
It messes with my comment heading navigation, and it's readable enough
when packed into a single line.
|
|
|
|
Directing all piem-related output to one buffer should be sufficient,
for now at least.
|
|
These are things that will be used outside of piem-b4.
|
|
|
|
|
|
There's no need to autoload the non-interactive functions.
|
|
The links in Elfeed entries only need the restricted variant, but the
extended one will be useful for EWW support.
|
|
alist-get uses eq as the default test function, so it was only working
by chance. Rather than calling alist-get with three additional
arguments in order to specify TESTFN, switch to assoc.
|
|
|
|
This will be used in the upcoming piem-gnus.el as well.
|
|
This does nothing useful, but the idea is that it never will do much
of anything on its own. Different libraries---piem-notmuch,
piem-elfeed, piem-gnus, and so on---will populate its hooks, teaching
it how to extract information.
|
|
|