From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.devel Subject: Re: Why does Gnus article-moving act like a fetch of new news? Date: Mon, 03 May 2021 13:53:17 -0700 Message-ID: <87tunjsfnm.fsf@ericabrahamsen.net> References: <87lf9rruzl.fsf@red-bean.com> <87wnt824dq.fsf@gnus.org> <87eeffsaa6.fsf@ericabrahamsen.net> <87tuobs7xd.fsf@red-bean.com> <87a6q3s6ja.fsf@ericabrahamsen.net> <875z0qextc.fsf@red-bean.com> <87pmyxg81f.fsf@ericabrahamsen.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29809"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Lars Ingebrigtsen , Emacs Development To: Karl Fogel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 03 22:54:16 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ldfa4-0007dq-M2 for ged-emacs-devel@m.gmane-mx.org; Mon, 03 May 2021 22:54:16 +0200 Original-Received: from localhost ([::1]:34608 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ldfa3-0003eF-Ne for ged-emacs-devel@m.gmane-mx.org; Mon, 03 May 2021 16:54:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35800) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ldfZD-0002Qs-Cu for emacs-devel@gnu.org; Mon, 03 May 2021 16:53:26 -0400 Original-Received: from ericabrahamsen.net ([52.70.2.18]:34900 helo=mail.ericabrahamsen.net) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ldfZ9-0004zz-Ph for emacs-devel@gnu.org; Mon, 03 May 2021 16:53:22 -0400 Original-Received: from localhost (c-71-197-184-122.hsd1.wa.comcast.net [71.197.184.122]) (Authenticated sender: eric@ericabrahamsen.net) by mail.ericabrahamsen.net (Postfix) with ESMTPSA id C19CFFA01F; Mon, 3 May 2021 20:53:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericabrahamsen.net; s=mail; t=1620075199; bh=Bnw9rl3ywx4tx3DXKYyM6uqtSvnBpmYCfpGMR+9smzg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=piGDCS8Gwlp/53Z5nIK+Bqv6MhnvUhd2SJMy22YGXeh9lz9jl38L3jZbZjaKkghmn F0zJLQeDhvsemaGgsjlUaNbuTLJsaSqazcxzUZXz0svIyDguoaTfVync7UCOoqz8Kl +yltgiRWkyEe//pOctPPucPjLylptWmlyLMqSzJw= In-Reply-To: <87pmyxg81f.fsf@ericabrahamsen.net> (Eric Abrahamsen's message of "Tue, 13 Apr 2021 14:59:40 -0700") Received-SPF: pass client-ip=52.70.2.18; envelope-from=eric@ericabrahamsen.net; helo=mail.ericabrahamsen.net X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:268849 Archived-At: Eric Abrahamsen writes: > Karl Fogel 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.