| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
I hit into a type error by calling piem-am, without thinking, on an
attachment of a plain diff.
|
|
I think I left this out initially with the idea that the user can (and
should) set am.threeWay to true. But I can't come up with a reason
why a caller wouldn't want to fall back to a 3-way merge [*], so pass
--3way as an explicit argument to benefit users that haven't
configured am.threeWay. Now that piem-am-args exists, a user can
always remove it if desired.
[*] And magit-am has had --3way on by default for a long time; I don't
recall any complaints.
|
|
It's tempting to define a transient for piem-am and let that handle
the arguments, but doing so only takes care of the case where piem-am
is the entrypoint, not piem-b4-am---which is already a transient with
b4 arguments. And it's not yet clear whether many users will need to
modify that these arguments across different calls (e.g., based on
conventions across different projects). For my purposes, a single set
of arguments is fine.
For now, add a defvar so that there's at least something to latch onto
if someone needs to modify the arguments unconditionally or via a
let-binding.
|
|
For the remaining commands that don't use Magit, it doesn't seem worth
introducing a separate code path. These don't interact with the
caller, and it'd be unnecessarily confusing to have different output
destinations (piem's process buffer versus Magit's) depending on the
value of piem-use-magit.
|
|
|
|
A previous process should leave point at the end of the buffer, but
the user is of course free to reposition it afterwards, so move to the
end of the buffer before staring a new process.
|
|
|
|
|
|
With an inline patch that has a Message-Id, this information can be
linked up to the patch when applied (e.g., with git-am's --message-id
flag or using a post-applypatch hook [1]). Unfortunately, this method
fails for projects where it is common to attach patches, as there is
no Message-Id within the patch.
Teach piem-am-ready-mbox how to insert the Message-Id that piem-mid
reports, which should always correspond to the message that contains
the patch attachments.
[1] Here's an example that used to keep the commit->Message-Id mapping
in git.git:
https://lore.kernel.org/git/xmqq7e5ag4g5.fsf@gitster-ct.c.googlers.com/
Message-Id: <20200613044933.4046-1-kyle@kyleam.com>
|
|
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.
|
|
|
|
These will be used for writing messages from a public-inbox t.mbox.gz
into a Maildir directory.
|
|
:/
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
|
|
|
|
Conceptually these are under ";;; Code", so add a ";" to reflect that.
|
|
|
|
|
|
This is my attempt to follow Chris Wellons's recommendations [*]. I'm
not sure how successful it is, but GNU make and bmake (from Debian)
seem happy.
[*] https://nullprogram.com/blog/2017/08/20/
https://nullprogram.com/blog/2020/01/22/
|
|
|
|
The pattern rule creates an autoload file for each .el, which isn't
very useful in the context of a multi-file package. Replace that with
a rule that creates a single autoloads file. Instead of calling
update-directory-autoloads directly use package.el, letting it worry
about setting the appropriate variables.
|
|
|
|
There's no need to autoload the non-interactive functions.
|
|
|
|
This option was added in b4 v0.4.1.
|
|
|