unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Why does Gnus article-moving act like a fetch of new news?
@ 2021-04-09 21:47 Karl Fogel
  2021-04-10  4:11 ` Eric Abrahamsen
                   ` (2 more replies)
  0 siblings, 3 replies; 19+ messages in thread
From: Karl Fogel @ 2021-04-09 21:47 UTC (permalink / raw)
  To: Emacs Development

In lisp/gnus/gnus-sum.el, at the end of 
`gnus-summary-move-article', there is this code:

    ;; 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))) 

I'm no expert in this area of the code, but the above seems to 
conflate two different things:

a) It tells the destination group(s) that a new article has 
arrived, and 
   I guess that in turn "activates" the group?  (My understanding 
   of activation in Gnus is somewhat fuzzy.)

b) It also causes Gnus to run code that's involved in fetching new 
news? 
   At least, it definitely causes `gnus-get-new-news-hook' to be 
   run.

The latter part of (b) surprised me.  My `gnus-get-new-news-hook' 
runs a function that contacts a remote server of mine to check 
something.  I expect Gnus to run that hook only when I actually 
fetch new news -- like when I hit `g' in the Group buffer.  But 
because of (b), that hook is being run every time I move an 
article from one group to another (thus making article-moving very 
slow, of course).  

I expected article-moving to be an entirely local operation, and 
to have nothing to do with fetching new news.  After all, Gnus 
already has the article in question -- it's not "new".

One possibility is that I have wrong expectations about that hook. 
But the hook's documentation says:

  "A hook run just before Gnus checks for new news."

To me, that doesn't mean that the hook would run when I move an 
article from one group to another :-).

So I tentatively think this might indicate a problem in Gnus?  At 
the very least the hook's documentation might need to be updated. 
But it also seems possible that Gnus is failing to make a 
distinction between these two things: 

  "fetch new news from outside sources (usually some server 
  somewhere)"

versus

  "move an article that Gnus already had from one group to 
  another"

Are those two different actions sharing code that perhaps they 
shouldn't share?

I'm not expert in Gnus internals; I hope someone who knows more 
(Lars?)  can comment.

Best regards,
-Karl



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Why does Gnus article-moving act like a fetch of new news?
  2021-04-09 21:47 Why does Gnus article-moving act like a fetch of new news? Karl Fogel
@ 2021-04-10  4:11 ` Eric Abrahamsen
  2021-04-10  4:58   ` Karl Fogel
  2021-04-10  8:29 ` Andreas Schwab
  2021-04-11 16:05 ` Lars Ingebrigtsen
  2 siblings, 1 reply; 19+ messages in thread
From: Eric Abrahamsen @ 2021-04-10  4:11 UTC (permalink / raw)
  To: Karl Fogel; +Cc: Emacs Development

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

> In lisp/gnus/gnus-sum.el, at the end of `gnus-summary-move-article',
> there is this code:
>
>    ;; 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))) I'm no expert in
>       this area of the code, but the above seems to conflate two
>      different things:
>
> a) It tells the destination group(s) that a new article has arrived,
> and    I guess that in turn "activates" the group?  (My understanding
> of activation in Gnus is somewhat fuzzy.)
>
> b) It also causes Gnus to run code that's involved in fetching new
> news?    At least, it definitely causes `gnus-get-new-news-hook' to be
> run.
>
> The latter part of (b) surprised me.  My `gnus-get-new-news-hook' runs
> a function that contacts a remote server of mine to check something.
> I expect Gnus to run that hook only when I actually fetch new news --
> like when I hit `g' in the Group buffer.  But because of (b), that
> hook is being run every time I move an article from one group to
> another (thus making article-moving very slow, of course).  I expected
> article-moving to be an entirely local operation, and to have nothing
> to do with fetching new news.  After all, Gnus already has the article
> in question -- it's not "new".
>
> One possibility is that I have wrong expectations about that hook. But
> the hook's documentation says:
>
>  "A hook run just before Gnus checks for new news."
>
> To me, that doesn't mean that the hook would run when I move an
> article from one group to another :-).
>
> So I tentatively think this might indicate a problem in Gnus?  At the
> very least the hook's documentation might need to be updated. But it
> also seems possible that Gnus is failing to make a distinction between
> these two things:   "fetch new news from outside sources (usually some
> server   somewhere)"
>
> versus
>
>  "move an article that Gnus already had from one group to   another"
>
> Are those two different actions sharing code that perhaps they
> shouldn't share?

I think an argument could be made that if the DONT-SCAN optional
argument is non-nil, we should also skip running the two get-new-news
hooks. But let's see what Lars says.

