Gnus development mailing list
 help / color / mirror / Atom feed
From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: ding@gnus.org
Subject: Replies, (very) wide replies, yanking, and the prefix argument
Date: Fri, 19 Jan 2024 14:47:49 -0800	[thread overview]
Message-ID: <87zfx1os8a.fsf@ericabrahamsen.net> (raw)

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



             reply	other threads:[~2024-01-19 22:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-19 22:47 Eric Abrahamsen [this message]
2024-01-20  8:28 ` Michael Albinus
2024-01-21  3:28   ` 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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zfx1os8a.fsf@ericabrahamsen.net \
    --to=eric@ericabrahamsen.net \
    --cc=ding@gnus.org \
    /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.
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 NNTP newsgroup(s).