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