| Age | Commit message (Collapse) | Author |
|---|
|
Embarrassingly, I forgot to do this in b8eec6b9.
|
|
|
|
|
|
|
|
In 29834774 (piem-use-magit: Unconditionally set to t, 2021-05-23),
the initial sentence that actually referenced the variable name was
dropped, leaving the downstream text to confusingly talk about a
variable that was never named.
|
|
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.
|
|
|
|
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>
|
|
|
|
Teach piem how to get the associated inbox and message ID for the
current Rmail message.
Message-Id: <20210527232714.8726-1-kyle@kyleam.com>
|
|
piem-b4-am-ready-from-mid's docstring doesn't mention that it tries to
download the thread from a piem-inboxes URL before falling back to
letting b4 handle the download. The manual's description is better,
though it makes it sound like the b4 fallback depends on not finding a
URL in piem-inboxes rather than the download being unsuccessful for
whatever reason. Reword the docstring and manual text to hopefully
make things clearer.
Message-Id: <20210524005040.12668-1-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>
|
|
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>
|
|
|
|
|