From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.bugs Subject: bug#66106: 28.2; Undo on yanked message fills message body with headers Date: Tue, 19 Sep 2023 21:02:23 -0700 Message-ID: <875y455w6o.fsf@ericabrahamsen.net> References: <87msxi19l2.fsf@makinata.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12999"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 66106@debbugs.gnu.org To: Bruno Victal Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Sep 20 06:03:18 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qioQn-000383-Q0 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 20 Sep 2023 06:03:17 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qioQR-0005h7-8m; Wed, 20 Sep 2023 00:02:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qioQP-0005gv-VA for bug-gnu-emacs@gnu.org; Wed, 20 Sep 2023 00:02:53 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qioQP-0002nS-Kh for bug-gnu-emacs@gnu.org; Wed, 20 Sep 2023 00:02:53 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qioQY-0005fv-El for bug-gnu-emacs@gnu.org; Wed, 20 Sep 2023 00:03:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eric Abrahamsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 20 Sep 2023 04:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66106 X-GNU-PR-Package: emacs Original-Received: via spool by 66106-submit@debbugs.gnu.org id=B66106.169518256921797 (code B ref 66106); Wed, 20 Sep 2023 04:03:02 +0000 Original-Received: (at 66106) by debbugs.gnu.org; 20 Sep 2023 04:02:49 +0000 Original-Received: from localhost ([127.0.0.1]:58022 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qioQL-0005fU-3o for submit@debbugs.gnu.org; Wed, 20 Sep 2023 00:02:49 -0400 Original-Received: from mail.ericabrahamsen.net ([52.70.2.18]:57230) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qioQF-0005f7-9r for 66106@debbugs.gnu.org; Wed, 20 Sep 2023 00:02:46 -0400 Original-Received: from localhost (71-212-75-26.tukw.qwest.net [71.212.75.26]) (Authenticated sender: eric@ericabrahamsen.net) by mail.ericabrahamsen.net (Postfix) with ESMTPSA id 5999CFA059; Wed, 20 Sep 2023 04:02:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericabrahamsen.net; s=mail; t=1695182545; bh=Hg0L76Zw13yUlTc9ynKqJ87eUOqM8UdpgxY87KUxhnU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=TCnKMf0SxEneo96nY4PiBZXm1ACuCjc+z/QJLoBYGb2Ehm/lxpYSiKusVdKDYRzl1 9Jhu3BQP8xaoCteATf9kd5JxpGNYDPc5kRDi1e6PSAOJkLC6nxEuFsoG5h5YR29i8l 8ap7j1tx0g+dgY2ZJjLtdPeDJHy8Sah2byB3rHiw= In-Reply-To: <87msxi19l2.fsf@makinata.eu> (Bruno Victal's message of "Tue, 19 Sep 2023 16:11:53 +0100") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:270902 Archived-At: Bruno Victal 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 =E2=80=9CJean Abou Samra writes:=E2=80=9D 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 th= ere. 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