[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why does Gnus article-moving act like a fetch of new news?
From: |
Karl Fogel |
Subject: |
Re: Why does Gnus article-moving act like a fetch of new news? |
Date: |
Tue, 13 Apr 2021 15:25:51 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
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
- Re: Why does Gnus article-moving act like a fetch of new news?, (continued)
- Re: Why does Gnus article-moving act like a fetch of new news?, Lars Ingebrigtsen, 2021/04/11
- Re: Why does Gnus article-moving act like a fetch of new news?, Eric Abrahamsen, 2021/04/12
- Re: Why does Gnus article-moving act like a fetch of new news?, Karl Fogel, 2021/04/12
- Re: Why does Gnus article-moving act like a fetch of new news?, Eric Abrahamsen, 2021/04/12
- Re: Why does Gnus article-moving act like a fetch of new news?,
Karl Fogel <=
- Re: Why does Gnus article-moving act like a fetch of new news?, Eric Abrahamsen, 2021/04/13
- Re: Why does Gnus article-moving act like a fetch of new news?, Karl Fogel, 2021/04/13
- Re: Why does Gnus article-moving act like a fetch of new news?, Lars Ingebrigtsen, 2021/04/25