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: Tue, 13 Apr 2021 14:59:40 -0700 Message-ID: <87pmyxg81f.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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9538"; 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 Wed Apr 14 00:01:19 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 1lWR5z-0002MX-0g for ged-emacs-devel@m.gmane-mx.org; Wed, 14 Apr 2021 00:01:19 +0200 Original-Received: from localhost ([::1]:41978 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lWR5y-0003VL-0f for ged-emacs-devel@m.gmane-mx.org; Tue, 13 Apr 2021 18:01:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33114) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lWR4a-0002z4-Cm for emacs-devel@gnu.org; Tue, 13 Apr 2021 17:59:52 -0400 Original-Received: from ericabrahamsen.net ([52.70.2.18]:49384 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 1lWR4Y-0000iu-H0 for emacs-devel@gnu.org; Tue, 13 Apr 2021 17:59:52 -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 C3134FA099; Tue, 13 Apr 2021 21:59:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericabrahamsen.net; s=mail; t=1618351182; bh=YcRrhSvXrkaHmour6PnHsYLSojncJQmGNFlvRMlAKQA=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=QhLBX85RkeN0aQ/jYWOdqqwBs2478zWApdU4W07P+nDfYPVL0Gw5qunTIjdIrQ048 xPaHrbcZw4QHnv7iVotJ7AGu7oUTFD0pztefYmKDl1BQ1xdfrd3eTVfKTGIWcE8Ivk kvr8EksMnl6g27U+eDNaoooQb5IuNPt1ihiSqeb8= In-Reply-To: <875z0qextc.fsf@red-bean.com> (Karl Fogel's message of "Tue, 13 Apr 2021 15:25:51 -0500") 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:268014 Archived-At: 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_. 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...