| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The new name aligns more closely with the piem-lei-buffer-query and
piem-lei-buffer-args buffer-local variables introduced a few commits
back.
Message-Id: <20211025035630.297598-11-kyle@kyleam.com>
|
|
The --include option of lei-q enables searching external sources that
are not already registered, whether they are local inboxes or remote
URLs. --only also does this, along with restricting the results to
the specified sources. As such, registered inboxes make sense as
values for --only, in _addition_ to any values the make sense for
--include.
Message-Id: <20211025035630.297598-10-kyle@kyleam.com>
|
|
piem--merge-config-inboxes determines public-inbox's configuration
file by using PI_CONFIG if set, falling back to the hardcoded
location. piem-lei.el will need to do the same, so move the logic
into a function.
Message-Id: <20211025035630.297598-9-kyle@kyleam.com>
|
|
piem-lei-query sets piem-lei-buffer-query to the query it's called
with. Like piem-lei-query, piem-lei-query-thread produces a
piem-lei-query-mode buffer, but it doesn't set this variable.
Make piem-lei-query-thread do so for consistency (though I don't have
a concrete use in mind). And I guess piem-lei-show might as well set
this variable too.
Message-Id: <20211025035630.297598-8-kyle@kyleam.com>
|
|
Expose (most if not all) relevant arguments of lei-q in a new
transient. The only somewhat tricky part here is propagating the
original arguments so that piem-lei-query-thread and
piem-lei-query-show can find messages that require a non-default
source (e.g., an unregistered external or a remote source when there
are local externals configured).
While remote operations work, the current design is still focused on a
setup where externals are configured locally, as described in
<20210605211402.20304-1-kyle@kyleam.com> (e.g., there's no attempt to
limit the number of times the server is hit).
Using the key 's' (for search) is unfortunate given the
command name is `lei q', but I think that's better than using 'q',
which is pretty widely used for "quit" in Emacs buffers.
Message-Id: <20211025035630.297598-7-kyle@kyleam.com>
|
|
None of the current calls to lei should have a non-zero exit, even
when they come up empty.
Message-Id: <20211025035630.297598-6-kyle@kyleam.com>
|
|
This is a bit more readable, and it introduces a single spot where
error handling can be added.
Message-Id: <20211025035630.297598-5-kyle@kyleam.com>
|
|
There are -executable options for git and b4, so for consistency add
one for lei. And for things like Guix that prefer to expand
executables to a full path, this makes it easier because there's just
one spot to patch.
Message-Id: <20211025035630.297598-4-kyle@kyleam.com>
|
|
piem-lei-known-mid-p does essentially the same thing as
piem-notmuch-known-mid-p, so collect output in a consistent way.
Message-Id: <20211025035630.297598-3-kyle@kyleam.com>
|
|
Message-Id: <20211025035630.297598-2-kyle@kyleam.com>
|
|
There's no need to switch to the standard-output buffer because it can
be passed as a destination for call-process.
I go back and forth on whether I prefer (with-output-to-string ...) to
(with-temp-buffer ... (buffer-string)), but the main thing I like
about with-output-to-string is that the intention of the code is
declared at the start.
Message-Id: <20211025035505.297281-1-kyle@kyleam.com>
|
|
The "m:" prefix is probabilistic and can do partial matches, whereas
"mid:" is boolean (see lib/PublicInbox/Search.pm). When "m:" is used
in lei, the intention is to get the one and only, so switch to using
"mid:".
Message-Id: <20211023205712.202126-1-kyle@kyleam.com>
|
|
Allow users to set piem-mail-injection-skipif-predicate to
piem-notmuch-known-mid-p without worrying about whether
piem-notmuch.el is loaded.
Message-Id: <20211023171651.167143-1-kyle@kyleam.com>
|
|
Catch up with some new options and add some older ones that I punted
on earlier. This should cover everything that's in b4 v0.8, hiding
things that are a bit too lore-specific or tailored to command-line
operation.
Message-Id: <20210923023511.269242-1-kyle@kyleam.com>
|
|
mail-parse.el defines mail-decode-encoded-word-string as an alias for
rfc2047-decode-string. Use the higher-level wrapper for the reasons
described in (emacs-mime)Interface.
Message-Id: <20210923012353.256964-1-kyle@kyleam.com>
|
|
A client may mirror and configure inboxes locally. Doing so enables
fast local access to public-inbox-httpd and public-inbox-nntpd. And
with the next pubic-inbox release (v1.7), it will be necessary to set
up local externals for lei.
That can lead to a good amount of information being duplicated between
the piem-inboxes option and ~/.public-inbox/config. To avoid this,
let users set an option to enable collecting information from
public-inbox's configuration.
This relies on code getting the list of inboxes with
piem-merged-inboxes rather than inspecting piem-inboxes directly.
That should be okay because at this point there should be very few
third-party callers. An alternative would be to merge values from the
configuration into the value of piem-inboxes. That'd let callers
continue to inspect public-inboxes, but I'd prefer not to touch the
value of a user option.
Message-Id: <20210610185943.14155-5-kyle@kyleam.com>
|
|
The properties of piem-inboxes align with public-inbox-config names to
keep things consistent, which is especially important given the
upcoming support of reading inboxes from public-inbox's configuration.
However, :coderepo, which needs to point to a working tree, doesn't
nicely match publicinbox.$inbox.coderepo, which points to another
section that in turn must point to a .git directory.
I'm still undecided on whether using a different name (e.g.,
:code-working-tree) would be clearer, but at least document the
difference to hopefully avoid some confusion.
Message-Id: <20210610185943.14155-4-kyle@kyleam.com>
|
|
A coderepo is by definition a directory. Append a trailing separator
so that callers don't have to worry about normalizing it.
Message-Id: <20210610185943.14155-3-kyle@kyleam.com>
|
|
piem-inbox-coderepo-maybe-read deals with a code repository but
confusingly calls it "inbox".
Message-Id: <20210610185943.14155-2-kyle@kyleam.com>
|
|
|
|
Make the current entry stand out more (and match the expectations of
notmuch.el and Elfeed users).
Message-Id: <20210611010335.10937-1-kyle@kyleam.com>
|
|
Transplant some items from my private to-do list to hopefully give
others a better sense for what's planned.
Message-Id: <20210611002040.4709-1-kyle@kyleam.com>
|
|
|
|
|
|
|
|
piem-lei-query-thread uses piem-lei-query-get-mid to get the message
ID for interactive calls. Switch to piem-lei-get-mid, which uses
piem-lei-query-get-mid underneath, so that the message ID can also be
extracted from piem-lei-show-mode buffers.
Message-Id: <20210605211402.20304-19-kyle@kyleam.com>
|
|
piem-lei-show-mode and piem-lei-query-mode now have enough
functionality to implement all piem.el hooks except for
piem-am-ready-mbox-functions.
Message-Id: <20210605211402.20304-18-kyle@kyleam.com>
|
|
Message-Id: <20210605211402.20304-17-kyle@kyleam.com>
|
|
Start with direct wrappers around scroll-{up,down}-command, but it
might be worth making these circle around (like
magit-diff-show-or-scroll-{up,down} do) rather than signaling an error
at the beginning or end of the buffer.
Message-Id: <20210605211402.20304-16-kyle@kyleam.com>
|
|
This information will be needed for the "show or scroll" command, as
well as for integration with piem.el hooks.
Message-Id: <20210605211402.20304-15-kyle@kyleam.com>
|
|
Using next-line and previous-line directly is inconvenient for viewing
results because the associated message buffer needs to be manually
displayed even if a piem-lei-show-mode buffer is visible.
Add commands that 1) automatically call piem-lei-query-show and 2)
skip over ghost messages, because in that case there's nothing to
display or otherwise act on.
If the command is executed quickly, unconditionally showing the buffer
is wasteful and won't perform well, so something like
magit-update-other-window-delay should probably be added.
Message-Id: <20210605211402.20304-14-kyle@kyleam.com>
|
|
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-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>
|