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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 53989 in the body.
You can then email your comments to 53989 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: bug-gnu-emacs <at> gnu.org
Cc: eric <at> ericabrahamsen.net
Subject: 29.0.50; Gnus searches broken
Date: Mon, 14 Feb 2022 04:37:28 +0100

Hello,

G g in Gnus only gives me search groups containing no messages.  I have
verified that matches are collected successfully, but they are not
processed correctly.

When I load the gnus-search.el version of the parent commit of

| e7f6bb38dd Rework gnus-search-indexed-parse-output
| Eric Abrahamsen <eric <at> ericabrahamsen.net> Sat Jun 26 10:16:19 2021 -0700

searching works again.  When I load the version of the commit, it's
broken.  So with my setup that commit seems to have broken something.

What could be the problem?

TIA,

Michael.


In GNU Emacs 29.0.50 (build 17, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0)
 of 2022-02-14 built on drachen
Repository revision: f2dae7e79c37a94069245319166b9e4193f2ccf7
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)

Message #8 received at 53989 <at> debbugs.gnu.org (full text, mbox):

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

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> Hello,
>
> G g in Gnus only gives me search groups containing no messages.  I have
> verified that matches are collected successfully, but they are not
> processed correctly.
>
> When I load the gnus-search.el version of the parent commit of
>
> | e7f6bb38dd Rework gnus-search-indexed-parse-output
> | Eric Abrahamsen <eric <at> ericabrahamsen.net> Sat Jun 26 10:16:19 2021 -0700
>
> searching works again.  When I load the version of the commit, it's
> broken.  So with my setup that commit seems to have broken something.
>
> What could be the problem?

The problem is the search output isn't being parsed correctly! Again.
Can you tell me which Gnus backend this is on, what the search engine
is, what search engine config you've got, and the full filepath of a
typical search result that isn't showing up in searches?

TIA,
Eric

Message #11 received at 53989 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 53989 <at> debbugs.gnu.org
Subject: Re: bug#53989: 29.0.50; Gnus searches broken
Date: Mon, 14 Feb 2022 05:59:25 +0100

Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

> Can you tell me which Gnus backend this is on, what the search engine
> is, what search engine config you've got, and the full filepath of a
> typical search result that isn't showing up in searches?

I was using mairix to search my local mail archives (nnml):

