Yes,I think I follow.  To be clear I think the problem is somewhere in

(defun eglot--path-to-uri (path)
  "URIfy PATH."
  (let ((truepath (file-truename path)))
    (if (url-type (url-generic-parse-url truepath))
        ;; Path is already a URI, so forward it to the LSP server
        ;; untouched.  The server should be able to handle it, since
        ;; it provided this URI to clients in the first place.
        truepath
      ...)

So either url-generic-parse-url and url-type is fixed in url-parse.el, or
we must add some Windows-specific guards in eglot.el.  Or likely
both, since url-parse.el is not a :core ELPA package.

Richard/Danny, can you perhaps come up with some patch?

João

On Wed, Nov 23, 2022 at 11:55 AM Richard Copley <rcopley@gmail.com> wrote:

> On 22/11/2022 14:30, Michael Albinus wrote:
> > João Távora <joaotavora@gmail.com> writes:
> >
> > Hi João,
> >
> >>      Both seem to be OK, although I'm not sure that it is the right
> >>      approach in eglot--path-to-uri just to concat "file://" and the
> >>      file-local-name part of a remote file name.
> >>
> >> Can you describe a case where this would be problematic? Remember
> >> that, from the point of view of the server, the file is always local.
> >> That's regardless of whether eglot invoked the server remotely or
> >> locally.
> >
> > Got it.
> >
> > Best regards, Michael.
>
> Hi All,
>
> For file names with a Windows drive letter and forward slashes (as
> emitted by CMAKE_EXPORT_COMPILE_COMMANDS), the drive letter is
> misinterpreted as a URL type, leading to repeated errors,
>    "clangd only supports 'file' URI scheme for workspace files".
>
>
> (let ((path "c:/projects/awesome-project/source/main.cpp"))
>    (message "type %s, url %s"
>             (url-type (url-generic-parse-url path))
>             (eglot--path-to-uri path)))
>
> ;; => "type c, url c:/projects/awesome-project/source/main.cpp"
>
>

-- 
João Távora