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

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

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

I thought this was worth looking into more closely, and I'm getting
closer to figuring out the problem.

What we really need is to update the "active" number for the receiving
group -- that's Gnus' final authoritative figure for how many articles
are in the group, and if it's not updated then we see Karl's situation
where you enter the receiving group and don't see the moved articles,
until you do a full refresh of the group.

The calls to `gnus-group-get-new-news-this-group' make the world right
only because they end up calling `gnus-get-unread-articles-in-group',
which updates the group's active number (in addition to a bunch of other
stuff).

What I'm trying to figure out now is, what's the minimum amount of code
we can run that does this work, without running a whole bunch of other
unwanted processes. We can't just set the group's active number
directly, because we need to check the cache and the agent, and update
the *Group* buffer, etc., as part of that. So we'll need some
combination of the "larger" functions, invoked properly, but I haven't
figured out yet exactly how that will work.

But anyway, the mystery is clearing.