Eric



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Why does Gnus article-moving act like a fetch of new news?
  2021-04-10  4:11 ` Eric Abrahamsen
@ 2021-04-10  4:58   ` Karl Fogel
  2021-04-10  5:29     ` Eric Abrahamsen
  0 siblings, 1 reply; 19+ messages in thread
From: Karl Fogel @ 2021-04-10  4:58 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: Emacs Development

On 09 Apr 2021, Eric Abrahamsen wrote:
> I think an argument could be made that if the DONT-SCAN optional 
> argument is non-nil, we should also skip running the two 
> get-new-news hooks. But let's see what Lars says. 

You mean the second argument to 
`gnus-group-get-new-news-this-group'?

The doc string is somewhat confusing on that argument:

  | gnus-group-get-new-news-this-group is an interactive compiled 
  | Lisp function in ‘gnus-group.el’.  |  | 
  (gnus-group-get-new-news-this-group &optional N DONT-SCAN) |  | 
  Check for newly arrived news in the current group (and the N-1 
  next groups).  | The difference between N and the number of 
  newsgroup checked is returned.  | If N is negative, this group 
  and the N-1 previous groups will be checked.  | If DONT-SCAN is 
  non-nil, scan non-activated groups as well. 

In other words, the meaning of "DONT-SCAN" seems to be: scan!  One 
can see how a person might be confused by this :-).

According to the "Terminology" section in the Gnus manual, 
"activating" a group means this:

  | The act of asking the server for info on a group and computing 
  the | number of unread articles is called “activating the 
  group”.  | Un-activated groups are listed with ‘*’ in the group 
  buffer. 

Thus I don't understand why moving an article to a group should 
unconditionally "activate" that group in the first place.  I can 
see how moving an *unread* article to a group might activate that 
group?  But the code in `gnus-summary-move-article' doesn't have 
such a conditional.

And even if we leave aside the question of why we unconditionally 
activate the destination group, it's still not clear why 
activating a group should imply getting new news for that group. 
Or, to put it another way: why is the way to activate a group to 
get new news for it?  These just seem like two very different 
things.

I realize you may not know the answers either, and that we may 
need Lars or someone with a similar level of knowledge.  I'm just 
trying to line up some useful questions.  Gnus is a very, very 
complex code base, I have learned through several dives in its 
coastal waters.

Best regards,
-Karl



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Why does Gnus article-moving act like a fetch of new news?
  2021-04-10  4:58   ` Karl Fogel
@ 2021-04-10  5:29     ` Eric Abrahamsen
  0 siblings, 0 replies; 19+ messages in thread
From: Eric Abrahamsen @ 2021-04-10  5:29 UTC (permalink / raw)
  To: Karl Fogel; +Cc: Emacs Development

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

> On 09 Apr 2021, Eric Abrahamsen wrote:
>> I think an argument could be made that if the DONT-SCAN optional
>> argument is non-nil, we should also skip running the two
>> get-new-news hooks. But let's see what Lars says. 
>
> You mean the second argument to `gnus-group-get-new-news-this-group'?
>
> The doc string is somewhat confusing on that argument:

Yup, and looking at the code I'm inclined to think that the docs are
just a typo -- don't scan really means don't scan.

>  | gnus-group-get-new-news-this-group is an interactive compiled   |
>    Lisp function in ‘gnus-group.el’.  |  |
>    (gnus-group-get-new-news-this-group &optional N DONT-SCAN) |  |
>    Check for newly arrived news in the current group (and the N-1
>    next groups).  | The difference between N and the number of
>    newsgroup checked is returned.  | If N is negative, this group
>    and the N-1 previous groups will be checked.  | If DONT-SCAN is
>    non-nil, scan non-activated groups as well. In other words, the
>    meaning of "DONT-SCAN" seems to be: scan!  One can see how a person
>   might be confused by this :-).
>
> According to the "Terminology" section in the Gnus manual,
> "activating" a group means this:
>
>  | The act of asking the server for info on a group and computing
>    the | number of unread articles is called “activating the   group”.
>    | Un-activated groups are listed with ‘*’ in the group   buffer.
>    Thus I don't understand why moving an article to a group should
>    unconditionally "activate" that group in the first place.  I can
>    see how moving an *unread* article to a group might activate that
>    group?  But the code in `gnus-summary-move-article' doesn't have
>    such a conditional.
>
> And even if we leave aside the question of why we unconditionally
> activate the destination group, it's still not clear why activating a
> group should imply getting new news for that group. Or, to put it
> another way: why is the way to activate a group to get new news for
> it?  These just seem like two very different things.

Yeah, I'm not sure either!



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Why does Gnus article-moving act like a fetch of new news?
  2021-04-09 21:47 Why does Gnus article-moving act like a fetch of new news? Karl Fogel
  2021-04-10  4:11 ` Eric Abrahamsen
