bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#66106: 28.2; Undo on yanked message fills message body with headers


From: Eric Abrahamsen
Subject: bug#66106: 28.2; Undo on yanked message fills message body with headers
Date: Tue, 19 Sep 2023 21:02:23 -0700
User-agent: Gnus/5.13 (Gnus v5.13)

Bruno Victal <mirai@makinata.eu> writes:

> 1. Using debbugs (elpa), go to issue #66057.
> 2. Open the 3rd reply. (from Jean Abou Samra)
> 3. In the Article buffer (the buffer with the message) do `S v' to
> start a wide reply.
> 4. Within the message body, do `C-c C-y' to copy the original
> message/yank.
>
> Issue #1: I get a “Jean Abou Samra writes:” line followed by nothing, it
> didn't paste the contents of the message I'm replying to.
>
> 5. Press `Undo'.
>
> Issue #2: Instead of reverting to an empty message body, I get the
> headers of the message I'm replying to in its place.
>
> Notes that might be of interest:
> * I have set `message-generate-hashcash' to `t'.
>
> There's also another issue I've encountered when I reattempted to reply
> but using `S V' (wide reply with yank): The message doesn't seem to be
> properly quoted. I only see a single level of '>' whereas I'd expect to
> see part of the body with '>>' corresponding to the quoted parts of the
> original message that started the discussion.

I don't see exactly what you're seeing -- I tried this out and always
got the message headers (no message body) with one level of quoting.
Hitting undo just removed the level of quoting. But the basic problem is there.

It looks like the issue is in `gnus-summary-reply'. The function that
prepares the original copy of the article for yanking is
`gnus-copy-article-buffer', which is called once per article being
replied to (note that "S V" is only wide; "S v" is very wide).

Starting at line 1105 in `gnus-summary-reply', we go to the buffer
containing the article text to yank, and run:

        (save-restriction
          (message-narrow-to-head)
          (when very-wide
            (erase-buffer)
            (insert headers))
          (goto-char (point-max)))

Perhaps the intention was that the narrowing would affect the behavior
of `erase-buffer', so that in effect this is supposed to replace
whatever headers were there with the contents of the "headers" variable.
But of course `erase-buffer' doesn't respect buffer narrowing, so
everything (including the actual text you wanted to reply to) gets
deleted. If I replace (erase-buffer) with (delete-region (point-min)
(point-max)), it appears to work correctly.

Did `erase-buffer' used to respect narrowing, when this code was written
20 years ago? Anyway, the more I look at it, the more I think that's
what's supposed to be happening here.

Eric





reply via email to

[Prev in Thread] Current Thread [Next in Thread]