From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Cc: 66450@debbugs.gnu.org, Bruno Victal <mirai@makinata.eu>
Subject: bug#66450: 29.1; Debbugs/Gnus sometimes corrupt git formatted patches
Date: Sat, 14 Oct 2023 09:43:46 -0700 [thread overview]
Message-ID: <87sf6dcfy5.fsf@ericabrahamsen.net> (raw)
In-Reply-To: <87edhx44a6.fsf@gmail.com> (Maxim Cournoyer's message of "Sat, 14 Oct 2023 11:22:57 -0400")
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
> Hi Eric!
>
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>>
>>> Hello,
>>>
>>> While working via Emacs Debbugs, I noticed that applying a patch would
>>> fail, and that this only occurred when fetching and saving the patch via
>>> Debbugs/Gnus. Below is a reproducer:
>>>
>>> 1. mkdir -p src && cd src && git clone https://git.savannah.gnu.org/git/guix.git
>>> 2. cd guix && git checkout core-updates
>>> 3. in emacs: M-x debbugs-gnu-bugs RET 65479 RET
>>> 4. Navigate to the message with [PATCH core-updates v3 10/63] in its
>>> subject
>>
>> This took way too long to figure out...
>>
>> TL;DR is: run "M-i r" before the "|" command.
>
> Oh, thank you, that works.
>
>> Gnus is treating the article with the `gnus-display-mime' treatment
>> function, which ends up inserting newlines between detected MIME parts,
>> in order to look "nice". It's not necessary to save the article to see
>> this: the newlines are present if you just open Bruno's message and look
>> at it. If you run `gnus-summary-show-raw-article', you'll see the
>> original raw article with no newlines.
>>
>> The problem is that the Gnus summary "save-article" commands operate on
>> the treated article, not the raw article.
>
> It'd be nice if that 'gnus-display-mime' procedure tried hard to *not*
> break 'git format-patch' messages; perhaps it could use a simple
> heuristic to do so. Out of the 63 patches in the series linked in the
> reproducer steps, only patch 10/63 was corrupted by it, so it appears to
> be a relatively rare occurrence.
Is it possible that message in particular had multiple mime attachments,
and the others didn't? I got the sense that the issue was with multiple
attachments, or a message that isn't itself the attachment in question,
but that contains attachments. Or something.
>> BUT! Someone™ anticipated that this would be an issue, and for
>> `gnus-summary-pipe-output' in particular provided a "symbolic prefix"
>> option for this command, a mechanism specific to Gnus that I'll wager
>> very few are aware of. It lets you specify that the raw article should
>> be piped instead of the treated article, by using "M-i" (to initiate the
>> symbolic prefix), then "r" (the prefix itself).
>>
>> It's actually documented in the manual, though the fact that neither of
>> us looked makes that feel a bit useless. It's also weird that only this
>> pipe command has the option of operating on the raw article; you'd think
>> that would be a useful option for the other article-saving commands, and
>> you'd also think maybe this should be the default for the pipe command.
>
> I'd also opine that the pipe command should process the raw article by
> default, but that's based on my sole experience with it, which nearly
> always involve applying 'git format-patch' patches.
By definition the pipe command will be sending the message to an
exterior process, so you'd think you'd never want to run the
treatment/washing commands, which have to do with user-facing article
display. Gnus (and Emacs in general) is full of Chesterton's fences,
though, and I would hesitate to go changing defaults like this.
next prev parent reply other threads:[~2023-10-14 16:43 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-10 18:29 bug#66450: 29.1; Debbugs/Gnus sometimes corrupt git formatted patches Maxim Cournoyer
2023-10-11 20:37 ` Eric Abrahamsen
2023-10-14 15:22 ` Maxim Cournoyer
2023-10-14 15:35 ` Maxim Cournoyer
2023-10-14 16:43 ` Eric Abrahamsen [this message]
2023-10-12 16:52 ` Michael Albinus
2023-10-12 22:04 ` Eric Abrahamsen
2023-10-13 7:01 ` Michael Albinus
2023-10-13 16:53 ` Eric Abrahamsen
2023-10-14 14:41 ` Michael Albinus
2023-10-14 16:40 ` Eric Abrahamsen
2023-10-16 14:59 ` Maxim Cournoyer
2023-10-17 7:03 ` Michael Albinus
2023-10-17 14:06 ` Eric Abrahamsen
2023-10-17 15:19 ` Maxim Cournoyer
2023-10-17 16:41 ` Eric Abrahamsen
2023-10-18 18:50 ` Maxim Cournoyer
2023-10-18 19:40 ` Eric Abrahamsen
2023-10-19 1:01 ` Maxim Cournoyer
2023-10-19 2:50 ` Eric Abrahamsen
2023-10-19 3:38 ` Maxim Cournoyer
2023-10-19 6:26 ` Visuwesh
2024-03-10 15:12 ` Eric Abrahamsen
2023-10-19 1:53 ` Maxim Cournoyer
2023-10-19 7:05 ` Michael Albinus
2023-10-14 20:27 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] ` <875y390x1s.fsf@>
2023-10-15 1:13 ` Eric Abrahamsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sf6dcfy5.fsf@ericabrahamsen.net \
--to=eric@ericabrahamsen.net \
--cc=66450@debbugs.gnu.org \
--cc=maxim.cournoyer@gmail.com \
--cc=mirai@makinata.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
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).