unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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.





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