| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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.
|
|
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".
|
|
|
|
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.
|
|
All downstream code expects unescaped message IDs.
Message-Id: <20200919044639.26871-3-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).
|
|
Using the second group in piem-link-re is not reliable because the
trailing part of the URL may be anything. Instead get the inboxes
:url first and then generate a regular expression that has that value
as the prefix.
Message-Id: <20200828031920.7515-5-kyle@kyleam.com>
|
|
piem-elfeed-get-inbox and piem-eww-get-inbox match the URL against
piem-link-re and take the second group as the inbox name. That's a
bad approach because the inbox name in the URL doesn't necessarily
match the one in piem-inboxes. For example, public-inbox's own
archive is https://public-inbox.org/meta/, but my entry in
piem-inboxes uses the name "public-inbox":
("public-inbox" :url "https://public-inbox.org/meta/" ...)
The approach also fails if the URL isn't a public-inbox message URL
because piem-link-re isn't very specific. (That will be improved in
an upcoming commit.)
Find the inbox name by matching the buffer URL against the :url values
in piem-inboxes.
Message-Id: <20200828031920.7515-2-kyle@kyleam.com>
|
|
|
|
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.
|
|
|