From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_DOTEDU_SUSP,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from mx1.math.uh.edu (mx1.math.uh.edu [129.7.128.32]) by inbox.vuxu.org (Postfix) with ESMTP id 7D7A220551 for ; Fri, 19 Jan 2024 23:48:20 +0100 (CET) Received: from lists1.math.uh.edu ([129.7.128.208]) by mx1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1rQxem-0000000CUVN-2h4c for ml@inbox.vuxu.org; Fri, 19 Jan 2024 16:48:17 -0600 Received: from lists1.math.uh.edu ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.97.1) (envelope-from ) id 1rQxem-00000003UG7-18DR for ml@inbox.vuxu.org; Fri, 19 Jan 2024 16:48:12 -0600 Received: from mx1.math.uh.edu ([129.7.128.32]) by lists1.math.uh.edu with esmtp (Exim 4.97.1) (envelope-from ) id 1rQxej-00000003UFy-1H7H for ding@lists.math.uh.edu; Fri, 19 Jan 2024 16:48:09 -0600 Received: from quimby.gnus.org ([95.216.78.240]) by mx1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1rQxei-0000000CUUk-0qr0 for ding@lists.math.uh.edu; Fri, 19 Jan 2024 16:48:09 -0600 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:Mime-Version:Message-ID:Date:Subject:From:To: Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=CmQpNa3dG9u5rAFsJESuLQHUun6IcbYQpo/3FpUrNa8=; b=sPFEOs9pSI1r3Tv+FYEFwJ5oyZ SkiL0l/XyRihbH5n9M1Umar+lrolovsVLeUfsLiMlVjFsXcUh4dQKs3S49tZqqOujuMKHhZC+SV9m AML4q+LcojxR2uONFpjIaVIR95HD947g/2S5nmhWMyDo2/p2KymtmOeomCnjflik/Z7o=; Received: from ciao.gmane.io ([116.202.254.214]) by quimby.gnus.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rQxea-0005Iv-DP for ding@gnus.org; Fri, 19 Jan 2024 23:48:03 +0100 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1rQxeZ-0004Qp-89 for ding@gnus.org; Fri, 19 Jan 2024 23:47:59 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ding@gnus.org From: Eric Abrahamsen Subject: Replies, (very) wide replies, yanking, and the prefix argument Date: Fri, 19 Jan 2024 14:47:49 -0800 Message-ID: <87zfx1os8a.fsf@ericabrahamsen.net> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:cR5/kmLZUj0UVid+eMnSXKR7lLs= List-ID: Precedence: bulk Someone opened a bug against Gnus today[0], about buggy behavior when using "S v" (gnus-summary-very-wide-reply) with a prefix argument. That function looks like this: (defun gnus-summary-very-wide-reply (&optional yank) (interactive (list (and current-prefix-arg (gnus-summary-work-articles 1))) gnus-summary-mode) (gnus-summary-reply yank t (gnus-summary-work-articles yank))) Say point is on article number 10682 in the summary buffer, and you run "C-u S v". The call to the first `gnus-summary-work-articles' in the interactive form will return (10682), which is assigned to the variable yank. The second call to `gnus-summary-work-articles' now looks like `(gnus-summary-work-articles (10682))', which ends up trying to include the next 10,682 articles in the Summary buffer into the very wide reply. The whole thing is confusing. A few things seem wrong: 1. The Gnus manual says "S v" runs gnus-summary-wide-reply, but it actually runs gnus-summary-very-wide-reply 2. The docstring of gnus-summary-very-wide-reply says that it obeys the process/prefix convention (ie a prefix of '(4) should start a reply to the next four articles), and *also* says that the prefix argument means yank the contents of the articles being replied to. The manual only mentions the process/prefix convention. 3. Then there's the actual bug that the prefix argument is used incorrectly to generate WIDE-REPLY. I'm surprised that no one hit this bug before, and I'm not sure what to do with it. We have "S V" (gnus-summary-very-wide-reply-with-original) that uses the prefix argument correctly *and* yanks message content correctly, so I'm not sure there's a need for "S v" to handle the prefix argument both ways. I suppose I could make it handle the prefix argument both ways, though. Let me know if anyone has any thoughts on this. [0]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=68510