GNU bug report logs - #59338
29.0.50; Commit 1a2d603bb3 breaks Eglot on Windows

Previous Next

Full log

View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Richard Copley <rcopley <at> gmail.com>
Cc: arash <at> gnu.org, arstoffel <at> gmail.com, Danny Freeman <danny <at> dfreeman.email>, 59338 <at> debbugs.gnu.org
Subject: bug#59338: 29.0.50; Commit 1a2d603bb3 breaks Eglot on Windows
Date: Wed, 23 Nov 2022 12:51:37 +0000

[Message part 1 (text/plain, inline)]

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 <at> gnu.org> wrote:

> > From: Danny Freeman <danny <at> dfreeman.email>
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, Arash Esbati <arash <at> gnu.org>,
> >  59338 <at> debbugs.gnu.org, bug-gnu-emacs <at> 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

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.