aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-10-25lei: Introduce option to set "lei" executableKyle Meyer
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>
2021-10-25piem-lei-known-mid-p: Use with-output-to-stringKyle Meyer
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>
2021-10-25piem-lei-query-show: Fix capitalization in error messageKyle Meyer
Message-Id: <20211025035630.297598-2-kyle@kyleam.com>
2021-10-25piem-notmuch-known-mid-p: Drop call to with-current-bufferKyle Meyer
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>
2021-10-24lei: Prefer "mid:" to "m:"Kyle Meyer
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>
2021-10-23piem-notmuch-known-mid-p: AutoloadKyle Meyer
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>
2021-09-23b4-am: Fill in more optionsKyle Meyer
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>
2021-09-22Prefer mail-decode-encoded-word-string to rfc2047-decode-stringKyle Meyer
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>
2021-06-11Support reading inboxes from ~/.public-inbox/configKyle Meyer
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>
2021-06-11piem-inboxes: Clarify that :coderepo points to a working treeKyle Meyer
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>
2021-06-11piem-inbox-coderepo*: Always return coderepo as a directoryKyle Meyer
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>
2021-06-11piem-inbox-coderepo-maybe-read: Avoid confusing "inbox" referencesKyle Meyer
piem-inbox-coderepo-maybe-read deals with a code repository but confusingly calls it "inbox". Message-Id: <20210610185943.14155-2-kyle@kyleam.com>
2021-06-10piem-b4-am: Specify :man-pageKyle Meyer
2021-06-10piem-lei-query-mode: Highlight current lineKyle Meyer
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>
2021-06-10Add a very incomplete to-do listKyle Meyer
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>
2021-06-09manual: Avoid space between link and closing parenthesisKyle Meyer
2021-06-08piem-inboxes: Fix typo in commentKyle Meyer
2021-06-07Merge branch 'km/initial-lei-support'Kyle Meyer
2021-06-07piem-lei-query-thread: Use piem-lei-get-mid to get message IDKyle Meyer
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>
2021-06-07lei: Wire up piem.el hooksKyle Meyer
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>
2021-06-07lei: Configure bindings for query and show modesKyle Meyer
Message-Id: <20210605211402.20304-17-kyle@kyleam.com>
2021-06-07lei query: Add commands for showing or scrolling message bufferKyle Meyer
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>
2021-06-07piem-lei-show: Record message IDKyle Meyer
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>
2021-06-07lei query: Add next/previous line variants that update message bufferKyle Meyer
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>
2021-06-07piem-lei-query-thread: Add bug#NNN special case when eliding subjectKyle Meyer
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>
2021-06-07piem-lei-query-thread: Omit main part of subject if sharedKyle Meyer
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>
2021-06-07piem-lei-query-thread: Deal with multiple "re:"sKyle Meyer
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>
2021-06-07piem-lei-query-thread: Drop repeated subjectsKyle Meyer
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>
2021-06-07piem-lei-query-thread: Position point on seed messageKyle Meyer
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>
2021-06-07lei query: Fontify resultsKyle Meyer
Message-Id: <20210605211402.20304-8-kyle@kyleam.com>
2021-06-07lei: Add command for viewing a threadKyle Meyer
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>
2021-06-07lei query: Add piem-lei-show wrapper for displaying line's messageKyle Meyer
Message-Id: <20210605211402.20304-6-kyle@kyleam.com>
2021-06-07lei: Add command and mode for displaying overview of search resultsKyle Meyer
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>
2021-06-07piem-lei-show: Highlight headers and quoted textKyle Meyer
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>
2021-06-07piem-lei-show: Let caller suppress displaying bufferKyle Meyer
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>
2021-06-07lei: Add command and mode for displaying a messageKyle Meyer
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>
2021-05-31piem.el: Drop an empty lineKyle Meyer
2021-05-27Add basic integration for RmailKyle Meyer
Teach piem how to get the associated inbox and message ID for the current Rmail message. Message-Id: <20210527232714.8726-1-kyle@kyleam.com>
2021-05-24b4: Better describe how piem-b4-am-ready-from-mid gets the threadKyle Meyer
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>
2021-05-23piem-gunzip-buffer: Don't assume t.mbox.gz is being decompressedKyle Meyer
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>
2021-05-23piem-gunzip-buffer: Absorb caching of gunzip checkKyle Meyer
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>
2021-05-23piem-gunzip-buffer: Check for gunzip executableKyle Meyer
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>
2021-05-23Rework url-retrieve-synchronously wrapperKyle Meyer
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>
2021-05-23b4: Check for message ID match when using current buffer's URLKyle Meyer
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>
2021-05-23piem-use-magit: Unconditionally set to tKyle Meyer
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>
2021-05-23piem-use-magit: Reword docstring to clarify scopeKyle Meyer
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>
2021-03-12piem: Add :maildir keyword to piem-inboxesXinglu Chen
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>
2021-02-24Release version 0.2.0v0.2.0Kyle Meyer
2021-02-24manual: Move under Documentation/Kyle Meyer
2021-02-22Require Transient 0.3.0Kyle Meyer
Transient 0.3.0 was just released. Require it, and stop using now obsolete macros. Message-Id: <20210222034807.23437-1-kyle@kyleam.com>