@ 2021-04-10  8:29 ` Andreas Schwab
  2021-04-10 13:06   ` Stefan Monnier
  2021-04-11 16:05 ` Lars Ingebrigtsen
  2 siblings, 1 reply; 19+ messages in thread
From: Andreas Schwab @ 2021-04-10  8:29 UTC (permalink / raw)
  To: Karl Fogel; +Cc: Emacs Development

On Apr 09 2021, Karl Fogel wrote:

> I expected article-moving to be an entirely local operation, and to have
> nothing to do with fetching new news.  After all, Gnus already has the
> article in question -- it's not "new".

What if the destination group has been updated in the mean time?  Gnus
needs to know the current status of the group, before it can write to
it.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Why does Gnus article-moving act like a fetch of new news?
  2021-04-10  8:29 ` Andreas Schwab
@ 2021-04-10 13:06   ` Stefan Monnier
  2021-04-10 22:00     ` Eric Abrahamsen
  0 siblings, 1 reply; 19+ messages in thread
From: Stefan Monnier @ 2021-04-10 13:06 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: Karl Fogel, Emacs Development

>> I expected article-moving to be an entirely local operation, and to have
>> nothing to do with fetching new news.  After all, Gnus already has the
>> article in question -- it's not "new".
> What if the destination group has been updated in the mean time?  Gnus
> needs to know the current status of the group, before it can write to
> it.

But what if it gets updated *again* before we actually write to it?


        Stefan




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Why does Gnus article-moving act like a fetch of new news?
  2021-04-10 13:06   ` Stefan Monnier
@ 2021-04-10 22:00     ` Eric Abrahamsen
  2021-04-11  6:02       ` Karl Fogel
  0 siblings, 1 reply; 19+ messages in thread
From: Eric Abrahamsen @ 2021-04-10 22:00 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Karl Fogel, Andreas Schwab, Emacs Development

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> I expected article-moving to be an entirely local operation, and to have
>>> nothing to do with fetching new news.  After all, Gnus already has the
>>> article in question -- it's not "new".
>> What if the destination group has been updated in the mean time?  Gnus
>> needs to know the current status of the group, before it can write to
>> it.
>
> But what if it gets updated *again* before we actually write to it?

Also, in this case, it's updated *after* the article is moved to it.



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Why does Gnus article-moving act like a fetch of new news?
  2021-04-10 22:00     ` Eric Abrahamsen
@ 2021-04-11  6:02       ` Karl Fogel
  0 siblings, 0 replies; 19+ messages in thread
From: Karl Fogel @ 2021-04-11  6:02 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: Andreas Schwab, Stefan Monnier, Emacs Development

On 10 Apr 2021, Eric Abrahamsen wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes: 
> 
>>>> I expected article-moving to be an entirely local operation, 
>>>> and to have nothing to do with fetching new news.  After all, 
>>>> Gnus already has the article in question -- it's not "new". 
>>> What if the destination group has been updated in the mean 
>>> time?  Gnus needs to know the current status of the group, 
>>> before it can write to it. 
>> 
>> But what if it gets updated *again* before we actually write to 
>> it? 
> 
> Also, in this case, it's updated *after* the article is moved to 
> it. 

Yeah, that's the thing that puzzles me.  By this point, the 
article has already been moved to the destination group.  There 
can't be (I think?)  any justification for fetching new news to 
the destination group right then.  The user certainly hasn't asked 
for that to happen.

(Sorry for the strange formatting in my original couple of posts, 
by the way.  I was experimenting with `use-hard-newlines' in 
Message Mode, but I now see how that doesn't quite do the right 
thing in prose messages that contain code-like blocks interleaved 
with the regular paragraphs.  I've started using the helpful 
`messages-are-flowing' package while I ponder how best to solve 
this.)

Best regards,
-Karl



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Why does Gnus article-moving act like a fetch of new news?
  2021-04-09 21:47 Why does Gnus article-moving act like a fetch of new news? Karl Fogel
  2021-04-10  4:11 ` Eric Abrahamsen
  2021-04-10  8:29 ` Andreas Schwab
@ 2021-04-11 16:05 ` Lars Ingebrigtsen
  2021-04-12 17:05   ` Eric Abrahamsen
  2 siblings, 1 reply; 19+ messages in thread
From: Lars Ingebrigtsen @ 2021-04-11 16:05 UTC (permalink / raw)
  To: Karl Fogel; +Cc: Emacs Development

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

> In lisp/gnus/gnus-sum.el, at the end of `gnus-summary-move-article',
> there is this code:
>
>    ;; 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))) I'm no expert in
>       this area of the code, but the above seems to conflate two
>      different things:
>
> a) It tells the destination group(s) that a new article has arrived,
> and    I guess that in turn "activates" the group?  (My understanding
> of activation in Gnus is somewhat fuzzy.)

