bug#66450: 29.1; Debbugs/Gnus sometimes corrupt git formatted patches

[Eric Abrahamsen <eric@ericabrahamsen.net>]

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.