gnus-summary-refer-thread does not find all

gnus-summary-refer-thread does not find all

[Stefan Monnier]

I often find that A T doesn't find all the articles I'm looking for.
It turns out that one of the reason might be the following:

gnus-summary-limit-include-thread calls
gnus-summary-limit-include-matching-articles with "subject" and
a subject-regexp in decoded form (with non-ASCII chars).  These args are
then passed to gnus-find-matching-articles which compares uses the regexp on
the output of mail-header-subject but this output is not decoded (accented
chars are represented by sequences of other chars).


        Stefan

Re: gnus-summary-refer-thread does not find all

[Katsumi Yamaoka]

>>>>> In <jwvhdl6pol1.fsf-monnier+emacs@gnu.org> Stefan Monnier wrote:

> I often find that A T doesn't find all the articles I'm looking for.
> It turns out that one of the reason might be the following:

> gnus-summary-limit-include-thread calls
> gnus-summary-limit-include-matching-articles with "subject" and
> a subject-regexp in decoded form (with non-ASCII chars).  These args are
> then passed to gnus-find-matching-articles which compares uses the regexp on
> the output of mail-header-subject but this output is not decoded (accented
> chars are represented by sequences of other chars).

Hmm, the output mail-header-subject returns looks always a
decoded subject.  Raw headers gathered in the " *nntpd*" buffer
are decoded when building the value of gnus-newsgroup-headers as
far as I know.

Aren't there ticked articles in the group?  In such a case, `A T'
ignores articles newer than the last article listed in the
summary buffer.  Although I don't understand why it does so, the
possible workaround is to set the gnus-refer-thread-limit
variable as t, not a number.  If it is not effective, something
exceeding my imagination may have occurred.