Age | Commit message (Collapse) | Author |
|
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.
|
|
|