GNU bug report logs - #53989
29.0.50; Gnus searches broken

Previous Next

Full log

View this message in rfc822 format

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 53989 <at> debbugs.gnu.org
Subject: bug#53989: 29.0.50; Gnus searches broken
Date: Mon, 14 Feb 2022 14:11:01 -0800

On 02/14/22 06:19 AM, Michael Heerdegen wrote:
> Michael Heerdegen <michael_heerdegen <at> web.de> writes:
>
>> When edebugging, the path stuff seemed to work ok, I saw that the
>> article numbers like "9076" were processed individually.
>
> I had edebugged gnus-search-indexed-parse-output.
>
> When I replace the (member group groups) test there with just t, the
> search group gets a positive article count in the group buffer, unlike
> before.  But I still can't read the articles in that created search
> group.

Indeed, the problem is the doubled forward slash in your search results.
Does that actually come out of mairix? Any clue why that's in there?

We process the prefix to make sure that it ends in a forward slash
(which removes the first of the group name's two slashes), but the
second remains, and it is interpreted as a group name that looks like
this on the filesystem -- "computers/emacs" -- but should look like this
in Gnus -- "computers.emacs". Ie, internal slashes should be replaced
with a period.

We currently remove a leading ".", and I can additionally remove a
leading "/", but since in effect we've already done that, I'd like to
know where the doubled slash comes from.

This process is the bloody front line of Gnus' interface with a wild
world of search engines, and I'm happy to special-case the heck out of
it, but there is also something weird about the search results.

Thanks,
Eric

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.