Age | Commit message (Collapse) | Author |
|
It looks like all other spots that aren't specifically referring to
the header use "message ID".
|
|
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>
|
|
Message-Id: <20201122204609.12604-4-kyle@kyleam.com>
|
|
This will gain another condition. Avoid repeating it across two
spots.
Message-Id: <20201122204609.12604-3-kyle@kyleam.com>
|
|
Message-Id: <20201122204609.12604-2-kyle@kyleam.com>
|
|
|
|
Message-Id: <20201115061518.22191-7-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>
|
|
b4 is available upstream as of 3b77ba78684.
Ref: https://yhetil.org/guix-patches/20201114003906.25111-1-kyle@kyleam.com
Message-Id: <20201115210445.7892-1-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>
|
|
As of 30defdb (b4: Clean up temporary directories by default,
2020-09-27), piem-b4-am-from-mid is supposed to clean up its temporary
directory unless piem-b4-keep-temp-directory is non-nil. That commit,
however, missed an error case where the cleanup function needs to be
triggered.
Message-Id: <20201025192111.27439-1-kyle@kyleam.com>
|
|
|
|
Each piem-b4-am-from-mid call works in a new temporary directory.
Aside from debugging, there's no reason to keep these directories
around, polluting temporary-file-directory.
Message-Id: <20200927061446.2301-1-kyle@kyleam.com>
|
|
|
|
|
|
By default the HTML dir link points to /dir/index.html, which doesn't
exist in the case of docs.kyleam.com. Point docs.kyleam.com/ instead.
|
|
Message-Id: <20200921045801.24501-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>
|
|
1000739 (Unescape message IDs extracted from URLs, 2020-09-19)
incorrectly/embarrassingly used the variable name from
piem-eww-get-mid.
|
|
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>
|
|
All downstream code expects unescaped message IDs.
Message-Id: <20200919044639.26871-3-kyle@kyleam.com>
|
|
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>
|
|
When 05f3ca5 (manual: A rough and incomplete start, 2020-08-25)
fleshed out the skeleton a bit, the individual nodes for the
integration libraries got dropped and the one for b4 got renamed.
|
|
|
|
|
|
I haven't decided how I want to deal with packaging, but in any case
there's no point in having a version heading for each library. Keep
the one in piem.el since there's no *-pkg.el file (at this point, at
least).
|
|
Avoid presenting the two am-ready variants as though they are early
stopping variants of piem-b4-am-from-mid. That's inaccurate, as they
don't go through any of the handling in piem-b4--get-am-files and are
meant to map directly to `b4 am [options] MID' and `b4 am [options]
--use-local-mbox=FILE'.
Also expand piem-b4-am-from-mid's description, hopefully providing a
better picture of what it's doing on top of a plain `b4 am' call.
Message-Id: <20200901032239.25361-1-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.
|