| Age | Commit message (Collapse) | Author |
|---|
|
Describing CODEREPO in terms of where git-am is called is a bit
confusing because piem-am does other things here as well (e.g. reading
the base and checking out a branch). And it won't necessarily be
where git-am is called once worktree support is added.
Give a more generic description.
Message-Id: <20201115061518.22191-2-kyle@kyleam.com>
|
|
A standard prefix command would do, but since piem-b4 already depends
on transient, use transient here as well to provide a more helpful
interface.
Message-Id: <20201109030034.11429-1-kyle@kyleam.com>
|
|
Let-bind mail-extr-ignore-realname-equals-mailbox-name to nil
(defaults to t) so that a sender name is returned for addresses like
"name <name@a.com>" and "name@a.com".
Also, let-bind mail-extr-ignore-single-names to its default value of
nil so that a user setting this option to t doesn't interfere with
piem-name-branch-who-what-v.
Message-Id: <20200921032214.16940-1-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.
|
|
|
|
<blush>
|
|
Message IDs can include characters that must escaped before being
included in the path part of public-inbox URLs. Add a variant of
url-hexify-string that uses the same set of characters as
public-inbox's mid_escape().
Message-Id: <20200919044639.26871-2-kyle@kyleam.com>
|
|
|
|
Using the second group in piem-link-re is not reliable because the
trailing part of the URL may be anything. Instead get the inboxes
:url first and then generate a regular expression that has that value
as the prefix.
Message-Id: <20200828031920.7515-5-kyle@kyleam.com>
|
|
All the callers at the moment only care about the current inbox, but
this is still useful for avoiding a repeated call to piem-inbox (and
an upcoming commit will use it to do so).
Message-Id: <20200828031920.7515-4-kyle@kyleam.com>
|
|
There's no need to have a function like piem-inbox-url for every key.
Drop piem-inbox-url, but keep piem-inbox-coderepo around because it
does a bit of extra processing on top.
Message-Id: <20200828031920.7515-3-kyle@kyleam.com>
|
|
piem-elfeed-get-inbox and piem-eww-get-inbox match the URL against
piem-link-re and take the second group as the inbox name. That's a
bad approach because the inbox name in the URL doesn't necessarily
match the one in piem-inboxes. For example, public-inbox's own
archive is https://public-inbox.org/meta/, but my entry in
piem-inboxes uses the name "public-inbox":
("public-inbox" :url "https://public-inbox.org/meta/" ...)
The approach also fails if the URL isn't a public-inbox message URL
because piem-link-re isn't very specific. (That will be improved in
an upcoming commit.)
Find the inbox name by matching the buffer URL against the :url values
in piem-inboxes.
Message-Id: <20200828031920.7515-2-kyle@kyleam.com>
|
|
piem-download-and-decompress uses url-retrieve and a callback, setting
url-asynchronous to nil. This approach doesn't seem to be sufficient
because I'm getting intermittent failures in piem-b4--get-am-files
related to unfinished processes. And taking a peek at
url-retrieve-synchronously suggests that indeed a good amount more is
needed to do a synchronous call with url-retrieve.
Switch piem-download-and-decompress over to
url-retrieve-synchronously. I haven't noticed any issues with the
url-retrieve call in piem-inject-thread-into-maildir, but switch that
over too for simplicity and consistency.
Message-Id: <20200828025605.1106-1-kyle@kyleam.com>
|
|
In 846c69c (b4: Try to download thread from piem-inboxes URL,
2020-08-16), the "Maildir injection" section gained code that's used
more widely. Move it to its own section.
|
|
Notmuch users can set piem-mail-injection-skipif-predicate to the new
function.
Message-Id: <20200822190130.20397-4-kyle@kyleam.com>
|
|
piem-inject-thread-into-maildir allows pulling a thread from a
public-inbox URL, but repeating the process to get new messages in the
thread leads to duplicates in the local store. Add a predicate that
the caller can configure to avoid this.
Note that the predicate has the entire message available to make its
decision, but it's called with the message ID for convenience because
that's likely the only information needed to determine if the message
is already in the local store.
Message-Id: <20200822190130.20397-3-kyle@kyleam.com>
|
|
The message is going to get longer when skip counts are reported, so
try to save some characters.
Message-Id: <20200822190130.20397-2-kyle@kyleam.com>
|
|
If a call to piem-b4-am-from-mid fails to generate the thread for a
message ID via piem-mid-to-thread-functions, b4 is called without a
local mbox. In this case, b4 tries to download the thread from the
URL specified by b4.midmask in the caller's Git configuration.
That works, but it's inconvenient because the user needs to configure
the URL in two places. If the current buffer is associated with an
inbox in piem-inboxes, try to download the thread from its :url before
falling back to b4's midmask.
Message-Id: <20200817013343.15615-6-kyle@kyleam.com>
|
|
An upcoming commit will use this same logic in another callback.
Message-Id: <20200817013343.15615-4-kyle@kyleam.com>
|
|
This will be needed in another spot.
Message-Id: <20200817013343.15615-3-kyle@kyleam.com>
|
|
Message-Id: <20200817013343.15615-2-kyle@kyleam.com>
|
|
The other methods return expanded absolute paths. Do the same here.
Message-Id: <20200816185130.32703-4-kyle@kyleam.com>
|
|
When piem-inbox-coderepo-maybe-read is called from within a project,
the current project isn't included in the collection because
projectile-relevant-known-projects excludes it when
projectile-current-project-on-switch is at its default value. That's
undesirable in this context; if there's a current project, it's likely
the one of interest (e.g., calling piem-b4-am-ready-from-mbox from a
project's directory).
Add the current project to the collection and make it the default.
Also, don't bother going down the projectile branch if there are no
known projects.
Message-Id: <20200816185130.32703-3-kyle@kyleam.com>
|
|
While it's possible that the caller wants to specify a path for a repo
that isn't yet registered as a project, it should be quite rare, and
disabling it decreases the chances of invalid input.
Message-Id: <20200816185130.32703-2-kyle@kyleam.com>
|
|
Message-Id: <20200816185130.32703-1-kyle@kyleam.com>
|
|
When called interactively, piem-am retrieves the mbox with
piem-am-ready-mbox. As piem-am-ready-mbox's docstring says, the
caller is responsible for cleaning up the buffer. Make piem-am do so
to avoid leaving a hidden buffer around for each mbox applied.
Message-Id: <20200811043220.14679-1-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 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.
|
|
|
|
:/
|
|
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.
|