| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Embarrassingly, I forgot to do this in b8eec6b9.
|
|
|
|
|
|
|
|
In 29834774 (piem-use-magit: Unconditionally set to t, 2021-05-23),
the initial sentence that actually referenced the variable name was
dropped, leaving the downstream text to confusingly talk about a
variable that was never named.
|
|
public-inbox has started to drop dates from its copyright lines,
pointing to the recommendation at
https://www.linuxfoundation.org/blog/copyright-notices-in-open-source-software-projects/
I regularly fail to keep copyright lines up to date, so I'll gladly
follow suit.
While touching these lines, change "all contributors" to "all piem
contributors" to get a bit closer to the variants recommended in the
above article.
|
|
piem-am-read-worktree isn't a good name because it doesn't provide any
information to distinguish this function from any other function used
for piem-am-read-worktree-function.
Message-Id: <20211229235036.372313-2-kyle@kyleam.com>
|
|
Within query buffers, a message for the current line can be displayed
while keeping point in the query buffer. Calling quit-window in a
query buffer, however, leaves the associated buffer's window in place,
which is probably not what the caller wants. Add a custom quit-window
variant that handles the message buffer too.
Suggested-by: Xinglu Chen <public@yoctocell.xyz>
Link: https://inbox.kyleam.com/piem/871r96am1q.fsf@yoctocell.xyz
Message-Id: <20211228231143.244455-1-kyle@kyleam.com>
|
|
piem-edit stores the format returned by piem-am-ready-mbox in a
buffer-local variable, piem-edit-patch--format. However,
piem-edit-patch-am doesn't use this value when it calls piem-am,
instead passing a hard-coded "mbox".
Pass piem-edit-patch--format so that git-am is called with the
appropriate format.
Cc: Leo <sourcehut@relevant-information.com>
Message-Id: <20211228170417.216825-1-kyle@kyleam.com>
|
|
|
|
Now that there is a command for displaying multiple threads, the order
that piem-lei-query--thread returns the threads matters. When lei-q
is given the --threads option, the threads don't have a clear order,
and --sort and --reverse don't have an effect, so
piem-lei-query--thread must handle the sorting.
Teach piem-lei-query--thread to sort by the date of the root message
in a thread, adding a option to control the direction of this sorting.
It may be better to sort by the latest date within the entire thread.
However, doing so is more expensive, so don't bother until a clear
case is made that it's the better option.
Message-Id: <20211228022037.206597-7-kyle@kyleam.com>
|
|
For piem-lei-query-threads output with multiple threads, add a newline
to make it easier to spot the start of a new thread.
In terms of presentation, I think it would also be nice to distinguish
search hits in the thread from other messages. For local messages,
pct could be used to do this, but punt on that for now.
Message-Id: <20211228022037.206597-6-kyle@kyleam.com>
|
|
piem-lei-query-threads inserts only the message ID of a ghost message,
using spaces for where the date and time is for other messages. The
space placeholders will become visually confusing when the next commit
starts inserting an empty line between threads. Switch to using a
dummy date-time instead.
Message-Id: <20211228022037.206597-5-kyle@kyleam.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
`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>
|
|
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>
|
|
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>
|
|
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>
|
|
|
|
|
|
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>
|
|
|
|
|
|
|