| Age | Commit message (Collapse) | Author |
|---|
|
In debbugs threads, it's not uncommon for a leading "[bug#NNN]" in the
subject to be converted to "bug#NNN:" [*]. I'm not sure what the
source of this is, but it prevents the suppression of an otherwise
identical subject.
It's probably not worth normalizing before the comparison to get full
suppression, but it'd be nice to at least elide the main part of the
subject so it's more obvious that it didn't change. Add a special
case so that "bug#NNN:" prefix is treated the same as a bracketed
prefix.
[*] example:
https://yhetil.org/guix-patches/20201128051435.30580-1-kyle@kyleam.com
Message-Id: <20210605211402.20304-13-kyle@kyleam.com>
|
|
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 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>
|
|
Teach piem how to get the associated inbox and message ID for the
current Rmail message.
Message-Id: <20210527232714.8726-1-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>
|
|
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".
|
|
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>
|