| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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>
|
|
|