(setf (alist-get 'nnml gnus-search-default-engines)
      'gnus-search-mairix)
(setq gnus-search-mairix-remove-prefix
      (expand-file-name "Mail/archive/" "~"))

Matches look like

/home/micha/Mail/archive//sent/9076

Anything else you need to know?

When edebugging, the path stuff seemed to work ok, I saw that the
article numbers like "9076" were processed individually.  However I
didn't understand why the group names in the code were like ".sent",
".work", etc, with a leading dot, instead of "sent", "work".  At that
point I gave up.  I had the impression that the articles were not
correctly mapped to their groups and all were just discarded.

Michael.

Message #14 received at 53989 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 53989 <at> debbugs.gnu.org
Subject: Re: bug#53989: 29.0.50; Gnus searches broken
Date: Mon, 14 Feb 2022 06:19:38 +0100

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.

If you have problems to identify the issue, I can send you a recorded
Edebug session privately if that could help.

Michael.

Message #17 received at 53989 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 53989 <at> debbugs.gnu.org
Subject: Re: bug#53989: 29.0.50; Gnus searches broken
Date: Sun, 13 Feb 2022 22:06:49 -0800

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> 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.

Right, the problem is the erroneous group names: even if you let the
search results pass through, the group name is still wrong, and the
article won't be found.

Message #20 received at 53989 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 53989 <at> debbugs.gnu.org
Subject: Re: bug#53989: 29.0.50; Gnus searches broken
Date: Sun, 13 Feb 2022 22:05:49 -0800

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> Can you tell me which Gnus backend this is on, what the search engine
>> is, what search engine config you've got, and the full filepath of a
>> typical search result that isn't showing up in searches?
>
> I was using mairix to search my local mail archives (nnml):
>
> (setf (alist-get 'nnml gnus-search-default-engines)
>       'gnus-search-mairix)
> (setq gnus-search-mairix-remove-prefix
>       (expand-file-name "Mail/archive/" "~"))
>
> Matches look like
>
> /home/micha/Mail/archive//sent/9076

This double slash is odd?

> Anything else you need to know?
>
> When edebugging, the path stuff seemed to work ok, I saw that the
> article numbers like "9076" were processed individually.  However I
> didn't understand why the group names in the code were like ".sent",
> ".work", etc, with a leading dot, instead of "sent", "work".  At that
> point I gave up.  I had the impression that the articles were not
> correctly mapped to their groups and all were just discarded.

I'm not sure where the dot would come from, either, but that's a good
clue. I'll take a look.

Message #23 received at 53989 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 53989 <at> debbugs.gnu.org
Subject: Re: 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

Message #26 received at 53989 <at> debbugs.gnu.org (full text, mbox):

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

On 02/14/22 14:11 PM, Eric Abrahamsen wrote:
> 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.

Also, it looks like your bug#47130 is still open. Since we've moved on
to this one, maybe lets close that in the meantime?

Message #29 received at 53989 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 53989 <at> debbugs.gnu.org
Subject: Re: bug#53989: 29.0.50; Gnus searches broken
Date: Mon, 14 Feb 2022 23:49:27 +0100

Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

> Does that actually come out of mairix? Any clue why that's in there?

I think it comes from mairix.  When I run

|  micha> mairix -r b:emacs

I get an output like

| /home/micha/Mail/archive//sent/8383
| /home/micha/Mail/archive//sent/8391
| ...

Without the -r arg ("raw output"), mairix fills a folder with symlinks.

That folder looks like

|  /home/micha/mairix:
|  drwxr-xr-x   2 micha micha 120K Feb 14 23:42 .
|  drwxr-xr-x 195 micha micha  60K Feb 14 23:42 ..
|  lrwxrwxrwx   1 micha micha   35 Feb 14 23:42 10002 -> /home/micha/Mail/archive//sent/2876
|  lrwxrwxrwx   1 micha micha   35 Feb 14 23:42 10005 -> /home/micha/Mail/archive//sent/2879

Visiting these symlinks succeeds, surprisingly, in Emacs, and in
Dolphin.  Is this double-slash syntax in symlink targets something
special or some kind of error that is just ignored?

This is my .mairixrc:

| base=~/Mail/archive
| mfolder=/home/micha/mairix
| mh=...
| mformat=mh
| omit=zz_mairix-*
| database=~/.mairixdatabase

Doesn't look like the slashes are from there.  And that's already all
setup I have, AFAIR. The folder names in /home/micha/Mail/archive just
look normally.

I tried to search the internet for the //-problem but didn't find
anything.

Michael.

Message #32 received at 53989 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 53989 <at> debbugs.gnu.org
Subject: Re: bug#53989: 29.0.50; Gnus searches broken
Date: Tue, 15 Feb 2022 00:06:41 +0100

Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

> Also, it looks like your bug#47130 is still open. Since we've moved on
> to this one, maybe lets close that in the meantime?

Did you already add the note to the documentation that we seemed to have
talked about in that report?  AFAIR, the note should say that the
binding of `gnus-search-mairix-remove-prefix' must correspond to the
path of the mail archive, not to some mairix folder.

Michael.

Message #35 received at 53989 <at> debbugs.gnu.org (full text, mbox):

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

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> Does that actually come out of mairix? Any clue why that's in there?
>
> I think it comes from mairix.  When I run
>
> |  micha> mairix -r b:emacs
>
> I get an output like
>
> | /home/micha/Mail/archive//sent/8383
> | /home/micha/Mail/archive//sent/8391
> | ...
>
> Without the -r arg ("raw output"), mairix fills a folder with symlinks.
>
> That folder looks like
>
> |  /home/micha/mairix:
> |  drwxr-xr-x   2 micha micha 120K Feb 14 23:42 .
> |  drwxr-xr-x 195 micha micha  60K Feb 14 23:42 ..
> |  lrwxrwxrwx   1 micha micha   35 Feb 14 23:42 10002 -> /home/micha/Mail/archive//sent/2876
> |  lrwxrwxrwx   1 micha micha   35 Feb 14 23:42 10005 -> /home/micha/Mail/archive//sent/2879
>
> Visiting these symlinks succeeds, surprisingly, in Emacs, and in
> Dolphin.  Is this double-slash syntax in symlink targets something
> special or some kind of error that is just ignored?

I guess it isn't symlink specific, since it's part of mairix's raw
output, too.

I was also surprised to see that Emacs handles a path like that just
fine. Looks like `directory-file-name' will remove as many trailing
slashes as you have on a filepath, and since that function gets used
somewhere inside most of the other filepath functions, it ends up
working.

Luckily `file-name-split' is one of those other functions, so instead of
doing gross regular expression munging I'll switch to using Science™ and
treat the path like an actual file name. Instead of adding cruft we can
fix your bug and make the whole thing more reliable at the same time.

(mapconcat #'identity
	   (remove "" (file-name-split f-name))
	   ".")

Maybe this will create more bugs, but let's see!

Hmm, maybe I'll float this on gnus.general first...

Message #38 received at 53989 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 53989 <at> debbugs.gnu.org
Subject: Re: bug#53989: 29.0.50; Gnus searches broken
Date: Tue, 15 Feb 2022 00:21:54 +0100

Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

> Hmm, maybe I'll float this on gnus.general first...

Would be good to know if this is a bug in mairix, or somewhere else.
Unfortunately Debian only offers one built of mairix.

I wonder if anyone else is seeing what I see.

Michael.

Message #41 received at 53989 <at> debbugs.gnu.org (full text, mbox):

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

On 02/15/22 00:06 AM, Michael Heerdegen wrote:
> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> Also, it looks like your bug#47130 is still open. Since we've moved on
>> to this one, maybe lets close that in the meantime?
>
> Did you already add the note to the documentation that we seemed to have
> talked about in that report?  AFAIR, the note should say that the
> binding of `gnus-search-mairix-remove-prefix' must correspond to the
> path of the mail archive, not to some mairix folder.

Done!

Message #44 received at 53989 <at> debbugs.gnu.org (full text, mbox):

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

On 02/15/22 00:21 AM, Michael Heerdegen wrote:
> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> Hmm, maybe I'll float this on gnus.general first...
>
> Would be good to know if this is a bug in mairix, or somewhere else.
> Unfortunately Debian only offers one built of mairix.
>
> I wonder if anyone else is seeing what I see.

I'll ask at the same time I post the patch.

Message #47 received at 53989 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 53989 <at> debbugs.gnu.org
Subject: Re: bug#53989: 29.0.50; Gnus searches broken
Date: Tue, 15 Feb 2022 00:31:52 +0100

Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

> I'll ask at the same time I post the patch.

Thanks.  Meanwhile, I changed

base=~/Mail/archive

to

base=~/Mail/archive/

in my .mairixrc and rebuilt the database.  Now the matches have three
slashes, like in "/home/micha/Mail/archive///sent/995".

Michael.

Message #50 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#53989: 29.0.50; Gnus searches broken
Date: Mon, 14 Feb 2022 15:35:53 -0800

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> I'll ask at the same time I post the patch.
>
> Thanks.  Meanwhile, I changed
>
> base=~/Mail/archive
>
> to
>
> base=~/Mail/archive/
>
> in my .mairixrc and rebuilt the database.  Now the matches have three
> slashes, like in "/home/micha/Mail/archive///sent/995".

Ha! But never fear, `file-name-split' removes as many slashes as you've got.

Message #53 received at 53989 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 53989 <at> debbugs.gnu.org
Subject: Re: bug#53989: 29.0.50; Gnus searches broken
Date: Tue, 15 Feb 2022 00:40:16 +0100

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
> > I'll ask at the same time I post the patch.
>
> Thanks.  Meanwhile, I changed
>
> base=~/Mail/archive
>
> to
>
> base=~/Mail/archive/
>
> in my .mairixrc and rebuilt the database.  Now the matches have three
> slashes, like in "/home/micha/Mail/archive///sent/995".

I now tried with

| mh=*

instead of

| mh=...

and that gives me the correct number of slashes, and searching in Gnus
finally works.

Seems mairix is just not very smart when expanding file names.

Michael.

Message #56 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#53989: 29.0.50; Gnus searches broken
Date: Mon, 14 Feb 2022 15:45:25 -0800

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> Michael Heerdegen <michael_heerdegen <at> web.de> writes:
>
>> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>>
>> > I'll ask at the same time I post the patch.
>>
>> Thanks.  Meanwhile, I changed
>>
>> base=~/Mail/archive
>>
>> to
>>
>> base=~/Mail/archive/
>>
>> in my .mairixrc and rebuilt the database.  Now the matches have three
>> slashes, like in "/home/micha/Mail/archive///sent/995".
>
> I now tried with
>
> | mh=*
>
> instead of
>
> | mh=...
>
> and that gives me the correct number of slashes, and searching in Gnus
> finally works.
>
> Seems mairix is just not very smart when expanding file names.

Oh... hmm. I wonder if we should actually change the parsing then or
not? What do you think?

Message #59 received at 53989 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 53989 <at> debbugs.gnu.org
Subject: Re: bug#53989: 29.0.50; Gnus searches broken
Date: Tue, 15 Feb 2022 01:37:56 +0100

On Feb 14 2022, Eric Abrahamsen wrote:

> Oh... hmm. I wonder if we should actually change the parsing then or
> not? What do you think?

There is a similar problem in gud, see gud-find-file.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Message #62 received at 53989 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 53989 <at> debbugs.gnu.org
Subject: Re: bug#53989: 29.0.50; Gnus searches broken
Date: Mon, 14 Feb 2022 17:29:42 -0800

On 02/15/22 01:37 AM, Andreas Schwab wrote:
> On Feb 14 2022, Eric Abrahamsen wrote:
>
>> Oh... hmm. I wonder if we should actually change the parsing then or
>> not? What do you think?
>
> There is a similar problem in gud, see gud-find-file.

Huh, interesting. On the one hand, this particular error was (arguably)
caused by user config, or at least it was solvable though user config.
On the other hand, having your email searches fail when they wouldn't
have to is very annoying. I really hate this part of the code.

Message #65 received at 53989 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 53989 <at> debbugs.gnu.org
Subject: Re: bug#53989: 29.0.50; Gnus searches broken
Date: Tue, 15 Feb 2022 03:48:50 +0100

Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

> Oh... hmm. I wonder if we should actually change the parsing then or
> not? What do you think?

`expand-file-name' collapses multiple consecutive slashes into a single
slash - that's documented.  Can we just map it over the names delivered
by mairix?

Michael.

Message #68 received at 53989 <at> debbugs.gnu.org (full text, mbox):

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

On 02/15/22 03:48 AM, Michael Heerdegen wrote:
> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> Oh... hmm. I wonder if we should actually change the parsing then or
>> not? What do you think?
>
> `expand-file-name' collapses multiple consecutive slashes into a single
> slash - that's documented.  Can we just map it over the names delivered
> by mairix?

Oh, that's not bad. If you mess up your mairix config again and then
eval this:

(cl-defmethod gnus-search-indexed-extract :around
  ((_engine gnus-search-indexed))
  (let ((ret (cl-call-next-method)))
    (cl-callf expand-file-name (car ret) "/")
    ret))

Does everything work properly?

Message #71 received at 53989 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 53989 <at> debbugs.gnu.org
Subject: Re: bug#53989: 29.0.50; Gnus searches broken
Date: Tue, 15 Feb 2022 05:20:17 +0100

Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

> Oh, that's not bad. If you mess up your mairix config again and then
> eval this:
>
> (cl-defmethod gnus-search-indexed-extract :around
>   ((_engine gnus-search-indexed))
>   (let ((ret (cl-call-next-method)))
>     (cl-callf expand-file-name (car ret) "/")
>     ret))
>
> Does everything work properly?

Yes, I think so, looks good.

Michael.

Message #74 received at 53989 <at> debbugs.gnu.org (full text, mbox):

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

[Message part 1 (text/plain, inline)]

On 02/15/22 05:20 AM, Michael Heerdegen wrote:
> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> Oh, that's not bad. If you mess up your mairix config again and then
>> eval this:
>>
>> (cl-defmethod gnus-search-indexed-extract :around
>>   ((_engine gnus-search-indexed))
>>   (let ((ret (cl-call-next-method)))
>>     (cl-callf expand-file-name (car ret) "/")
>>     ret))
>>
>> Does everything work properly?
>
> Yes, I think so, looks good.

Okay, it turns out that also lets us drop most of the regexp silliness
from the parsing stuff. Would you mind trying the attached patch and
confirm that it doesn't break anything? I'll try to make this the last
time I mess with search results parsing...

[moresearchparsingfun.diff (text/x-patch, attachment)]

Message #77 received at 53989 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 53989 <at> debbugs.gnu.org
Subject: Re: bug#53989: 29.0.50; Gnus searches broken
Date: Fri, 18 Feb 2022 03:10:07 +0100

Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

> Okay, it turns out that also lets us drop most of the regexp silliness
> from the parsing stuff. Would you mind trying the attached patch and
> confirm that it doesn't break anything? I'll try to make this the last
> time I mess with search results parsing...

Works so far for me.

| +(cl-defmethod gnus-search-indexed-extract :around
| +  ((_engine gnus-search-indexed))
| +  (let ((ret (cl-call-next-method)))

Why do you need an :around method here - why don't you just add that to
the primary method?

| +    ;; We run `expand-file-name' here in order to collapse multiple
| +    ;; consecutive directory separators.
| +    (cl-callf expand-file-name (car ret))
| +    ret))

If I were you I would add to the comment that mairix may return such
multi-separator file names - else it's not clear why that collapsing is
necessary at that point.


Thanks,

Michael.

Message #80 received at 53989 <at> debbugs.gnu.org (full text, mbox):

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

On 02/18/22 03:10 AM, Michael Heerdegen wrote:
> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> Okay, it turns out that also lets us drop most of the regexp silliness
>> from the parsing stuff. Would you mind trying the attached patch and
>> confirm that it doesn't break anything? I'll try to make this the last
>> time I mess with search results parsing...
>
> Works so far for me.
>
> | +(cl-defmethod gnus-search-indexed-extract :around
> | +  ((_engine gnus-search-indexed))
> | +  (let ((ret (cl-call-next-method)))
>
> Why do you need an :around method here - why don't you just add that to
> the primary method?

Hmm... I think I was originally trying to do more in this method --
prefix removal and all that. You're right this isn't necessary.

> | +    ;; We run `expand-file-name' here in order to collapse multiple
> | +    ;; consecutive directory separators.
> | +    (cl-callf expand-file-name (car ret))
> | +    ret))
>
> If I were you I would add to the comment that mairix may return such
> multi-separator file names - else it's not clear why that collapsing is
> necessary at that point.

I think I'd rather leave it like this. We don't know if the behavior
might appear under other circumstances, and in the end the real problem
is multiple separators, not mairix.

Message #83 received at 53989 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 53989 <at> debbugs.gnu.org
Subject: Re: bug#53989: 29.0.50; Gnus searches broken
Date: Sat, 19 Feb 2022 02:07:35 +0100

Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

> I think I'd rather leave it like this. We don't know if the behavior
> might appear under other circumstances, and in the end the real problem
> is multiple separators, not mairix.

Ok, fine.

And I see that the change has been installed.

So we are done here, right?


Thanks,

Michael.

Message #86 received at 53989 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 53989 <at> debbugs.gnu.org
Subject: Re: bug#53989: 29.0.50; Gnus searches broken
Date: Fri, 18 Feb 2022 17:20:29 -0800

On 02/19/22 02:07 AM, Michael Heerdegen wrote:
> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> I think I'd rather leave it like this. We don't know if the behavior
>> might appear under other circumstances, and in the end the real problem
>> is multiple separators, not mairix.
>
> Ok, fine.
>
> And I see that the change has been installed.
>
> So we are done here, right?

We are! I hereby certify this area of the code bug-free, guaranteed for
ten years.

Message #91 received at 53989-close <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 53989-close <at> debbugs.gnu.org
Subject: Re: bug#53989: 29.0.50; Gnus searches broken
Date: Sat, 19 Feb 2022 02:29:44 +0100

Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

> > So we are done here, right?
>
> We are! I hereby certify this area of the code bug-free, guaranteed for
> ten years.

Very cool!  I hope I don't have to make use of the guarantee, but it's
good to have it.

So - thanks for fixing!

Michael.

Previous Next

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