I just found out this bug was ongoing. 

Eli, if you're proposing to fix url-parse.el to not be fooled by windows
file names, then I support that idea, and I think it's the correct
thing to do.

But.... we still need the eglot.el kludge installed because url-parse.el
is not distributed as an ELPA package and Eglot is. So users of
Emacs < 29 would not receive the fix and would have their
WIndows Eglot broken.

João

On Fri, Nov 18, 2022 at 7:13 AM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Danny Freeman <danny@dfreeman.email>
> Cc: Eli Zaretskii <eliz@gnu.org>, Arash Esbati <arash@gnu.org>,
59338@debbugs.gnu.org, bug-gnu-emacs@gnu.org
> 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.





--
João Távora