| Age | Commit message (Collapse) | Author |
|---|
|
All of the *-am-ready-mbox functions expect inline patches to have a
'[... PATCH ...]' in the subject. In cases where a patch is sent
without that prefix, a piem-am caller gets an unhelpful "Could not
find am-ready mbox for current buffer" in response to
piem-am-ready-mbox returning nil.
To support these (hopefully rare) cases, drop the "has patch prefix?"
guard from all the *-am-ready-mbox functions. A caller is requesting
to extract a patch from the current buffer, and the "is the current
buffer in the right mode?" check should be sufficient for an
am-ready-mbox function to decide whether it should be responsible for
generating the mbox.
This added flexibility increases a caller's ability to apply invalid
patches. As with the previously possible cases, the output buffer
will give a clear error, but the caller will need to abort the git-am
sequence and clean up the branch. That seems reasonable given that,
in addition to the initial explicit request, an interactive piem-am
caller needs to "confirm" applying through the prompts, making it more
difficult to get to that state unintentionally.
Reported-by: Leo <git@relevant-information.com>
Link: https://inbox.kyleam.com/piem/87fry9hn9u.fsf@
Message-ID: <87ttmo57js.fsf@kyleam.com>
|
|
|
|
|
|
|
|
|
|
piem has be included with Guix since f63696a007 (2022-09-24).
|
|
Message-ID: <20230610095858.26982-6-jlicht@fsfe.org>
|
|
Message-ID: <20230610095858.26982-5-jlicht@fsfe.org>
|
|
Message-ID: <20230610095858.26982-4-jlicht@fsfe.org>
|
|
When using Gnus over NNTP, `gnus-summary-display-article' shows a
plain message, but when debbugs.el visits an issue message with Gnus,
it's already in mbox format.
Link: https://inbox.kyleam.com/piem/87cz2dun0y.fsf@kyleam.com
Message-ID: <20230610095858.26982-3-jlicht@fsfe.org>
|
|
With the `:gnu-package` keyword, users can configure a string to match
against the X-GNU-PR-PACKAGE email header for the GNU Bug Tracker.
Message-ID: <20230610095858.26982-2-jlicht@fsfe.org>
|
|
The piem-inboxes documentation says that the :url value must end in a
slash, which is confusing because 1) public-inbox does not require
this and has examples in its docs without a slash and 2) some spots in
piem already append a slash if needed.
Add a piem-inbox-get wrapper that ensures the returned URL ends with a
slash, and use it in all spots that retrieve an inbox's URL.
Reported-by: Jelle Licht <jlicht@fsfe.org>
Link: https://inbox.kyleam.com/piem/87y1l9ualg.fsf@fsfe.org
Message-ID: <20230603041100.200632-1-kyle@kyleam.com>
|
|
piem-inbox-by-header-match is used by functions like
piem-notmuch-get-inbox and piem-gnus-get-inbox, which are wired up to
piem-get-inbox-functions not piem-get-mid-functions.
|
|
The two previous commits updated the piem-add-message-id-header
functionality for git.git's change from Message-Id to Message-ID.
Updates a couple of remaining spots to use Message-ID for consistency.
Message-ID: <20230430221552.251335-5-kyle@kyleam.com>
|
|
format-patch switch to using "Message-ID" instead of "Message-Id" in
git.git's ba4324c4e1 (e-mail workflow: Message-ID is spelled with ID
in both capital letters, 2023-04-03). Update
piem--insert-message-id-header to follow Git's change.
Message-ID: <20230430221552.251335-4-kyle@kyleam.com>
|
|
As of git.git's ba4324c4e1 (e-mail workflow: Message-ID is spelled
with ID in both capital letters, 2023-04-03), git-format-patch inserts
a Message-ID header instead of Message-Id. Teach
piem--insert-message-id-header to look for either variant when it
checks for an existing header.
Another option would be to ignore the header case entirely. However,
piem--insert-message-id-header is intended to work only for
format-patch output, so stick with the stricter header matching.
Message-ID: <20230430221552.251335-3-kyle@kyleam.com>
|
|
MID is used throughout the code base, and what it refers to is
probably clear enough without putting "Message-Id" in front of it.
(If it were to stay, it should probably be spelled "message ID").
Message-ID: <20230430221552.251335-2-kyle@kyleam.com>
|
|
Avoid polluting the test output with
Counting messages...
Counting messages...done
|
|
When extracting patches from attachments, piem-gnus-am-ready-mbox and
piem-notmuch-am-ready-mbox construct the mbox messages in the same
order as the attachments. This depends on the sender attaching the
patches in ascending order.
Be a bit more helpful in situations where the sender attaches the
patches out of order by reordering patches according to the NNNN-
prefix that git-format-patch adds to the start of the patch file name.
This approach won't be able to reliably sort patches that aren't
generated by git-format-patch, but that's outside of any use case that
piem is intended to support.
Suggested-by: Ihor Radchenko <yantar92@gmail.com>
Link: https://inbox.kyleam.com/piem/87mtdj9dzt.fsf@localhost
Message-Id: <878rp2pyx1.fsf@kyleam.com>
|
|
The case doesn't matter; use lower case for consistency with other
spots.
|
|
Most of the user-facing documentation says "Message-Id" to match the
form that git-format-patch and git-am use. Do the same in
piem--write-mbox-to-maildir's error message.
|
|
This option has been available since b4 v0.6.0.
Message-Id: <20220516024041.205178-3-kyle@kyleam.com>
|
|
The trailer-related options happen to be grouped together with the
alphabetical sorting of the options setting, but the next commit will
add a trailer option that breaks this pattern. Add a section to keep
them together.
Message-Id: <20220516024041.205178-2-kyle@kyleam.com>
|
|
piem-inject-thread-into-maildir expects to be able to determine the
inbox by calling piem-inbox. That's fine for interactive use, but
wrapper functions may want to determine the inbox in another way.
Suggested-by: zimoun <zimon.toutoune@gmail.com>
Link: https://yhetil.org/guix-devel/86sfpo5q8w.fsf@gmail.com
Message-Id: <20220516032241.212199-1-kyle@kyleam.com>
|
|
|
|
An inbox may regularly receive patches for multiple repos. Allow an
inbox's :coderepo to be a list, and teach piem-inbox-coderepo to
select a target repo by prompting the caller with the configured list.
Message-Id: <20220506014017.14259-1-kyle@kyleam.com>
|
|
|
|
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>
|
|
|