| Age | Commit message (Collapse) | Author |
|---|
|
In addition to suppressing identical subjects (after stripping "re:"),
public-inbox's web interface will compare the current line's subject
with the previous line's, and cut off the shared tail:
[PATCH] Add basic integration for Rmail
` <suppressed completely>
` [PATCH v2] " <-- here
` <suppressed completely>
I think the above is helpful. However, in some cases, I find the
presentation more confusing than helpful:
[PATCH 0/3] notmuch: Improve handling of attached patches
` [PATCH 1/3] piem-notmuch--with-current-message: Declare debug and indent specs
` [PATCH 2/3] piem-notmuch-am-ready-mbox: Improve handling of attachments
` <suppressed completely>
` [PATCH v2 0/3] notmuch: Improve handling of attached patches
` [PATCH v2 1/3] piem-notmuch--with-current-message: Declare debug and indent specs
` [PATCH v2 2/3] piem-notmuch-am-ready-mbox: Improve handling of attachments
` [PATCH v2 3/3] gnus, notmuch: Absorb now-shared bits into patch attachment helper
` [PATCH "
It takes me a second to figure out what the omitted bits in the last
line's subject are. I'm not sure, but I think the subject truncation
that I find clear is where the omitted text is the main subject after
a bracketed tag (i.e. "[tag] main"), not more or less.
Teach piem-lei-query-thread to split the subject into a "prefix" (some
number of "[tag]" items) and a "main" part (everything else), and
elide a line's main part if it matches the previous line's. In the
above example, the last line would be
` [PATCH 3/3] …
Message-Id: <20210605211402.20304-12-kyle@kyleam.com>
|
|
piem-lei-query-thread strips a message's subject of "re: " before
checking matches the previous line's subject and should be dropped.
"re: re: <subjects>" unfortunately don't seem uncommon, so strip
multiple "re:"s.
Message-Id: <20210605211402.20304-11-kyle@kyleam.com>
|
|
public-inbox's web interface suppresses a message's subject when it
matches the previous lines [*]. Teach piem-lei-query-thread to do the
same to make it easier to spot subject shifts and identify subthreads.
[*] notmuch-tree-mode does similar, displaying "..." instead.
Message-Id: <20210605211402.20304-10-kyle@kyleam.com>
|
|
It seems likely that the caller wants to start digesting the thread in
the context of the seed message, and that message may be part of a
large thread. Move point to help orient the caller.
Notmuch nicely distinguishes search hits from other messages when
displaying a thread. Something along those lines is worth considering
eventually.
Message-Id: <20210605211402.20304-9-kyle@kyleam.com>
|
|
Message-Id: <20210605211402.20304-8-kyle@kyleam.com>
|
|
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>
|
|
Message-Id: <20210605211402.20304-6-kyle@kyleam.com>
|
|
The output is intended to resemble search in public-inbox's web
interface: an entry for each matching message. This is different from
notmuch-search's output in that results are not grouped in their
thread. I like notmuch's interface, although I'm not sure that trying
to reshape lei-q's JSON output into something like that is worth the
code complication or computation cost.
The plan is to eventually wire this up to a transient to allow the
caller to specify arguments (e.g., --only to restrict the search
results to a particular inbox).
Message-Id: <20210605211402.20304-5-kyle@kyleam.com>
|
|
Piggyback off of message-* faces to hopefully fit in nicely with
themes and expectations. Leave other highlighting (e.g., of diffs),
until later.
Message-Id: <20210605211402.20304-4-kyle@kyleam.com>
|
|
piem-lei-show switches to the message buffer with pop-to-buffer, but
that behavior won't work well in the context of a mode that gives an
overview of lei-q search results. In that case, a wrapper command
will want to control the display of the buffer so that it can keep a
split window layout and avoid switching to the piem-lei-show-mode
buffer.
And more generally, Lisp callers are likely to want to handle the
display themselves. Add an optional 'display' parameter that defaults
to nil for non-interactive calls.
Message-Id: <20210605211402.20304-3-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>
|
|
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>
|
|
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>
|
|
If piem-mid-to-thread-functions fails to generate the thread,
piem-b4--get-am-files tries to download the mbox from the URL
associated with the current buffer. However, it uses the message ID
returned by piem-mid rather than the message ID passed by
piem-b4-am-from-mid. That's not a safe assumption for non-interactive
calls to piem-b4-am-from-mid.
Construct the URL with the message ID passed by piem-b4-am-from-mid,
and skip the download completely if that message ID doesn't match the
one for the current buffer.
Message-Id: <20210523214623.31331-2-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.
|
|
|
|
Cc: Xinglu Chen <public@yoctocell.xyz>
Message-Id: <20210207075738.8752-6-kyle@kyleam.com>
|
|
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>
|
|
Message-Id: <20210206180630.3676-4-kyle@kyleam.com>
|
|
Message-Id: <20210206180630.3676-3-kyle@kyleam.com>
|
|
Cut off part of a sentence that adds no additional information, and
discard a footnote.
Message-Id: <20210206180630.3676-2-kyle@kyleam.com>
|
|
|
|
|
|
This adds an entry to `notmuch-show-stash-mlarchive-link-alist` that
reads the `piem-inboxes` variable and returns the public-inbox archive
url. This means that users don't have to manually add public-inbox
archive urls to `notmuch-show-stash-mlarchive-link-alist`.
[km: added explicit error when inbox not found and fixed a few typos]
Message-Id: <8e8677cde716973081232aa65a37fa2fc621b15f.1612600790.git.public@yoctocell.xyz>
|
|
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.
|
|
Silence this warning:
defcustom for ‘piem-notmuch-mode’
fails to specify containing group
(I'm not sure why, but I don't see this when I run `make compile'.)
Reported-by: Jonas Bernoulli <jonas@bernoul.li>
|
|
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>
|
|
Xinglu Chen taught piem-gnus how to generate an am-ready mbox for an
entire thread in c9228b9 (gnus: Add piem-gnus-mid-to-thread,
2021-01-20).
Message-Id: <20210123023338.12211-1-kyle@kyleam.com>
|
|
Inserts a string of the whole thread in mbox format.
Message-Id: <796fb84d852f2a5adea1502db144dae1bdc4fe0c.1611132172.git.public@yoctocell.xyz>
|
|
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-notmuch-am-ready-mbox tries to get attached patches from the
plist returned by notmuch-show-get-message-properties. This works
okay for simple cases, but it doesn't find a patch if the content is
encoded or if the MIME tree isn't structured as expected. Instead use
mm-decode functions to get a list of handles and display their
content.
This new approach, as well as the previous one, probably isn't
compatible with `format-patch --attach' patches, but I'm not going to
worry about that until I actually see such a patch in the wild.
Message-Id: <20210104015435.18397-3-kyle@kyleam.com>
|