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

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

On 13 Apr 2021, Eric Abrahamsen wrote:
>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. 

It works as you expected: after I run M-g, the moved article is 
present in the destination group.  And as before, the article is 
marked as unread in the destination group, no matter whether it 
was read or unread in the group it departed from.

Note that `M-g' (`gnus-group-get-new-news-this-group') seems to 
have the same effect that just `g' (`gnus-group-get-new-news') 
would have: Gnus fetches mail from all the mail sources I have 
defined (it's configured to collect from several different 
servers).

But I don't know what other choice Gnus would have, really.  After 
all, it can't know what mail would be filtered into the specific 
group point was on when I typed `M-g'.  Gnus has to fetch *all* 
mail and run it through `nnmail-split-methods`, which in my case 
points to a gigantic `nnmail-split-fancy' expression, before 
knowing what messages will land in what groups.
 
>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... 

Well, if Gnus is going to fetch new news, then it should 
definitely run `gnus-get-new-news-hook'.

The question is: why does it have to fetch new news?  Gnus should 
be able to tell a group "update yourself based on all the news 
currently in place, including some new stuff that I just placed in 
you that you might not be aware of yet", without that implying 
contacting upstream news sources.

But I don't know the code well enough to know what to invoke such 
that that boundary would be honored.

Best regards,
-Karl