Re: Why does Gnus article-moving act like a fetch of new news?

[Karl Fogel <kfogel@red-bean.com>]

On 12 Apr 2021, Eric Abrahamsen wrote:
>> On 12 Apr 2021, Eric Abrahamsen wrote:
>>> So maybe `gnus-activate-group' would be sufficient? Though it 
>>> looks
>>> like the number-of-articles update is happening at line 10271,
>>> anyway.   Karl, would you be willing to patch the function to
>>> replace `gnus-group-get-new-news-this-group' with
>>> `gnus-activate-group', and run that for a while and see if 
>>> anything
>>> terrible happens?
>>
>> Yes, I'll do that and set a bit to report back here in two 
>> weeks. I'm
>> happy to be the Gnus test suite for a fortnight :-).
>
>Hopefully things won't go too wrong :)

Well, they go sort-of wrong :-).  Here's what happens:

First, this is the patch I'm using:

  --- lisp/gnus/gnus-sum.el
  +++ lisp/gnus/gnus-sum.el
  @@ -10346,8 +10346,8 @@ gnus-summary-move-article
         (apply #'gnus-summary-remove-process-mark 
         articles-to-update-marks))
       ;; Re-activate all groups that have been moved to.
       (with-current-buffer gnus-group-buffer
  -      (let ((gnus-group-marked to-groups))
  -	(gnus-group-get-new-news-this-group nil t)))
  +      (dolist (group to-groups)
  +	(gnus-activate-group group nil t nil t)))
   
       (gnus-kill-buffer copy-buf)
       (gnus-summary-position-point)

(There's a variant in which that first `nil' argument to 
`gnus-activate-group' is `t' instead.  I'll discuss both ways 
below.)

* *Without* the patch applied, per-article behavior is correct:
 
If you're in the summary buffer for group A, and you move an 
article to group B, then if you exit group A's summary buffer and 
go visit group B's summary, the article is there already, and its 
read-vs-unread state has been properly preserved.

* With the patch as shown above:
 
Immediately after moving an unread article from A to B, when you 
enter group B's summary buffer and look for the article, it won't 
be there.  However, if you `q'uit out of Gnus and then start Gnus 
again with `M-x gnus', *then* when you visit B, the article will 
be in B and marked as unread.
 
Now try the same thing with a marked-as-read article.  Not only 
will the article not be in group B right away, but even after you 
quit out of Gnus and then start Gnus again, when you visit group 
B, the article will be there *but marked as unread*.
 
* With the same patch but with the first `nil' changed to `t':
 
That's the SCAN argument, but changing it to `t' has no effect: 
it's the same behavior as with the original patch.
 
Now, maybe my patch wasn't what you hand in mind? 
Comments/suggestions welcome...

Best regards,
-Karl