unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Karl Fogel <kfogel@red-bean.com>
To: Eric Abrahamsen <eric@ericabrahamsen.net>
Cc: Andreas Schwab <schwab@linux-m68k.org>,
	Stefan Monnier <monnier@iro.umontreal.ca>,
	Emacs Development <emacs-devel@gnu.org>
Subject: Re: Why does Gnus article-moving act like a fetch of new news?
Date: Sun, 11 Apr 2021 01:02:44 -0500	[thread overview]
Message-ID: <87fszx1hq3.fsf@red-bean.com> (raw)
In-Reply-To: <87mtu5iyv8.fsf@ericabrahamsen.net> (Eric Abrahamsen's message of "Sat, 10 Apr 2021 15:00:27 -0700")

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



  reply	other threads:[~2021-04-11  6:02 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fszx1hq3.fsf@red-bean.com \
    --to=kfogel@red-bean.com \
    --cc=emacs-devel@gnu.org \
    --cc=eric@ericabrahamsen.net \
    --cc=monnier@iro.umontreal.ca \
    --cc=schwab@linux-m68k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).