From: Manuel Giraud via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Andrew Cohen <cohen@bu.edu>
Cc: Eli Zaretskii <eliz@gnu.org>, 63842@debbugs.gnu.org, cohen@andy.bu.edu
Subject: bug#63842: 30.0.50; Slow 'gnus-summary-refer-thread'
Date: Mon, 19 Jun 2023 17:44:37 +0200 [thread overview]
Message-ID: <874jn3o3ru.fsf@ledu-giraud.fr> (raw)
In-Reply-To: <87bkhbpq1k.fsf@ust.hk> (Andrew Cohen's message of "Mon, 19 Jun 2023 20:58:15 +0800")
Andrew Cohen <cohen@bu.edu> writes:
>>>>>> "MG" == Manuel Giraud <manuel@ledu-giraud.fr> writes:
>
> MG> Andrew Cohen <cohen@bu.edu> writes:
> >> OK, I think I understand the problem.
>
> [...]
>
> MG> From my tiny testing set, it does not seems to me that parsing
> MG> all the headers is the way to go: the call to
> MG> 'gnus-search-run-query' in gnus-search.el line 2206 directly
> MG> returns direcly the correct set of messages and the call to
> MG> 'gnus-get-newsgroup-headers-xover' later looks like some "deep"
> MG> search (eg. on subject content).
>
> OK, I understand it now. This isn't really about searching, or subject
> content (the fact that Manuel sees some articles not in the thread but
> with similar subject remains a bit of a mystery).
It is a mistery to me too. If 'gnus-get-newsgroup-headers-xover' job is
to gather messages from the same thread, I think there is something
wrong here. I'm still searching.
> To get everything right, any articles in the thread that need to be
> added to the summary buffer have to be added to the dependencies
> hash. In the case of searching we know exactly which articles need to
> be added so we have no need for 'gnus-read-all-available-headers to be
> non-nil: the "found" articles are each added to the hash. The only
> case where 'gnus-read-all-available-headers needs to be non-nil is
> when we don't know exactly which articles are part of the thread in
> which case we have to parse a larger set. This is what happens in the
> 3rd case in the conditional (the "t" clause) in
> 'gnus-summary-refer-thread. That is, this variable is only relevant in
> those cases where we don't have a configured search engine and just
> retrieve a lot of headers and hope for the best. So the setting of
> 'gnus-read-all-available-headers is just in the wrong place.
Thanks. I don't know for other backends/search engines but a binding of
'gnus-read-all-available-headers' to t elsewhere will sure fix my issue.
--
Manuel Giraud
next prev parent reply other threads:[~2023-06-19 15:44 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-02 13:17 bug#63842: 30.0.50; Slow 'gnus-summary-refer-thread' Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-02 15:26 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-02 23:32 ` Andrew Cohen
2023-06-03 13:23 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-15 5:55 ` Eli Zaretskii
2023-06-15 17:59 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-16 10:36 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-16 23:37 ` Andrew Cohen
2023-06-17 22:16 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-18 0:45 ` Andrew Cohen
2023-06-18 20:57 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-19 12:58 ` Andrew Cohen
2023-06-19 15:44 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2023-06-23 10:00 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-01 8:25 ` Eli Zaretskii
[not found] ` <87edlsav34.fsf@ust.hk>
2023-07-01 9:49 ` Eli Zaretskii
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=874jn3o3ru.fsf@ledu-giraud.fr \
--to=bug-gnu-emacs@gnu.org \
--cc=63842@debbugs.gnu.org \
--cc=cohen@andy.bu.edu \
--cc=cohen@bu.edu \
--cc=eliz@gnu.org \
--cc=manuel@ledu-giraud.fr \
/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).