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

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Karl Fogel <kfogel@red-bean.com> writes:

> 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...

Your patch was what I had in mind, and I guess that means the update is
necessary! I guess I would have expected that
`gnus-request-accept-article' would take care of all the necessary
updating of group/article data, but apparently it doesn't. I guess it
updates the _backend_, but not _Gnus_.

With your patch, can you confirm that it's enough (after the article is
moved) to put point on the moved-to group and run M-g? That should mimic
the current behavior, and let you find the moved article correctly.

Anyway, I don't see a good solution to your problem, except for maybe my
earliest suggestion: that get-new-news not run the hooks if DONT-SCAN
is t. But now I'm not even confident that that behavior would be correct...