Yes, i think that makes sense. Can't look at that pull request right now,
but my current thinking is to leave the URI unprocessed if the scheme is
anything other than file://.

Then file-name-handler-alist can decide what to do with it.

But warning the user on such occasions sounds a bit too noisy. Maybe a
one-time warning.

The only other thing to watch out for is that wherever find-file lands is,
its buffer-file-name should probably be left with the unchanged URI, so
that eglot--path-to-uri can return it and tell the LSP server that we're
now managing the buffer using the original URI.

João

On Sat, Oct 29, 2022, 16:36 Felician Nemeth <felician.nemeth@gmail.com>
wrote:

> > The problem occurs when using `xref-find-defintions` while eglot is
> > managing a clojure buffer with clojure-lsp. If the symbol that
> > xref-find-definitions is activated on is defined in a jar file,
> > clojure-lsp by default will provide a location with a response like
> > the following
> >
> > (:jsonrpc "2.0" :id 14 :result
> >   (:uri
> >
>  "zipfile:///Users/andreperictavares/.m2/repository/org/clojure/tools.namespace/0.3.1/tools.namespace-0.3.1.jar::clojure/tools/namespace/find.clj"
> > ... ))
> >
>
> Can you, please, consider merging something like github#854?
> https://github.com/joaotavora/eglot/pull/854
>
> Currently, Eglot assumes that the uri-scheme is always "file".  I think
> Eglot should at least warn the user if this assumption is false instead
> of silently failing as it currently does.
>
> Thanks.
>