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

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

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.

> 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.

Maxim