Age | Commit message (Collapse) | Author |
|
Silence this warning:
defcustom for ‘piem-notmuch-mode’
fails to specify containing group
(I'm not sure why, but I don't see this when I run `make compile'.)
Reported-by: Jonas Bernoulli <jonas@bernoul.li>
|
|
The more interesting things will involve more work and setup to test,
but at least start testing some simple things.
This project's Makefile was originally based off of Elfeed's, and the
changes from this commit are adapted from there as well.
Message-Id: <20210123044300.31326-1-kyle@kyleam.com>
|
|
Xinglu Chen taught piem-gnus how to generate an am-ready mbox for an
entire thread in c9228b9 (gnus: Add piem-gnus-mid-to-thread,
2021-01-20).
Message-Id: <20210123023338.12211-1-kyle@kyleam.com>
|
|
Inserts a string of the whole thread in mbox format.
Message-Id: <796fb84d852f2a5adea1502db144dae1bdc4fe0c.1611132172.git.public@yoctocell.xyz>
|
|
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-notmuch-am-ready-mbox tries to get attached patches from the
plist returned by notmuch-show-get-message-properties. This works
okay for simple cases, but it doesn't find a patch if the content is
encoded or if the MIME tree isn't structured as expected. Instead use
mm-decode functions to get a list of handles and display their
content.
This new approach, as well as the previous one, probably isn't
compatible with `format-patch --attach' patches, but I'm not going to
worry about that until I actually see such a patch in the wild.
Message-Id: <20210104015435.18397-3-kyle@kyleam.com>
|
|
Message-Id: <20210104015435.18397-2-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>
|
|
|
|
|
|
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>
|