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 wrote: > > From: Danny Freeman > > Cc: Eli Zaretskii , Arash Esbati , > > 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