The code has been in there since the command was added (in 1997),
apparently...  I think it's just supposed to update the number of
articles in the group buffer?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Why does Gnus article-moving act like a fetch of new news?
  2021-04-11 16:05 ` Lars Ingebrigtsen
@ 2021-04-12 17:05   ` Eric Abrahamsen
  2021-04-12 17:56     ` Karl Fogel
  0 siblings, 1 reply; 19+ messages in thread
From: Eric Abrahamsen @ 2021-04-12 17:05 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Karl Fogel, Emacs Development

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Karl Fogel <kfogel@red-bean.com> writes:
>
>> In lisp/gnus/gnus-sum.el, at the end of `gnus-summary-move-article',
>> there is this code:
>>
>>    ;; 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))) I'm no expert in
>>       this area of the code, but the above seems to conflate two
>>      different things:
>>
>> a) It tells the destination group(s) that a new article has arrived,
>> and    I guess that in turn "activates" the group?  (My understanding
>> of activation in Gnus is somewhat fuzzy.)
>
> The code has been in there since the command was added (in 1997),
> apparently...  I think it's just supposed to update the number of
> articles in the group buffer?

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?



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Why does Gnus article-moving act like a fetch of new news?
  2021-04-12 17:05   ` Eric Abrahamsen
@ 2021-04-12 17:56     ` Karl Fogel
  2021-04-12 18:26       ` Eric Abrahamsen
  0 siblings, 1 reply; 19+ messages in thread
From: Karl Fogel @ 2021-04-12 17:56 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: Lars Ingebrigtsen, Emacs Development

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

Best regards,
-Karl



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Why does Gnus article-moving act like a fetch of new news?
  2021-04-12 17:56     ` Karl Fogel
@ 2021-04-12 18:26       ` Eric Abrahamsen
  2021-04-13 20:25         ` Karl Fogel
  0 siblings, 1 reply; 19+ messages in thread
From: Eric Abrahamsen @ 2021-04-12 18:26 UTC (permalink / raw)
  To: Karl Fogel; +Cc: Lars Ingebrigtsen, Emacs Development

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

> 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 :)



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Why does Gnus article-moving act like a fetch of new news?
  2021-04-12 18:26       ` Eric Abrahamsen
@ 2021-04-13 20:25         ` Karl Fogel
  2021-04-13 21:59           ` Eric Abrahamsen
  0 siblings, 1 reply; 19+ messages in thread
From: Karl Fogel @ 2021-04-13 20:25 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: Lars Ingebrigtsen, Emacs Development

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



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Why does Gnus article-moving act like a fetch of new news?
  2021-04-13 20:25         ` Karl Fogel
@ 2021-04-13 21:59           ` Eric Abrahamsen
  2021-04-14  3:27             ` Karl Fogel
                               ` (3 more replies)
  0 siblings, 4 replies; 19+ messages in thread
From: Eric Abrahamsen @ 2021-04-13 21:59 UTC (permalink / raw)
  To: Karl Fogel; +Cc: Lars Ingebrigtsen, Emacs Development

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



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Why does Gnus article-moving act like a fetch of new news?
  2021-04-13 21:59           ` Eric Abrahamsen
@ 2021-04-14  3:27             ` Karl Fogel
  2021-04-25 17:37             ` Lars Ingebrigtsen
                               ` (2 subsequent siblings)
  3 siblings, 0 replies; 19+ messages in thread
From: Karl Fogel @ 2021-04-14  3:27 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: Lars Ingebrigtsen, Emacs Development

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



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Why does Gnus article-moving act like a fetch of new news?
  2021-04-13 21:59           ` Eric Abrahamsen
  2021-04-14  3:27             ` Karl Fogel
@ 2021-04-25 17:37             ` Lars Ingebrigtsen
  2021-05-03 20:52             ` Eric Abrahamsen
  2021-05-03 20:53             ` Eric Abrahamsen
  3 siblings, 0 replies; 19+ messages in thread
