From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:203:375::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms1.migadu.com with LMTPS id uPXpJozrv2X95gAA62LTzQ:P1 (envelope-from ) for ; Sun, 04 Feb 2024 20:54:52 +0100 Received: from mta1.migadu.com ([2001:41d0:203:375::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id uPXpJozrv2X95gAA62LTzQ (envelope-from ) for ; Sun, 04 Feb 2024 20:54:52 +0100 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kyleam.com; s=key1; t=1707076492; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=4ZKdTOR57Ohg/rYm/5vZpitqzb2H5kD9837rm2YnnZM=; b=qCgH3Nei7vNAC5nLFTLO7cGH7ETSFbelD1iQdrgeeDAahUilj1W8hsnPjGoZkfaHHlnIRn eyZsA2NZQkOr5A+ZldoB5sc/+aCusL2TlPvphtWJjMNVooPFqpUXuv2gkK5EDdp3nO6e3l ubBxd1HzAc1nGnKLVpFOcJRVE1pUIgVKTK5vqJuC24Xx9vrgl2dGB8naZeWoiOYVCyN5vN DAlpAdbTX9ilnLSXcjv8SWHowBvstQlATbW32MvBDDdx9MvzcjA9pHu84sy8KEIXyzehpk YnXRtcS3lTfzCA0dpsSmWJwOfBF+6CbR0urJxhmWAqevNyS3KfqEX2kAauoHAg== From: Kyle Meyer To: Leo Cc: piem@inbox.kyleam.com Subject: [PATCH] *-am-ready-mbox: Don't require PATCH prefix In-Reply-To: <87fry9hn9u.fsf@> References: Date: Sun, 04 Feb 2024 14:54:47 -0500 Message-ID: <87ttmo57js.fsf@kyleam.com> MIME-Version: 1.0 Content-Type: text/plain X-Migadu-Flow: FLOW_OUT X-TUID: j997w0YOKz/X 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