* Could not find am-ready mbox for current buffer
@ 2024-02-03 10:09 Leo
2024-02-04 19:54 ` [PATCH] *-am-ready-mbox: Don't require PATCH prefix Kyle Meyer
0 siblings, 1 reply; 5+ messages in thread
From: Leo @ 2024-02-03 10:09 UTC (permalink / raw)
To: piem
Hello,
This is really just for future reference, in case someone else stumbles
upon this. I've resolved it for myself and am just documenting what the
issue was.
I found that for a specific email with a patch piem would just refuse to
apply it with the message "Could not find am-ready mbox for current
buffer", even if just piping the email through `git am` would work.
Turns out the issue was with piem-patch-subject-re. The patch was sent
with a different subject prefix (the --subject-prefix option in
git-send-email) than the default, which didn't match
piem-patch-subject-re.
For example:
> Subject: [RFC] add some code
So if you, like me, just can't figure out why piem is angry with just
this specific patch, consider adjusting that variable.
Cheers,
Leo
^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH] *-am-ready-mbox: Don't require PATCH prefix
2024-02-03 10:09 Could not find am-ready mbox for current buffer Leo
@ 2024-02-04 19:54 ` Kyle Meyer
2024-02-04 20:12 ` Kyle Meyer
[not found] ` <87sf272ojs.fsf@>
0 siblings, 2 replies; 5+ messages in thread
From: Kyle Meyer @ 2024-02-04 19:54 UTC (permalink / raw)
To: Leo; +Cc: piem
Leo writes:
> This is really just for future reference, in case someone else stumbles
> upon this. I've resolved it for myself and am just documenting what the
> issue was.
Thanks.
> I found that for a specific email with a patch piem would just refuse to
> apply it with the message "Could not find am-ready mbox for current
> buffer", even if just piping the email through `git am` would work.
> Turns out the issue was with piem-patch-subject-re. The patch was sent
> with a different subject prefix (the --subject-prefix option in
> git-send-email) than the default, which didn't match
> piem-patch-subject-re.
It looks like piem-patch-subject-re is used in piem--shorten-subject and
*-am-ready-mbox functions:
$ grep -p piem-patch-subject-re
piem-gnus.el=(defun piem-gnus-am-ready-mbox ()
piem-gnus.el: piem-patch-subject-re
piem-notmuch.el=(defun piem-notmuch-am-ready-mbox ()
piem-notmuch.el: (when (string-match-p piem-patch-subject-re
piem-notmuch.el=(defun piem-notmuch-extract-patch-am-ready-mbox ()
piem-notmuch.el: (string-match-p piem-patch-subject-re
piem.el=(defun piem-extract-mbox-info (&optional buffer)
piem.el:(defvar piem-patch-subject-re
piem.el=(defun piem--shorten-subject (subject)
piem.el: piem-patch-subject-re ""))
Perhaps it was a mistake to add the piem-patch-subject-re guard to the
*-am-ready-mbox functions. If we know we're in the right buffer type
and the caller is asking to extract the am-ready-mbox from the current
buffer, is there any value being strict about the subject? I'm thinking
of dropping the guards like so...
-- >8 --
Subject: [PATCH] *-am-ready-mbox: Don't require PATCH prefix
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 change makes it more likely that a piem-am caller invokes 'git
am' on something that's not a valid patch, but in that case 1) the
output buffer gives a reasonable error and 2) no other function in
piem-am-ready-mbox-functions could be expected to successfully apply
it, so there's no harm in claiming it.
---
piem-gnus.el | 8 ++------
piem-notmuch.el | 12 ++++--------
2 files changed, 6 insertions(+), 14 deletions(-)
diff --git a/piem-gnus.el b/piem-gnus.el
index 7120512..b6dc672 100644
--- a/piem-gnus.el
+++ b/piem-gnus.el
@@ -130,12 +130,8 @@ (defun piem-gnus-am-ready-mbox ()
(when-let ((patch (with-current-buffer gnus-article-buffer
(save-restriction
(widen)
- (and (string-match-p
- piem-patch-subject-re
- (mail-decode-encoded-word-string
- (message-field-value "subject")))
- (buffer-substring-no-properties
- (point-min) (point-max)))))))
+ (buffer-substring-no-properties
+ (point-min) (point-max))))))
(cons (lambda () (insert patch))
"mbox"))))))
diff --git a/piem-notmuch.el b/piem-notmuch.el
index 493b724..9077ec8 100644
--- a/piem-notmuch.el
+++ b/piem-notmuch.el
@@ -100,12 +100,10 @@ (defun piem-notmuch-am-ready-mbox ()
(n-attachments (notmuch-count-attachments handle))
patches)
(if (= n-attachments 0)
- (when (string-match-p piem-patch-subject-re
- (notmuch-show-get-subject))
- (let ((id (notmuch-show-get-message-id)))
- (lambda ()
- (call-process notmuch-command nil t nil
- "show" "--format=mbox" id))))
+ (let ((id (notmuch-show-get-message-id)))
+ (lambda ()
+ (call-process notmuch-command nil t nil
+ "show" "--format=mbox" id)))
(notmuch-foreach-mime-part
(lambda (p)
(when-let ((patch (piem-am-extract-attached-patch p)))
@@ -125,8 +123,6 @@ (defun piem-notmuch-extract-patch-am-ready-mbox ()
notmuch-extract-patch to get the latest patch series from the
notmuch thread."
(when (and (derived-mode-p 'notmuch-show-mode)
- (string-match-p piem-patch-subject-re
- (notmuch-show-get-subject))
(= (notmuch-count-attachments
(piem-notmuch--with-current-message
(mm-dissect-buffer)))
base-commit: 4256eb8b62f81f1f755184bbe245b3155f723a5a
--
2.41.0
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] *-am-ready-mbox: Don't require PATCH prefix
2024-02-04 19:54 ` [PATCH] *-am-ready-mbox: Don't require PATCH prefix Kyle Meyer
@ 2024-02-04 20:12 ` Kyle Meyer
[not found] ` <87sf272ojs.fsf@>
1 sibling, 0 replies; 5+ messages in thread
From: Kyle Meyer @ 2024-02-04 20:12 UTC (permalink / raw)
To: Leo; +Cc: piem
Kyle Meyer writes:
> Subject: [PATCH] *-am-ready-mbox: Don't require PATCH prefix
> [...]
I meant to add a Reported-by trailer; will fix on apply (unless reroll
is needed for other reasons).
> ---
> piem-gnus.el | 8 ++------
> piem-notmuch.el | 12 ++++--------
> 2 files changed, 6 insertions(+), 14 deletions(-)
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] *-am-ready-mbox: Don't require PATCH prefix
[not found] ` <87sf272ojs.fsf@>
@ 2024-02-06 4:08 ` Kyle Meyer
2024-02-12 3:44 ` Kyle Meyer
0 siblings, 1 reply; 5+ messages in thread
From: Kyle Meyer @ 2024-02-06 4:08 UTC (permalink / raw)
To: Leo; +Cc: piem
[ adding piem inbox back to cc ]
Leo writes:
> Kyle Meyer <kyle@kyleam.com> writes:
>>
>> This change makes it more likely that a piem-am caller invokes 'git
>> am' on something that's not a valid patch, but in that case 1) the
>> output buffer gives a reasonable error
>>
> The only comment I have is that running piem-am with this patch on a
> non-patch buffer (and selecting a repo to apply it on) will create a new
> branch and put git in a state of failing to apply a patch. You need to
> clean it up by deleting the branch and running `git am --abort` in the
> repository. This seems reasonable to me. Both are easy to do, and is
> what you would expect to happen if you run `git-am` with a broken patch
> (well not really the branch, but I think that's fine).
Right, that is worth spelling out. Thanks.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] *-am-ready-mbox: Don't require PATCH prefix
2024-02-06 4:08 ` Kyle Meyer
@ 2024-02-12 3:44 ` Kyle Meyer
0 siblings, 0 replies; 5+ messages in thread
From: Kyle Meyer @ 2024-02-12 3:44 UTC (permalink / raw)
To: Leo; +Cc: piem
Kyle Meyer writes:
> Leo writes:
>
>> The only comment I have is that running piem-am with this patch on a
>> non-patch buffer (and selecting a repo to apply it on) will create a new
>> branch and put git in a state of failing to apply a patch. You need to
>> clean it up by deleting the branch and running `git am --abort` in the
>> repository. This seems reasonable to me. Both are easy to do, and is
>> what you would expect to happen if you run `git-am` with a broken patch
>> (well not really the branch, but I think that's fine).
>
> Right, that is worth spelling out. Thanks.
Pushed (8abe70c) with a revised commit message.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2024-02-12 3:44 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-02-03 10:09 Could not find am-ready mbox for current buffer Leo
2024-02-04 19:54 ` [PATCH] *-am-ready-mbox: Don't require PATCH prefix Kyle Meyer
2024-02-04 20:12 ` Kyle Meyer
[not found] ` <87sf272ojs.fsf@>
2024-02-06 4:08 ` Kyle Meyer
2024-02-12 3:44 ` Kyle Meyer
Code repositories for project(s) associated with this public inbox
https://git.kyleam.com/piem/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).