aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-08-25README: Bring a link target inlineKyle Meyer
2020-08-25README: Update description of statusKyle Meyer
2020-08-25manual: A rough and incomplete startKyle Meyer
2020-08-25Split a code sectionKyle Meyer
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.
2020-08-23notmuch: Extract "known message?" logic to functionKyle Meyer
Notmuch users can set piem-mail-injection-skipif-predicate to the new function. Message-Id: <20200822190130.20397-4-kyle@kyleam.com>
2020-08-23inject: Support skipping messagesKyle Meyer
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>
2020-08-23inject: Abbreviate piem-maildir-directory in messageKyle Meyer
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>
2020-08-17b4: Try to download thread from piem-inboxes URLKyle Meyer
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>
2020-08-17b4: Use a clearer variable nameKyle Meyer
Message-Id: <20200817013343.15615-5-kyle@kyleam.com>
2020-08-17Extract logic from inject-thread-callbackKyle Meyer
An upcoming commit will use this same logic in another callback. Message-Id: <20200817013343.15615-4-kyle@kyleam.com>
2020-08-17Move "has gunzip?" check to helperKyle Meyer
This will be needed in another spot. Message-Id: <20200817013343.15615-3-kyle@kyleam.com>
2020-08-17Use url-http-end-of-headers move to payloadKyle Meyer
Message-Id: <20200817013343.15615-2-kyle@kyleam.com>
2020-08-16piem-inbox-coderepo-maybe-read: Expand paths from projectileKyle Meyer
The other methods return expanded absolute paths. Do the same here. Message-Id: <20200816185130.32703-4-kyle@kyleam.com>
2020-08-16piem-inbox-coderepo-maybe-read: Include current projectile projectKyle Meyer
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>
2020-08-16piem-inbox-coderepo-maybe-read: Require projectile project matchKyle Meyer
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>
2020-08-16piem-inbox-coderepo-maybe-read: Reject invalid empty-string inboxKyle Meyer
Message-Id: <20200816185130.32703-1-kyle@kyleam.com>
2020-08-11piem-am: Clean up hidden buffers produced by interactive callsKyle Meyer
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>
2020-08-10Fix handling of -am-ready-mbox valuesKyle Meyer
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>
2020-08-10Explicitly specify --patch-format in git-am callsKyle Meyer
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>
2020-08-09Convert unnecessary let* to letKyle Meyer
2020-07-24gnus: Enable functions in gnus-summary-modeKyle Meyer
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.
2020-07-19Don't assume "From:" exists when extracting infoKyle Meyer
I hit into a type error by calling piem-am, without thinking, on an attachment of a plain diff.
2020-06-27piem-am: Call git-am with --3wayKyle Meyer
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.
2020-06-27piem-am: Move git-am arguments to variableKyle Meyer
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.
2020-06-27piem-am: Drop to-do commentKyle Meyer
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.
2020-06-21eww: Note limitation of extracting inbox name from URLKyle Meyer
2020-06-21process: Ensure output is inserted at end of bufferKyle Meyer
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.
2020-06-15Add docstrings to all -am commandsKyle Meyer
2020-06-14Autoload piem-am commandKyle Meyer
2020-06-13Support adding Message-Id to attached patchesKyle Meyer
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>
2020-06-11Use appropriate message-narrow-* variant (again)Kyle Meyer
This should have been done as part of 9faded3 (Use appropriate message-narrow-* variant, 2020-06-06).
2020-06-11Reposition two incorrectly placed thingsKyle Meyer
Neither of these belong in the "Options" section.
2020-06-11piem-{gnus,notmuch}-am-ready-mbox: Fix docstring typosKyle Meyer
2020-06-07Add command for downloading/injecting t.mbox.gz into a MaildirKyle Meyer
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.
2020-06-07Add function for accessing inbox's URLKyle Meyer
2020-06-07Copy over some Maildir utilities from NotmuchKyle Meyer
These will be used for writing messages from a public-inbox t.mbox.gz into a Maildir directory.
2020-06-06Fix copy-paste errorKyle Meyer
:/
2020-06-06gnus: Add support for piem-am-ready-mboxKyle Meyer
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.
2020-06-06notmuch: Add support for piem-am-ready-mboxKyle Meyer
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.
2020-06-06piem-patch-subject-re: Permit other text before the patch prefixKyle Meyer
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]".
2020-06-06Move regexp for patch subjects into a variableKyle Meyer
The piem-{notmuch,gnus}-am-ready-mbox functions will need this regexp too.
2020-06-06Convert piem-am into a standalone commandKyle Meyer
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.
2020-06-06Add piem-process- variant that accepts a buffer for stdinKyle Meyer
This will be used to feed git-am the buffer returned by piem-am-ready-mbox.
2020-06-06Add piem-am-ready-mboxKyle Meyer
This will enable libraries to provide an mbox that piem-am can use.
2020-06-06Don't pass invalid starting point to 'git checkout'Kyle Meyer
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.
2020-06-06Add piem-inbox-coderepo-maybe-read functionKyle Meyer
This logic will be used in another spot.
2020-06-06piem-extract-mbox-info: Process "From:" with rfc2047-decode-stringKyle Meyer
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.
2020-06-06Correct defcustom type for piem-default-branch-functionKyle Meyer
2020-06-06Extract patch information from a buffer rather than filesKyle Meyer
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.
2020-06-06Use appropriate message-narrow-* variantKyle Meyer
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.
Generated by cgit. Colors based on the Modus themes.