* 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
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.