| 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>
|