| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Message-ID: <20230610095858.26982-5-jlicht@fsfe.org>
|
|
Message-ID: <20230610095858.26982-4-jlicht@fsfe.org>
|
|
With the `:gnu-package` keyword, users can configure a string to match
against the X-GNU-PR-PACKAGE email header for the GNU Bug Tracker.
Message-ID: <20230610095858.26982-2-jlicht@fsfe.org>
|
|
The piem-inboxes documentation says that the :url value must end in a
slash, which is confusing because 1) public-inbox does not require
this and has examples in its docs without a slash and 2) some spots in
piem already append a slash if needed.
Add a piem-inbox-get wrapper that ensures the returned URL ends with a
slash, and use it in all spots that retrieve an inbox's URL.
Reported-by: Jelle Licht <jlicht@fsfe.org>
Link: https://inbox.kyleam.com/piem/87y1l9ualg.fsf@fsfe.org
Message-ID: <20230603041100.200632-1-kyle@kyleam.com>
|
|
piem-inbox-by-header-match is used by functions like
piem-notmuch-get-inbox and piem-gnus-get-inbox, which are wired up to
piem-get-inbox-functions not piem-get-mid-functions.
|
|
The two previous commits updated the piem-add-message-id-header
functionality for git.git's change from Message-Id to Message-ID.
Updates a couple of remaining spots to use Message-ID for consistency.
Message-ID: <20230430221552.251335-5-kyle@kyleam.com>
|
|
format-patch switch to using "Message-ID" instead of "Message-Id" in
git.git's ba4324c4e1 (e-mail workflow: Message-ID is spelled with ID
in both capital letters, 2023-04-03). Update
piem--insert-message-id-header to follow Git's change.
Message-ID: <20230430221552.251335-4-kyle@kyleam.com>
|
|
As of git.git's ba4324c4e1 (e-mail workflow: Message-ID is spelled
with ID in both capital letters, 2023-04-03), git-format-patch inserts
a Message-ID header instead of Message-Id. Teach
piem--insert-message-id-header to look for either variant when it
checks for an existing header.
Another option would be to ignore the header case entirely. However,
piem--insert-message-id-header is intended to work only for
format-patch output, so stick with the stricter header matching.
Message-ID: <20230430221552.251335-3-kyle@kyleam.com>
|
|
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>
|
|
Most of the user-facing documentation says "Message-Id" to match the
form that git-format-patch and git-am use. Do the same in
piem--write-mbox-to-maildir's error message.
|
|
piem-inject-thread-into-maildir expects to be able to determine the
inbox by calling piem-inbox. That's fine for interactive use, but
wrapper functions may want to determine the inbox in another way.
Suggested-by: zimoun <zimon.toutoune@gmail.com>
Link: https://yhetil.org/guix-devel/86sfpo5q8w.fsf@gmail.com
Message-Id: <20220516032241.212199-1-kyle@kyleam.com>
|
|
An inbox may regularly receive patches for multiple repos. Allow an
inbox's :coderepo to be a list, and teach piem-inbox-coderepo to
select a target repo by prompting the caller with the configured list.
Message-Id: <20220506014017.14259-1-kyle@kyleam.com>
|
|
|
|
Embarrassingly, I forgot to do this in b8eec6b9.
|
|
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.
|
|
piem-am-read-worktree isn't a good name because it doesn't provide any
information to distinguish this function from any other function used
for piem-am-read-worktree-function.
Message-Id: <20211229235036.372313-2-kyle@kyleam.com>
|
|
piem-edit stores the format returned by piem-am-ready-mbox in a
buffer-local variable, piem-edit-patch--format. However,
piem-edit-patch-am doesn't use this value when it calls piem-am,
instead passing a hard-coded "mbox".
Pass piem-edit-patch--format so that git-am is called with the
appropriate format.
Cc: Leo <sourcehut@relevant-information.com>
Message-Id: <20211228170417.216825-1-kyle@kyleam.com>
|
|
Sometimes it is necessary to edit patches before applying them. These changes
allows you to do that by providing a new command `piem-edit` that
shows the buffer that is prepared by `piem-am-ready-mbox` to the user.
[km] Fixed let-binding in piem-edit-patch-am.
Message-Id: <20211221140212.30248-1-sourcehut@relevant-information.com>
|
|
piem--merge-config-inboxes determines public-inbox's configuration
file by using PI_CONFIG if set, falling back to the hardcoded
location. piem-lei.el will need to do the same, so move the logic
into a function.
Message-Id: <20211025035630.297598-9-kyle@kyleam.com>
|
|
Expose (most if not all) relevant arguments of lei-q in a new
transient. The only somewhat tricky part here is propagating the
original arguments so that piem-lei-query-thread and
piem-lei-query-show can find messages that require a non-default
source (e.g., an unregistered external or a remote source when there
are local externals configured).
While remote operations work, the current design is still focused on a
setup where externals are configured locally, as described in
<20210605211402.20304-1-kyle@kyleam.com> (e.g., there's no attempt to
limit the number of times the server is hit).
Using the key 's' (for search) is unfortunate given the
command name is `lei q', but I think that's better than using 'q',
which is pretty widely used for "quit" in Emacs buffers.
Message-Id: <20211025035630.297598-7-kyle@kyleam.com>
|
|
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>
|
|
A client may mirror and configure inboxes locally. Doing so enables
fast local access to public-inbox-httpd and public-inbox-nntpd. And
with the next pubic-inbox release (v1.7), it will be necessary to set
up local externals for lei.
That can lead to a good amount of information being duplicated between
the piem-inboxes option and ~/.public-inbox/config. To avoid this,
let users set an option to enable collecting information from
public-inbox's configuration.
This relies on code getting the list of inboxes with
piem-merged-inboxes rather than inspecting piem-inboxes directly.
That should be okay because at this point there should be very few
third-party callers. An alternative would be to merge values from the
configuration into the value of piem-inboxes. That'd let callers
continue to inspect public-inboxes, but I'd prefer not to touch the
value of a user option.
Message-Id: <20210610185943.14155-5-kyle@kyleam.com>
|
|
The properties of piem-inboxes align with public-inbox-config names to
keep things consistent, which is especially important given the
upcoming support of reading inboxes from public-inbox's configuration.
However, :coderepo, which needs to point to a working tree, doesn't
nicely match publicinbox.$inbox.coderepo, which points to another
section that in turn must point to a .git directory.
I'm still undecided on whether using a different name (e.g.,
:code-working-tree) would be clearer, but at least document the
difference to hopefully avoid some confusion.
Message-Id: <20210610185943.14155-4-kyle@kyleam.com>
|
|
A coderepo is by definition a directory. Append a trailing separator
so that callers don't have to worry about normalizing it.
Message-Id: <20210610185943.14155-3-kyle@kyleam.com>
|
|
piem-inbox-coderepo-maybe-read deals with a code repository but
confusingly calls it "inbox".
Message-Id: <20210610185943.14155-2-kyle@kyleam.com>
|
|
|
|
|
|
If the gunzip call fails, piem-gunzip-buffer says "Decompressing
t.mbox.gz failed". All the piem-gunzip-buffer callers at the moment
do use to decompress t.mbox.gz downloads, but that's of course not
something this function should assume or know about.
Message-Id: <20210523214623.31331-6-kyle@kyleam.com>
|
|
Now that piem-gunzip-buffer handles the check for the gunzip
executable, there's not much point in having a dedicated function.
Message-Id: <20210523214623.31331-5-kyle@kyleam.com>
|
|
Make piem-gunzip-buffer handle the executable check so that callers
don't have to worry about it.
Message-Id: <20210523214623.31331-4-kyle@kyleam.com>
|
|
piem-download-and-decompress calls url-retrieve-synchronously, checks
for a 200 status, and then manually removes the header. This works
okay, but it'd be good for the error handling to match what's done by
url-insert-file-contents.
Introduce a new macro that largely copies what is done by
url-insert-file-contents. The main difference is that url-insert is
used instead of url-insert-buffer-contents so that the contents can be
inserted literally.
This approach is based on Emacs's 5f9671e57e
(lisp/emacs-lisp/package.el: Fix decoding of downloaded files,
2019-05-18).
Message-Id: <20210523214623.31331-3-kyle@kyleam.com>
|
|
When piem is loaded, piem-use-magit is enabled if Magit has already
been loaded. This approach is potentially confusing: a user may want
to use Magit, be happy that it seems to just work, and then confused
when it doesn't work in some later session where loading Magit happens
to not be triggered before loading piem.
All the relevant sites have fboundp guards (and those are cheap), so
there's no advantage to disabling this if Magit isn't enabled at load
time. Set piem-use-magit to t by default.
Message-Id: <20210522203905.16504-3-kyle@kyleam.com>
|
|
This option isn't really about using Magit wherever possible, but, as
the manual already states, using Magit for some user-facing
operations.
Message-Id: <20210522203905.16504-2-kyle@kyleam.com>
|
|
Previously the user was able to configure a maildir to inject threads
into, but the user might want the maildir to be different depending
on which mailing list the threads was coming from.
With the `:maildir` keyword, users can configure the maildir on a
per-list basis. If there is not `:maildir` configured for a mailing
list, it will fallback to the value of `piem-maildir-directory`.
Message-Id: <702dccedfc5e67a41bb0dd58fe66af6e3f204bb5.1615568004.git.public@yoctocell.xyz>
|
|
|
|
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>
|
|
|
|
|