bug#57353: [PATCH] Fix parse-colon-path with UNC directory names

[Richard Copley]

On Tue, 23 Aug 2022 at 14:21, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Richard Copley <rcopley@gmail.com>
> > Date: Tue, 23 Aug 2022 12:34:02 +0100
> >
> > A comment in `parse-colon-path' says:
> >
> > ;; Previous implementation used `substitute-in-file-name'
> > ;; which collapse multiple "/" in front.  Do the same for
> > ;; backward compatibility.
> >
> > However, `substitute-in-file-name' does not do that:
> >
> > (substitute-in-file-name "//foo/a/b") // -> "//foo/a/b"
>
> That is true, but:
>
>   (substitute-in-file-name "///foo/a/b") => "//foo/a/b"
>
> So it does collapse multiple "/", at least sometimes.  Moreover, the
> above is on MS-Windows, but on GNU/Linux:
>
>   (substitute-in-file-name "///foo/a/b") => "/foo/a/b"
>
> So (a) this is system-dependent, and (b) substitute-in-file-name does
> collapse multiple slashes, but preserves UNCs on MS-Windows.
>
> Therefore, your patch needs some (minor) amendments.

If the goal is to be backward-compatible with substitute-in-file-name,
we should do everything that function does, which is quite involved,
and involves configuration that is not available to lisp. Easier to
just revert the commits. But that wasn't the goal, see #21454.

Tino doesn't explain why the particular case of multiple slashes at
the start of a path component is any different from the other cases of
multiple slashes, which are no longer changed. I'm afraid I don't
understand the point of it.

I'll apply a workaround locally, and leave it up to the developers to
decide what to do, if anything.

Thanks.