Subject: Re: bug#59338: 29.0.50; Commit 1a2d603bb3 breaks Eglot on Windows

From: Eli Zaretskii <[email-masked]>
Date: Fri, 18 Nov 2022 09:12:11 +0200

> From: Danny Freeman <[email-masked]>
> Cc: Eli Zaretskii <[email-masked]>, Arash Esbati <[email-masked]>,
>  [email-masked], [email-masked]
> Date: Thu, 17 Nov 2022 17:27:40 -0500
> 
> Is there something we can do to detect a windows path

You mean, a Windows-style file name?  You can detect that, but it is
easier to test system-type instead: these file names cannot happen on
any system except Windows, and if they do happen, they don't have the
same semantics (i.e., "d:/foo/bar" is NOT an absolute file name on
Posix systems).

Or maybe I don't understand the purpose of the test you have in mind?

> and continue treating it as a path like we were before this change?

I'd advise against such kludges.  If a function wants a file:// URL,
it should receive a valid file:// URL on all systems, and it should be
capable of handling file:// URLs on MS-Windows as well as on Posix
systems.  Likewise with functions which produce file:// URLs.  Letting
local file names into this is a clear path to future bugs, because
many people will not realize this subtlety, and will think they deal
with file:// URLs on all platforms.

> If there is no function available already, it may be enough to check if
> the return value of `url-type` is not 1 character. Looking at this list
> of what I believe are official URI schemes, all of them have at least
> two characters: 
> https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml 

But hosts can have 1-character names (although that is unlikely).

Anyway, I'm against such kludges, especially since we don't need them
here.  We just need to make our functions that handle file:// URLs to
be capable of supporting file:// on MS-Windows.  It is not hard to do,
so let's do that.