aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-12-28lei q: Support displaying multiple threadsKyle Meyer
piem-lei-query shows unthreaded results. From there, piem-lei-query-thread can be used to show the entire thread for that result. This design is driven largely by my use of Notmuch, where I call notmuch-search and then follow up with a custom variant of notmuch-tree to show _one_ thread. However, users familiar with notmuch-tree probably expect to be able to display _multiple_ threads. piem-lei-query--thread already returns a list of threads, so it really just needs to be exposed at the command level. Update piem-lei-query-thread to make it handle a general query, renaming it slightly to make it clearer that the command now supports displaying multiple threads. Then, add a wrapper piem-lei-mid-thread that handles the old "single thread for a given MID" behavior. Rather than adding another suffix command to the lei-q transient (piem-lei-query-threads in addition to the existing piem-lei-query), I considered adding --threads to the transient and then having piem-lei-query check whether it's in the arguments. Conceptually, I dislike that because it conflates threaded _display_ with lei's --threads behavior that's instead about whether to include other messages from a match's thread in the results. Also, it'd mean some downstream handling of piem-lei-buffer-args (e.g., by piem-lei-query-show) would be complicated by the need to filter out --threads. Note that piem-lei-query-thread no longer sets piem-lei-buffer-mid because the buffer is no longer tied to a single message ID, which is okay because, unlike in show buffers, the value isn't actually used. Suggested-by: Xinglu Chen <public@yoctocell.xyz> Link: https://inbox.kyleam.com/piem/871r96am1q.fsf@yoctocell.xyz Message-Id: <20211228022037.206597-4-kyle@kyleam.com>
2021-12-28lei q: Extract buffer names to variablesKyle Meyer
The next commit will split piem-lei-query-thread into two commands, one for general queries with threaded output and one for displaying a single thread for a given message ID. It makes sense to have different buffer names for these commands, and going forward it's likely that there will be more name tweaks (e.g., support for "locked" buffers). Add defvars that can be bound to control the names. Message-Id: <20211228022037.206597-3-kyle@kyleam.com>
2021-12-28lei q: Allow initial input for query to be customizedKyle Meyer
piem-lei-query reads with initial input of "d:20.days.ago.. ", which I find useful because this time restriction works well with what I'm most often searching for. (This is a value I've long used with Notmuch.) However, what value of "recent" is most reasonable is likely to vary across users, and some users may not want the restriction at all. Add an option so that the initial input can be easily configured. Message-Id: <20211228022037.206597-2-kyle@kyleam.com>
2021-12-26notmuch: Silence warning about "hidden" argumentKyle Meyer
Move an argument to its own line to avoid the warning from lisp-mode's lisp--match-hidden-arg. (And while touching that line, fix up the indentation of piem-notmuch--with-current-message's BODY.) Message-Id: <20211224213153.8115-1-kyle@kyleam.com>
2021-12-24Add ability to edit patches before applying themLeo
Sometimes it is necessary to edit patches before applying them. These changes allows you to do that by providing a new command `piem-edit` that shows the buffer that is prepared by `piem-am-ready-mbox` to the user. [km] Fixed let-binding in piem-edit-patch-am. Message-Id: <20211221140212.30248-1-sourcehut@relevant-information.com>
2021-12-24Add user option for specifying path to notmuch-extract-patchLeo
`notmuch-extract-patch` might not be available on PATH. This can be the case if the package wasn't installed through the distro package manager. [km] Added package-version keyword, and dropped if-let binding. Message-Id: <20211221191527.11819-1-sourcehut@relevant-information.com>
2021-12-17Support preparing am-ready mbox via notmuch-extract-patchLeo
notmuch-extract-patch is a command line tool from the elpa-mailscripts package that extracts patches from a thread. It's a useful way to extract the latest patch series from an email thread and filter out the replies and reviews. Message-Id: <20211216193234.25745-1-sourcehut@relevant-information.com>
2021-12-14README: Point to related projectsKyle Meyer
Documentation/piem.texi has a section that lists related projects, but highlight a couple in the README for visibility. Cc: Sean Whitton <spwhitton@spwhitton.name> Link: https://inbox.kyleam.com/piem/YbZOh0yEFLBwVUMp@melete.silentflame.com/ Message-Id: <20211212222119.124669-3-kyle@kyleam.com>
2021-12-14README: Mention b4 and leiKyle Meyer
piem leans on b4 heavily, so it deserves a pointer in the README. Plus, the next patch will mention b4 when it describes mailscripts, and it seems a bit odd for that to be the only mention. And lei wasn't a thing when this README was written, but it's certainly worth highlighting now. Message-Id: <20211212222119.124669-2-kyle@kyleam.com>
2021-12-12README: Fix a typoKyle Meyer
2021-11-05Release version 0.3.0v0.3.0Kyle Meyer
2021-10-25lei: Rename piem-lei-show-mid to piem-lei-buffer-midKyle Meyer
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>
2021-10-25lei q: Offer candidates for --include and --onlyKyle Meyer
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>
2021-10-25piem: Add function that returns public-inbox's configuration fileKyle Meyer
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>
2021-10-25lei: Set piem-lei-buffer-query for mid-based query functionsKyle Meyer
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>
2021-10-25lei: Add transient wrapper for piem-lei-queryKyle Meyer
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>
2021-10-25piem-lei-insert-output: Signal an error if lei call failsKyle Meyer
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>
2021-10-25lei: Add call-process wrapper for inserting lei outputKyle Meyer
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>
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>