From: Lars Ingebrigtsen @ 2021-04-25 17:37 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: Karl Fogel, Emacs Development

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

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

I think that sounds more correct...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Why does Gnus article-moving act like a fetch of new news?
  2021-04-13 21:59           ` Eric Abrahamsen
  2021-04-14  3:27             ` Karl Fogel
  2021-04-25 17:37             ` Lars Ingebrigtsen
@ 2021-05-03 20:52             ` Eric Abrahamsen
  2021-05-03 20:53             ` Eric Abrahamsen
  3 siblings, 0 replies; 19+ messages in thread
From: Eric Abrahamsen @ 2021-05-03 20:52 UTC (permalink / raw)
  To: Karl Fogel; +Cc: Lars Ingebrigtsen, Emacs Development

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.



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Why does Gnus article-moving act like a fetch of new news?
  2021-04-13 21:59           ` Eric Abrahamsen
                               ` (2 preceding siblings ...)
  2021-05-03 20:52             ` Eric Abrahamsen
@ 2021-05-03 20:53             ` Eric Abrahamsen
  2021-05-05 23:21               ` Karl Fogel
  3 siblings, 1 reply; 19+ messages in thread
From: Eric Abrahamsen @ 2021-05-03 20:53 UTC (permalink / raw)
  To: Karl Fogel; +Cc: Lars Ingebrigtsen, Emacs Development

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.



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Why does Gnus article-moving act like a fetch of new news?
  2021-05-03 20:53             ` Eric Abrahamsen
@ 2021-05-05 23:21               ` Karl Fogel
  0 siblings, 0 replies; 19+ messages in thread
From: Karl Fogel @ 2021-05-05 23:21 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: Lars Ingebrigtsen, Emacs Development

On 03 May 2021, Eric Abrahamsen wrote:
>I thought this was worth looking into more closely, and I'm 
>getting
>closer to figuring out the problem.

[...distant cheering from over the horizon...]

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

Thank you so much for looking further into this.  Your reasoning & 
questions above seem exactly right to me.  Knowing this 
"combination of the 'larger' functions, invoked properly" would be 
a good thing, and I think might be of general utility in the Gnus 
code.  Surely this isn't the only place where a group needs to be 
told that its article set has changed and that it needs to refresh 
itself in a local-only way.

By the way, I received your message twice, with two separate 
Message-ID headers:

  Message-ID: <87v97zsfod.fsf@ericabrahamsen.net>

  Message-ID: <87tunjsfnm.fsf@ericabrahamsen.net>

Letting you know just in case that's a manifestation of some kind 
of message-sending buglet.  (Since I was an explicit recipient in 
the headers, along with emacs-devel, I wondered if maybe your MUA 
or MDA somehow generates a distinct message, with its own 
Message-ID, for each recipient, instead of all recipients getting 
the same message.)

Best regards,
-Karl



^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2021-05-05 23:21 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-09 21:47 Why does Gnus article-moving act like a fetch of new news? Karl Fogel
2021-04-10  4:11 ` Eric Abrahamsen
2021-04-10  4:58   ` Karl Fogel
2021-04-10  5:29     ` Eric Abrahamsen
2021-04-10  8:29 ` Andreas Schwab
2021-04-10 13:06   ` Stefan Monnier
2021-04-10 22:00     ` Eric Abrahamsen
2021-04-11  6:02       ` Karl Fogel
2021-04-11 16:05 ` Lars Ingebrigtsen
2021-04-12 17:05   ` Eric Abrahamsen
2021-04-12 17:56     ` Karl Fogel
2021-04-12 18:26       ` Eric Abrahamsen
2021-04-13 20:25         ` Karl Fogel
2021-04-13 21:59           ` Eric Abrahamsen
2021-04-14  3:27             ` Karl Fogel
2021-04-25 17:37             ` Lars Ingebrigtsen
2021-05-03 20:52             ` Eric Abrahamsen
2021-05-03 20:53             ` Eric Abrahamsen
2021-05-05 23:21               ` Karl Fogel

unofficial mirror of emacs-devel@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/emacs-devel/0 emacs-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 emacs-devel emacs-devel/ https://yhetil.org/emacs-devel \
		emacs-devel@gnu.org
	public-inbox-index emacs-devel

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.emacs.devel
	nntp://news.gmane.io/gmane.emacs.devel


code repositories for project(s) associated with this inbox:

	https://git.savannah.gnu.org/cgit/emacs.git

AGPL code for this site: git clone http://ou63pmih66umazou.onion/public-inbox.git