| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Transient 0.3.0 was just released. Require it, and stop using now
obsolete macros.
Message-Id: <20210222034807.23437-1-kyle@kyleam.com>
|
|
piem-copy-mid-url will usually be called through piem-dispatch, which
is autoloaded, so autoloading piem-copy-mid-url doesn't matter in that
context, but users are of course free to bind/call piem-copy-mid-url
directly.
|
|
I don't use EWW as my default browser for browse-url, but, for
public-inbox HTTP access, I primarily use EWW. Add an option that
makes it easier to do so without adding lots of regular expressions to
browse-url-browser-function.
Message-Id: <20210207075738.8752-5-kyle@kyleam.com>
|
|
I find the notmuch-show-stash-mlarchive-link-and-go command useful.
It's like notmuch-show-stash-mlarchive-link but calls browse-url on
the copied URL.
Make piem-copy-mid-url do the same when given a prefix argument.
Message-Id: <20210207075738.8752-4-kyle@kyleam.com>
|
|
piem-notmuch configures notmuch-show-stash-mlarchive-link-alist with a
custom piem function that's useful for grabbing the pubic-inbox URL.
Add a command to piem-dispatch that provides similar functionality.
Message-Id: <20210207075738.8752-3-kyle@kyleam.com>
|
|
There are two spots that use (piem-inbox-get :url ...) and
piem-escape-mid to construct the public-inbox link, and there is about
to be another. Extract this shared logic.
Cc: Xinglu Chen <public@yoctocell.xyz>
Message-Id: <20210207075738.8752-2-kyle@kyleam.com>
|
|
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".
|
|
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>
|
|
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.
|
|
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>
|
|
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>
|
|
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>
|
|
|
|
|
|
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>
|
|
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>
|
|
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.
|
|
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>
|
|
This will gain another condition. Avoid repeating it across two
spots.
Message-Id: <20201122204609.12604-3-kyle@kyleam.com>
|
|
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>
|
|
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>
|
|
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>
|
|
This will be needed in another spot.
Message-Id: <20201115061518.22191-3-kyle@kyleam.com>
|
|
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>
|