Age | Commit message (Collapse) | Author |
|
piem-lei-query presents a message-based overview. In many cases the
caller will want to use that search result as a seed for finding the
associated thread. Add a command that construct thread for a given
message.
The threading algorithm is based on public-inbox's. Some details may
have been lost in translation, but I haven't spotted any differences
yet when doing side-by-side comparisons of output from
piem-lei-query-thread and public-inbox's web interface. And testing
with a few ~100-message threads, the performance seems to be okay.
The appearance also follows public-inbox's, which I like.
Message-Id: <20210605211402.20304-7-kyle@kyleam.com>
|
|
This command is a simple wrapper around `lei q --format=text m:MID',
letting lei handle the details. Things will eventually need to get
more complicated (e.g., attachment handling, signatures, replies), but
this should do for now.
Message-Id: <20210605211402.20304-2-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>
|
|
|
|
The more interesting things will involve more work and setup to test,
but at least start testing some simple things.
This project's Makefile was originally based off of Elfeed's, and the
changes from this commit are adapted from there as well.
Message-Id: <20210123044300.31326-1-kyle@kyleam.com>
|
|
|
|
|
|
|
|
By default the HTML dir link points to /dir/index.html, which doesn't
exist in the case of docs.kyleam.com. Point docs.kyleam.com/ instead.
|
|
|
|
I follow some public-inbox-archived projects over NNTP with Gnus.
However, once I get involved in a thread, I usually want the entire
thread in my local mail/Notmuch database (or at least the message I'm
replying to).
With this new command, if I see a message in Gnus (or EWW or Elfeed)
that I want to reply to, I can get it into Notmuch, assuming
piem-inboxes and piem-maildir-directory are wired up. And through
piem-after-mail-injection-functions, it's possible to jump straight to
the message with notmuch-show.
|
|
These will be used for writing messages from a public-inbox t.mbox.gz
into a Maildir directory.
|
|
|
|
This is my attempt to follow Chris Wellons's recommendations [*]. I'm
not sure how successful it is, but GNU make and bmake (from Debian)
seem happy.
[*] https://nullprogram.com/blog/2017/08/20/
https://nullprogram.com/blog/2020/01/22/
|
|
|
|
The pattern rule creates an autoload file for each .el, which isn't
very useful in the context of a multi-file package. Replace that with
a rule that creates a single autoloads file. Instead of calling
update-directory-autoloads directly use package.el, letting it worry
about setting the appropriate variables.
|
|
|
|
|
|
|
|
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.)
|
|
|
|
My main motivation for this move is that it works well with Guix
environments. And outside of that context, it doesn't seem like it'd
be any more of a hassle to set EMACSLOADPATH rather than individual
variables like TRANSIENT_DIR in config.mk.
|
|
Aside from switching the 'b4 am' process to an asynchronous one, the
am-ready commands may not need a lot of work. The more interesting
variant, piem-b4-am-from-mid, can find an associated code repository
and am the patch, but there's a lot that needs to be fleshed out.
|
|
This does nothing useful, but the idea is that it never will do much
of anything on its own. Different libraries---piem-notmuch,
piem-elfeed, piem-gnus, and so on---will populate its hooks, teaching
it how to extract information.
|
|
|