From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: info-gnus-english@gnu.org
Subject: Re: nnimap-split-download-body removed?
Date: Mon, 30 Nov 2020 17:51:16 -0800 [thread overview]
Message-ID: <87lfeiqoob.fsf@ericabrahamsen.net> (raw)
In-Reply-To: <875z5mqt4o.fsf@gmail.com>
Bodertz <bodertz@gmail.com> writes:
> I can confirm that setting `nnimap-split-download-body-default' to t
> works as intended. I really should have tried that first.
No worries, that's good news.
> It sounds like the removal wasn't intentional, so hopefully it can be
> added back.
I think we could just resurrect the old `nnimap-split-download-body'
defcustom, then fix the docs. I don't see any need for this
`nnimap-split-download-body-default'.
> It seems to download the body before the splitting, which is
> unfortunate. It would be better if it only downloaded the body when the
> split required it. Or if it could match the sender against a whitelist
> of accepted senders and only download when they matched. Or the same
> thing but with the summary, but then it's getting close to just adding
> a simpler split system before the real one, which is a little odd.
>
> So I don't forget, someone also suggested `nnimap-split-download-body
> size', which might be a useful addition:
The code Ted's referring to is long gone, and things are a lot simpler
now. We could re-introduce some of the complexity, but I wasn't there
for the earlier versions and don't know the arguments for why the code
is the way it is now. The problem with checking the headers or the
message size before downloading the body is that you're then issuing one
FETCH to get all the messages without their bodies, and then issuing
another to get the bodies you want, likely just the same list as before.
That seems like it would end up being pretty inefficient, and I wouldn't
be surprised if it turned out that we had to issue one FETCH per message
we wanted the body for. I'll admit I haven't looked at this part of the
code closely, but...
Eric
_______________________________________________
info-gnus-english mailing list
info-gnus-english@gnu.org
https://lists.gnu.org/mailman/listinfo/info-gnus-english
next prev parent reply other threads:[~2020-12-01 1:52 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-30 15:03 Bodertz
2020-11-30 17:10 ` Eric Abrahamsen
2020-12-01 0:15 ` Bodertz
2020-12-01 1:51 ` Eric Abrahamsen [this message]
2020-12-01 3:04 ` Bodertz
2020-12-01 3:35 ` Eric Abrahamsen
2020-12-01 8:46 ` Bodertz
2020-12-01 18:26 ` Eric Abrahamsen
2020-12-02 7:18 ` Bodertz
2020-12-02 20:34 ` Eric Abrahamsen
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lfeiqoob.fsf@ericabrahamsen.net \
--to=eric@ericabrahamsen.net \
--cc=info-gnus-english@gnu.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.
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 NNTP newsgroup(s).