summaryrefslogtreecommitdiff
path: root/piem.el
AgeCommit message (Collapse)Author
2021-02-06Update copyright lines for a +1 contributor worldKyle Meyer
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".
2021-02-02piem-inbox-coderepo-maybe-read: Support project.elXinglu Chen
Add support for reading directory using project.el. project.el is a built-in library that offers similar functionality to projectile. It is also available on GNU ELPA. [km: repositioned fboundp call] Message-Id: <8ce1733ac0d0f63622d9060015949f31ce83d6ee.1612294275.git.public@yoctocell.xyz>
2021-01-29Prefer string-suffix-p to string-match-pKyle Meyer
It's faster and to my eyes slightly more readable. This changes the behavior of piem--ensure-trailing-slash for the edge case of "/". While I think the new behavior makes more sense, it doesn't matter in practice.
2021-01-19inject: Anchor 'From mboxrd@z ...' searchKyle Meyer
piem--write-mbox-to-maildir finds the bounds for each message by doing a plain search for "From mboxrd@z", but of course nothing prevents that from being within the text of the message. Anchor it to the start of the line to prevent false positives. Message-Id: <20210119054042.11985-1-kyle@kyleam.com>
2021-01-03gnus, notmuch: Absorb now-shared bits into patch attachment helperKyle Meyer
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>
2021-01-03Decode more message headersKyle Meyer
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>
2021-01-03Update copyright year to 2021Kyle Meyer
2020-12-24piem-inboxes: Document that :url must include trailing slashKyle Meyer
2020-12-08process buffer: Restore header's leading newlineKyle Meyer
94d0281 (process buffer: Add time to header, 2020-11-27) was just supposed to add a "time:" field, but it also dropped the leading "\n". Add it back, and also avoid the unnecessary concat call. Message-Id: <87h7ovstub.fsf@kyleam.com>
2020-11-28process buffer: Add time to headerKyle Meyer
Recording the time makes it easier to digest and group the subprocess commands when inspecting the buffer later. Message-Id: <20201127205815.17313-1-kyle@kyleam.com>
2020-11-27piem: Put dispatch transient in its own sectionKyle Meyer
The dispatch transient is under the "Patch handling" section, which doesn't really fit because it already has a command that isn't related to patch handling (piem-inject-thread-into-maildir) and will gain more.
2020-11-22gnus, notmuch: Consider text/plain patch attachmentsKyle Meyer
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>
2020-11-22gnus, notmuch: Share "attachment is patch?" logicKyle Meyer
This will gain another condition. Avoid repeating it across two spots. Message-Id: <20201122204609.12604-3-kyle@kyleam.com>
2020-11-15am: Allow flipping worktree creation with prefix argumentKyle Meyer
I tend to use a few dedicated worktrees for projects and am not interested in creating a worktree for each patch series I apply. However, I can imagine wanting to create one every now and then. Make it possible by adding a prefix argument to piem-am and piem-b4-am-from-mid that flips the meaning of piem-am-create-worktree. Message-Id: <20201115061518.22191-6-kyle@kyleam.com>
2020-11-15am: Add option to configure how worktree is readKyle Meyer
It seems likely that piem-am-read-worktree won't quite behave as some callers want. Let users specify a custom function. Message-Id: <20201115061518.22191-5-kyle@kyleam.com>
2020-11-15am: Support creating a new worktreeKyle Meyer
On the guix-patches list, simon described a workflow in which a new worktree is used to apply patches. Such a workflow is fairly straightforward to support in piem-am (and thus piem-b4-am-from-mid). Aside form reading the worktree from the caller, the main change needed is to replace 'git checkout (-b BRANCH|--detatched) [base]' with 'git worktree add (-b BRANCH|--detatched) PATH [base]'. Teach piem-am to use a worktree when piem-am-create-worktree is non-nil. Suggested-by: zimoun <zimon.toutoune@gmail.com> Ref: https://yhetil.org/guix-patches/86361cys9h.fsf@tournier.info Message-Id: <20201115061518.22191-4-kyle@kyleam.com>
2020-11-15piem-am: Store "empty string" branch checkKyle Meyer
This will be needed in another spot. Message-Id: <20201115061518.22191-3-kyle@kyleam.com>
2020-11-15piem-am: Rephrase CODEREPO descriptionKyle Meyer
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>
2020-11-08Add a dispatch transient for commandsKyle Meyer
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>
2020-09-21piem-name-branch-who-what-v: Relax sender name extractionKyle Meyer
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>
2020-09-19Fill in missing library commentariesKyle Meyer
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.
2020-09-19piem.el: Add homepage to headerKyle Meyer
2020-09-19piem.el: Fix typo in library descriptionKyle Meyer
<blush>
2020-09-19Escape message IDs when constructing URLsKyle Meyer
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>
2020-09-06Release version 0.1.0v0.1.0Kyle Meyer
2020-08-28elfeed, eww: Be stricter about the returned message IDKyle Meyer
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>
2020-08-28piem-inbox-{codrepo,get}: Allow caller to specify inboxKyle Meyer
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>
2020-08-28Add accessor for piem-inboxesKyle Meyer
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>
2020-08-28elfeed, eww: Don't assume inbox name in piem-inboxes and URL matchKyle Meyer
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>
2020-08-27Switch downloads to url-retrieve-synchronouslyKyle Meyer
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>
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-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-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.