Subject: bug#53989: 29.0.50; Gnus searches broken

From: Eric Abrahamsen <[email-masked]>
Date: Mon, 14 Feb 2022 15:08:36 -0800

Michael Heerdegen <[email-masked]> writes:

> Eric Abrahamsen <[email-masked]> 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...