| Age | Commit message (Collapse) | Author |
|---|
|
All of the *-am-ready-mbox functions expect inline patches to have a
'[... PATCH ...]' in the subject. In cases where a patch is sent
without that prefix, a piem-am caller gets an unhelpful "Could not
find am-ready mbox for current buffer" in response to
piem-am-ready-mbox returning nil.
To support these (hopefully rare) cases, drop the "has patch prefix?"
guard from all the *-am-ready-mbox functions. A caller is requesting
to extract a patch from the current buffer, and the "is the current
buffer in the right mode?" check should be sufficient for an
am-ready-mbox function to decide whether it should be responsible for
generating the mbox.
This added flexibility increases a caller's ability to apply invalid
patches. As with the previously possible cases, the output buffer
will give a clear error, but the caller will need to abort the git-am
sequence and clean up the branch. That seems reasonable given that,
in addition to the initial explicit request, an interactive piem-am
caller needs to "confirm" applying through the prompts, making it more
difficult to get to that state unintentionally.
Reported-by: Leo <git@relevant-information.com>
Link: https://inbox.kyleam.com/piem/87fry9hn9u.fsf@
Message-ID: <87ttmo57js.fsf@kyleam.com>
|
|
When using Gnus over NNTP, `gnus-summary-display-article' shows a
plain message, but when debbugs.el visits an issue message with Gnus,
it's already in mbox format.
Link: https://inbox.kyleam.com/piem/87cz2dun0y.fsf@kyleam.com
Message-ID: <20230610095858.26982-3-jlicht@fsfe.org>
|
|
When extracting patches from attachments, piem-gnus-am-ready-mbox and
piem-notmuch-am-ready-mbox construct the mbox messages in the same
order as the attachments. This depends on the sender attaching the
patches in ascending order.
Be a bit more helpful in situations where the sender attaches the
patches out of order by reordering patches according to the NNNN-
prefix that git-format-patch adds to the start of the patch file name.
This approach won't be able to reliably sort patches that aren't
generated by git-format-patch, but that's outside of any use case that
piem is intended to support.
Suggested-by: Ihor Radchenko <yantar92@gmail.com>
Link: https://inbox.kyleam.com/piem/87mtdj9dzt.fsf@localhost
Message-Id: <878rp2pyx1.fsf@kyleam.com>
|
|
The case doesn't matter; use lower case for consistency with other
spots.
|
|
public-inbox has started to drop dates from its copyright lines,
pointing to the recommendation at
https://www.linuxfoundation.org/blog/copyright-notices-in-open-source-software-projects/
I regularly fail to keep copyright lines up to date, so I'll gladly
follow suit.
While touching these lines, change "all contributors" to "all piem
contributors" to get a bit closer to the variants recommended in the
above article.
|
|
mail-parse.el defines mail-decode-encoded-word-string as an alias for
rfc2047-decode-string. Use the higher-level wrapper for the reasons
described in (emacs-mime)Interface.
Message-Id: <20210923012353.256964-1-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".
|
|
Inserts a string of the whole thread in mbox format.
Message-Id: <796fb84d852f2a5adea1502db144dae1bdc4fe0c.1611132172.git.public@yoctocell.xyz>
|
|
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>
|
|
|
|
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>
|
|
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.
|
|
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).
|
|
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>
|
|
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>
|
|
It makes sense for all of these functions to support gnus-summary-mode
because point is often in the summary buffer when reading a thread. I
punted on doing so initially because something probably should be done
to ensure that the gnus-article-* variables that these functions rely
on are up to date with the current line in the summary buffer.
I'm still not sure of the best way to do that (assuming it really is
an issue), but I think for common usage patterns the values won't be
stale (e.g., browsing with gnus-summary-next-page and
gnus-summary-next-unread-article), so simply relying on the current
values may be good enough.
|
|
|
|
As with the notmuch- counterpart added in the previous commit, I only
put this through very light testing, but it at least works in some
cases.
|
|
|
|
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.
|
|
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.)
|