Age | Commit message (Collapse) | Author |
|
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.
|
|
This will be used to feed git-am the buffer returned by
piem-am-ready-mbox.
|
|
This will enable libraries to provide an mbox that piem-am can use.
|
|
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.
|
|
This logic will be used in another spot.
|
|
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.
|
|
|
|
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.
|
|
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.
|
|
The end goal is to turn piem-am into a command that can work with
patches extracted from the current buffer. Pull out the logic that
can be reused for this.
|
|
It messes with my comment heading navigation, and it's readable enough
when packed into a single line.
|
|
|
|
Directing all piem-related output to one buffer should be sufficient,
for now at least.
|
|
These are things that will be used outside of piem-b4.
|
|
I just mindlessly added this, but I don't see any advantage of using a
separate variable rather than notmuch-command. And if the option were
to stay, it should default to notmuch-command.
Drop the piem-notmuch defgroup as well, since there are now no
options.
|
|
|
|
|
|
Conceptually these are under ";;; Code", so add a ";" to reflect that.
|
|
|
|
|
|
This is my attempt to follow Chris Wellons's recommendations [*]. I'm
not sure how successful it is, but GNU make and bmake (from Debian)
seem happy.
[*] https://nullprogram.com/blog/2017/08/20/
https://nullprogram.com/blog/2020/01/22/
|
|
|
|
The pattern rule creates an autoload file for each .el, which isn't
very useful in the context of a multi-file package. Replace that with
a rule that creates a single autoloads file. Instead of calling
update-directory-autoloads directly use package.el, letting it worry
about setting the appropriate variables.
|
|
|
|
There's no need to autoload the non-interactive functions.
|
|
|
|
This option was added in b4 v0.4.1.
|
|
|
|
The links in Elfeed entries only need the restricted variant, but the
extended one will be useful for EWW support.
|
|
There's not much point in having repeated comments across endpoints
that note the fallback behavior in general. Shorten the comment in
-gnus to just note that it'd be nice to have a Gnus variant. Assuming
the messages are present locally, that'd be better than downloading
the mbox from a public-inbox instance.
|
|
elfeed.el doesn't load elfeed-show at compile time.
|
|
|
|
|
|
|
|
alist-get uses eq as the default test function, so it was only working
by chance. Rather than calling alist-get with three additional
arguments in order to specify TESTFN, switch to assoc.
|
|
|
|
Implement message ID and inbox getters. As noted in the comment,
leave the mid->thread functionality undefined for now, because I don't
know if there's a good way to do that in Gnus.
These functions should probably learn how to work from
gnus-summary-mode too, but leave that for later. (Similarly, -notmuch
should also probably support notmuch-{search,tree}-mode in addition to
notmuch-show-mode.)
|
|
This will be used in the upcoming piem-gnus.el as well.
|
|
The function for generating the default branch name may need to be
tweaked to give useful suggestions in practice. Let's see.
|
|
When passing a name like "a.mbx" to b4-am's --mbox-name, only the "a"
is retained; b4-am unconditionally appends the ".mbx". Avoid passing
a name with ".mbx" to make it clearer that the caller does not control
the extension.
Reduce the base name to "m" to avoid a message ID ending with ".*"
being treated as an extension, which would require analyzing the
message ID in order to guess what output name b4-am will use.
Finally, name the custom thread mbox with "-piem" rather than
"-thread" (which was chosen to mimic b4-mbox) so it's more obvious who
created the file when later inspecting the directory.
|
|
The subprocess handling needs reworked and polished, so this helper
likely won't stay around in its current form for long, but it's still
useful to send git through it so that a failure signals an error and
shows the output.
|
|
message-narrow-to-headers-or-head will narrow to the message headers
based on hitting two consecutive new lines or based on a match for
mail-header-separator (by default "--text follows this line--"). Only
the former condition is relevant in the context of a non-draft
message, so use message-narrow-to-headers, which doesn't consider
mail-header-separator.
|
|
|
|
|
|
My main motivation for this move is that it works well with Guix
environments. And outside of that context, it doesn't seem like it'd
be any more of a hassle to set EMACSLOADPATH rather than individual
variables like TRANSIENT_DIR in config.mk.
|
|
Aside from switching the 'b4 am' process to an asynchronous one, the
am-ready commands may not need a lot of work. The more interesting
variant, piem-b4-am-from-mid, can find an associated code repository
and am the patch, but there's a lot that needs to be fleshed out.
|
|
This does nothing useful, but the idea is that it never will do much
of anything on its own. Different libraries---piem-notmuch,
piem-elfeed, piem-gnus, and so on---will populate its hooks, teaching
it how to extract information.
|
|
|
|
|