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

Previous Next

Package: emacs;

Reported by: Arash Esbati <arash <at> gnu.org>

Date: Thu, 17 Nov 2022 16:52:01 UTC

Severity: normal

Merged with 59565

Found in version 29.0.50

Done: João Távora <joaotavora <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Danny Freeman <danny <at> dfreeman.email>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: arash <at> gnu.org, arstoffel <at> gmail.com, 59338 <at> debbugs.gnu.org
Subject: bug#59338: 29.0.50; Commit 1a2d603bb3 breaks Eglot on Windows
Date: Fri, 18 Nov 2022 08:39:13 -0500
Eli Zaretskii <eliz <at> gnu.org> writes:

>
> Not sure I understand why this matters in the context of this
> discussion.  We need to make eglot--path-to-uri produce valid file://
> URL on MS-Windows and on Posix systems, right?  Then why does it
> matter how URI schema are defined?  What am I missing?

The current eglot--path-to-uri implementation should produce a valid
file:// url unless what it receives is already a URL.

So it could receive something like:

/home/user/project/whatever.c
d:/what/home/is/on/windows/whatever.c

Both of which should be transformed into file:// URLs
OR what it receives may already be a URL like

zipfile:home/user/project.zip::/path/in/zip.c

If it receives a URL, we want to pass it along, and not transform it
into a file:// URL.

If it is a full windows path, we DO want to turn that into a file url.

So how do we detect that is is a windows path, and not a URL already?
That's what I was trying to get at in the other message you replied to.
Just checking the user's current OS is not enough, because this function
could also receive a URL on Windows.

-- 
Danny Freeman




This bug report was last modified 2 years and 231 days ago.

Previous Next


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